In a previous blog post, we provided an introduction to massive scaling with MongoDB. Scaling tends to be reactive in nature leading to issues such as degraded application performance or, even worse, total application downtime. These issues ultimately lead to a negative customer experiences that impact your business. So how do you know when it’s the right time to scale your Mongo database so you don’t impact your bottom line?
Find the right threshold for your app
To ensure your application weathers the storm of growth in application usage and surges in traffic, it is imperative to load test a system to determine the threshold that your application can handle before you apply changes like scaling to your production system. More often that not, this process is overlooked and results in fire drills when you encounter issues with an increase in traffic.
The road to a successful MongoDB load test should include the following considerations:
- Which metrics need to be monitored so you can find bottlenecks?
- What threshold should be used in terms of when to scale?
- Which tools should be used to analyze the metrics?
- Where should you run the load test?
Which metrics should I monitor to find bottlenecks?
First, you’ll need to determine which criteria to use to find the limiting factors to your particular application. Every application is different. Knowing these requirements will allow you to determine the the appropriate metrics to monitor from the database side.
Here are some examples:
- Your application requires X number of inserts per second when there is an increase in traffic.
- Data needs to return to the user in less than 100 milliseconds.
- There is a limit in the number of concurrent connections.
- There is a limit in server resources, such as high CPU or load average.
Once you are able to determine the application-side metrics, you can decide what to monitor on the database side.
For example, if your requirements are to have a certain number of insert requests, focus on write metrics such as:
- Server I/O
- Database locking
- opcounters, in terms of active writes
- Available write tickets, if you are running WiredTiger as your storage engine
Tools used to analyze the metrics
Once you determine which metrics to monitor, you need to gather the data from the database side. Here are some utilities utilizing you can use to analyze the load factor:
- mongostat utility shows realtime database metrics on locking, read, and write queues.
- db.currentOp() utility determines the current active operations.
- mongotop allows you to view the top active collections.
- Server utilities such as top, sar, iostat show metrics such as CPU utilization or disk throughput.
In addition to real time analysis, you can also mine the MongoDB logs for additional details about database activity as well as any error conditions. By default, MongoDB logs queries that take longer than 100ms to execute so it is a good tool to identify poor performing queries.
Determine where to run the load test
Once you determine what you will use to gather the data, you are ready to load test. Common sense dictates that you should never load test in a production environment. Sometimes this becomes a show stopper because it can be difficult to spin up an environment fast enough. If you are not already on the ObjectRocket platform, you can spin up a MongoDB test cluster very quickly.
Need some help?
Knowing when to scale your MongoDB environment can get complicated. ObjectRocket customers enjoy the best scaling and sharding support hands-down. Our DBAs can help with every aspect of scaling your clusters and our help is always included. Contact us today to get started.
Now that you can start to determine when to scale your MongoDB instances, in our next blog we’ll cover how you scale MongoDB instances.