When our developers gather to discuss performance improvements, it sometimes sounds like a discussion in freshman philosophy class about man’s ability to know truth. We use RPM to monitor and tune RPM’s performance. The conversation can get odd as we talk about using our Scalability Analysis tool to improve the performance of the Scalability Analysis tool.
But lately we have been having a lot of those kinds of conversations. This week is the first anniversary of the GA release of RPM. In that year, it has become one of the essential tools for more than 1,800 Rails organizations and is now monitoring more than 27,000 app instances. RPM collects more than 50 Billion data rows per month. In other words it has become a very large scale application. And the growth is accelerating. In just the last 2 months our number of instances managed has increased about 50%!
We have also seen an increase in customer usage of the product. Most users access RPM with the regular browser UI, but many now also utilize our API to access performance data 24×7 through other programs and devices. So there is constant demand on our servers to retrieve and correlate user performance data.
Since we use RPM to monitor RPM, we watch our Apdex scores very closely. In the past month our scores for responsiveness of RPM have occasionally dropped down as low as .91. (Our target, or “T” is set at 1. That is 1 second. So we have been missing our performance targets at times.) It is probably not noticeable to most customers, but we consider this unacceptable. We keep reminding ourselves that the important part of software-as-a-service is service.
To keep up with this growth and demand we have been adding hardware, tweaking code, and considering every opportunity to optimize our performance. If you sometimes encounter a slow graph or report, we apologize. We think we deliver a great service and provide value to our customers every day. But we also believe in transparency and openness and wanted you to know we are striving to do even better.