• Learn
  • Blog
  • Pricing
  • About
  • Sign in

Bug report: Improved stability and performance

Calcapp usage is growing quickly, which has led to intermittent stability issues. We now deliver apps significantly faster than before, which greatly improves stability. Our White Label plan supports 100,000 app launches per month, but we plan on supporting even higher numbers in the future.

On April 4, and in the weeks leading up to that date, we experienced stability issues. At times, Calcapp was completely unavailable, meaning that apps could not be edited and only apps which had already been installed would run. (Our offline support cuts both ways, thankfully — apps continue to work when you’re offline, but also when we’re offline.)

The reason for these outages is that we have been growing faster than we have been able to handle, getting swamped by the increased traffic volumes. At its peak, we can get hundreds of app requests per minute and we previously were not equipped to handle that kind of traffic.

These issues should now be behind us, as our April update delivers apps significantly faster and our server is as a result far more capable of handling the increased traffic demands. We apologize for the disruption.

As part of our April update, we have added support for app launch and report counters, which are used to keep track of your Calcapp usage compared to your plan limits. These counters are also used to power the new statistics feature. When we started that work, we wanted to ensure that we didn’t degrade performance when running apps, as keeping track of counters means more work for our server. We identified and fixed several performance issues when we did that work, resulting in a new release that is able to cope far better with increased traffic — and delivers apps to you much faster.

Our plan was to deliver these performance improvements together with the rest of the April release, when we had had time to ensure its quality and update the documentation on our site. On April 4, though, we experienced a traffic surge so great it knocked us offline temporarily and we made the call to release our April update early, without doing the quality assurance we would have preferred to do. (All new features were cosmetically removed, so if you don’t remember being able to change plans or add users to private apps, that’s the reason.)

The new release was able to cope admirably with the influx of traffic and we have had no downtime since. However, the new release did introduce new bugs, like the inability to duplicate apps. In the days following the release, we diligently fixed all issues that got reported and which we uncovered ourselves, meaning that we think that quality should now be on par with what it was prior to the early rollout.

We don’t have a status page you can use to keep abreast of stability issues and see how we’ve been doing historically in terms of stability. Rolling one out is on our to-do list. Meanwhile, we use social media to keep you updated whenever we experience outages. For now, please refer to our Facebook, Twitter and LinkedIn feeds for updates if you believe we’re suffering an outage (or simply send us an e-mail).

Our paid plans are diffentiated from one another partly in terms of how many monthly app launches they support. Currently, the White Label plan supports 100,000 monthly app launches. With our new stability changes, we’re confident that we can support that number.

However, we realize that some customers will require a higher number, especially users of embedded apps that may be embedded in pages receiving millions of monthly hits. We don’t yet have the infrastructure to comfortably handle a large number of apps getting that kind of traffic, but getting there would be straight-forward.

When our server delivers apps today, it consults with our database. While our April update makes great strides in making that communication efficient, that kind of setup is still not efficient enough to handle very large traffic volumes. To get there, we would need to introduce one or several memory caches, separate servers which would deliver the most popular apps from high-speed memory, without consulting with a database. Using a memory cache is standard practice for high-volume sites.

If you’re looking to build apps you expect to be launched more than 100,000 times per month, please get in touch. We’re more than willing to do the work necessary to support your high-volume apps and we’d be happy to come up with a custom plan for your apps which supports your traffic goals.

« Feature: Sort apps by plan and date Feature: Usage statistics for apps »