Keep Your Technology Stack Up To Date Metreno Upgrade Case Study

Keep Your Technology Stack Up To Date Metreno Upgrade Case Study

The development of a web application does not end after all the features specified in the backlog have been implemented. The work on the application can continue for a long time after that point; the app has to be supported, maintained and, quite often, enhanced. Bear in mind that the technology platform of your choice changes and improves over time. Thousands of developers work on the platform every day contributing to and actively developing open source frameworks, packages, plugins, libraries, which become better and faster as a result. Ruby On Rails is a vibrant community in this respect. By keeping your application tech stack environment up-to-date, you ensure greater functional reliability and better application performance. All you need to do is to take advantage of the community contributions by periodically “refreshing” your application and thus bringing it in synch with the changes introduced. Your end user is likely to feel a huge difference.

Metreno

A very good example of the benefits coming from keeping your technology stack up to date is Metreno – a SaaS system for tests generation, sales and management. We have recently made a series of upgrades on that project and the results have turned out to be very good.

null

The scope of upgrade

Before we go into details it is important to note that we use the New Relic service to monitor the application. The tool ensures access to critical data about, for example, how much time it takes real users to perform typical tasks in the application. We also have a lot of other useful statistics that help the developers in their daily work on the project. You definitely should consider using New Relic or other some such tool, for monitoring your application.

In Metreno, the following parts of the system needed an upgrade:\ – Rails framework, from version 3.0 to 3.2 and\ – Ruby, from version 1.8.7 (REE) to 1.9.3.

From Rails 3.0 perspective, the major features / changes in Rails 3.2 were:\ – Assets Pipeline\ – HTTP Streaming\ – Identity Map\ – Faster Development Mode & Routing

From Ruby 1.8.7 perspective, the major features / changes in Ruby 1.9.2 were:\ – Performance\ – Threads/Fibers\ – Encoding/Unicode

Interestingly enough, there was no need to do extra refactoring of the existing functionalities that would go beyond what was necessary to make them compatible with new Rails and Ruby APIs.

The results achieved

The high-level factor that describes the performance of your application in New Relic is apdex. It is in a way an indicator of user satisfaction and it is based on the server response times and the number of errors that affect the user. Apdex is a float number between 0.0 (very bad) and 1.0 (very good). In can be measured from two perspectives: the end user and the application server. As regards Metreno, the response time threshold was set at 4.0 seconds for the end user perspective and at 0.5 seconds for the application server perspective.

Before the upgrades, the apdex from the end user perspective was around 0.905; the measurement was based on 125,000 pageviews. 83% of the users could browse the application in satisfying time, 15% in tolerating time and 2% in frustrating time. Not bad, but from the application server perspective things looked worse. Only 66% of 651,000 requests were served in satisfying time, 27% in tolerating time and 7% in frustrating time. There was room for improvement.

The technology stack was updated and deployed in the middle of February. After this update has been performed the average page load time dropped by 36% – from 2.8 seconds to 1.8 seconds – and the average response time decreased by 81% – from 608ms to 118ms.

After conducting the upgrades, the apdex from the end user perspective rose to 0.924, based on 180 000 pageviews. The application served pages to 93% of users in satisfying time, 6% in tolerating time and 1% in frustrating time. Even better results were recorded for the application server perspective. Over 97% of 1,413,000 requests were served in satisfying time, 2% in tolerating time and less than 1% in frustrating time. The application was now noticeably faster and – at the same time – able to serve more users than before the upgrade.

The following charts show how the end user perspective changed over time; the upgrades were deployed on the 10th of February.

The following charts show how the application server perspective changed over time; the upgrades were deployed on the 10th of February.

null

null

Conclusion

Thanks to the conducted Ruby and Rails upgrade, the application performs much better.\ The upgrade has had a positive influence on the end user satisfaction, which was measured by means of the New Relic apdex. In a nutshell, it may sometimes be a good idea to focus your efforts on the technology stack. Its upgrades do not add functionalities, but they do improve the quality of your application.

Post Scriptum

Special thanks toRadek Jędryszczak and Michał Czyż for their feedback on this article.