Countly performance


Countly can serve up to several million users on a single server, and it'll work happily out of the box. With a modern stack on top of Nodejs and MongoDB, this performance is far from other web analytics tools which can be installed on-premise.

Most of the time, a moderate server can handle several hundred users online and you'll only need to deal with the uptime and general server maintenance.

However, sometimes it might be necessary to tweak performance of the underlying system - database and server, in order to make Countly work in a very high traffic environment. With high traffic, we mean a few billion hits on the server per month.

Countly Enterprise Edition can serve tens of billions of hits per month on a scalable infrastructure with sharding technology, and is available for Enterprise Edition customers. For more information about Enterprise Edition and all of its features, see this link.

Recommended server configuration

There are several general recommendations for both Community Edition and Enterprise Edition, depicted below.

  • Running your Countly instance on a dedicated or barebone server greatly increases network throughput and CPU performance.
  • Instead of using hard disks, using SSD will also decrease time to write on disk. Even high performance hard disks will perform less than SSDs. Reliability of SSD disks are also much higher than traditional disks (0.6% per year vs 2.0% per year).
  • Countly will benefit from free RAM on the server. At least index of your MongoDB instance should reside in the RAM. Make sure you have at least 4GB of memory - the more the better.
  • Countly performance is heavily dependent on MongoDB performance, so we suggest you read Monitoring & Diagnostics for MongoDB.

By default, Countly operates real-time. Data is immediately inserted to MongoDB as they arrive, therefore there's no "work sans-real-time" option with Countly. Majority of work done is writing the data to memory and/or disk.

When you login to the administration panel, you only read aggregated data, which is in turn visualized on the browser. This is a very lightweight process compared to writing data to MongoDB. Two features that needs reading from database scanning data (no aggregation) is Flows and Drill.

Share your experience

While Countly Community Edition doesn't produce very large data sets, this is not the case with Enterprise Edition, where each and every custom event is stored on Countly Drill database. We provide sharding and replicaset configurations for Enterprise Edition. For the case of Community Edition, primary bottleneck would be caused by lack of RAM and improper server configuration/setup. If you are running Countly on a high traffic server, we recommend using Enterprise Edition.

Was this article helpful?
0 out of 0 found this helpful

Looking for help?