The Main Factors Determining a Speed of the Web App

In the series of tests conducted by TechEmpower, CPU usage is the bottleneck, while in the real world, the CPU performance of a programming language or a framework is almost never the bottleneck for a web app’s performance. Modern web applications typically are I/O heavy, especially in conditions of becoming more complicated and rich. A Rails app may interact with three separate databases, in some cases even more – with their SQL database, Redis for their backend job processor, and Memcached for caching. The fact is most often the time spent on interaction with these databases can reach more than 25% of a response.Moreover, you face a great number of problems with app deployments that have nothing in common with the CPU performance of the framework or language. This can be poor server configurations, memory leaks or bloat, or just a poor use of caching. It may seem that developers, mysteriously, are looking for additional ways to completely degrade the performance of their application all on their own!

If we talk about web applications from the Major League which are more mature, their execution time in the framework itself can reach at most 50%. Consequently, far more time is spent in the actual application code and other added dependencies. Especially this it true in case of Ruby with its stacktrace where you can count a small amount of the top frames from your framework. Even if you rewrite your web app in a faster framework in the same language, at the best possible scenario, you will just halve its response times.

Does Ruby Provide A Good User Experience?

At the previous article, we noted that a high performance of the web app is crucial for good user experience. No one wants to wait for eternity when a page is loaded, so that 10 seconds of boring waiting can severely annoy your users and make them exit your application. However, what amount of loading time is enough to retain a visitor? Let’s take a simple app which only returns HTML response with no JS or CSS as an example.

The time will depends on several significant factors. First of all, a distance between location of your device and a hosting server. It’s obvious the smaller the distance is, the faster a response will be. In this way, if both you and a server are located in the same country, the response should be immediate. For example, it can take about 20 milliseconds to get from your computer to the server, and another 20 milliseconds back. Totally, 40 milliseconds for the response. Considering that a user is located in other side of the planet, the waiting will be increased up to… 100 milliseconds. We bet this number doesn’t kill a desire to stay in the app.

Another factor is a type of device you use to reach the app. If in case of desktop it is 40-100 milliseconds, a smartphone can take 3-4 times more. As a result, we get 120-400 milliseconds for response. This number is more than twice less than 1 second.

The last parameter is a technology used to build the app. The difference of a response time between the app built in Rails or in Sequel will be so scanty (less than 100 milliseconds) that a naked eye can hardly notice it. If you are not Flash possessing the power of time, you’ll never suffer from such a latency.

But what if we consider not a little web app that returns a flat HTML response, but a system with JavaScript bundles stretching into the size of megabytes and stylesheets that couldn’t fit in ten Apollo Guidance Computers? The answer didn’t change. Nowadays it takes approximately 5 seconds a web page to render, and some giant apps can reach 12 and more seconds on initial render. In this scenario, the time of a server response is so tiny that it doesn’t have any importance in general interaction.

Moreover, web apps have nothing in common with sophisticated software like video games where speed really matters. By nature, 90% of web apps are simple CRUD systems that don’t require any fast languages with additional features and complex functionality. Both fast and not so fast languages are performing the task of rendering HTML forms with a difference of a few milliseconds. That’s enough to provide a good user experience.

How To Save $1000/month By Rewriting A Ruby App

Owners of Rails apps after viewing results of TechEmpower tests may start crying and blaming the world for injustice. “Why have I developed the app using this prehistorical framework?” “Why haven’t I chosen a faster technology?”, “I should immediately rewrite this obsolete app!” Please, stop. Simple mathematical calculations will allow you to stop hating your choice and rejecting the idea of rewriting your Rails app.

First of all, let’s analyze who makes a decision to rewrite the app and when it is a necessary measure. For example, Pinterest rewrote it’s Ads API in Elixir and finally their response time was reduced to less than a millisecond. Sounds great, yep? The only question is, why?

As we’ve already concluded, the end-user experience doesn’t suffer from the difference of even 400 milliseconds of a response time. That is why we have two reasonable reasons to choose a certain framework over another: a) it’s faster and therefore you’ll spend less on server costs to host it b) it’s simplifies the development process and helps you add quality features faster.

Okay, let’s calculate how your server costs can be changed.

The majority of web apps process far less than 1000 requests/second. It means that the majority of web app developers are hired by a company owning entire web app that does far less than 1000 requests/second. The majority of them do even less than 1000 requests/minute.

Let’s imagine you have a Rails app which serves 20,000 RPM (request/minute, or about 300 req/sec) at an average response time of 250 milliseconds. Such an application will require approximately 200 Puma processes to serve uninterruptedly. We can equate this to a dozen Performance-L dynos on Heroku, or $6,000/month.

Now, let’s assume you rewrite it in Elixir, Phoenix, or other technology you want, and reduce its response time to 125 milliseconds. Before you jump out of your seat, remember that you’re not going to reduce latency to 12 milliseconds or some other stupid-low amount: you’re still going to be limited by I/O to the databases that back this application.

Our application with a halved latency now needs about half the amount of servers we used before. Congratulations: since this moment your rewritten application saves $3,000/month. However, keep in mind that the load on the relational database maintaining this app won’t change, so those costs will remain the same. Moreover, now your app is big enough to perform 20,000 RPM, so you require at least five or what is more fifty engineers, depending on your application’s domain. It will take your company at least $10,000/month for a single software engineer with employee benefits and salary. So, does it worth to choose a fast framework based on saving one-third of an engineer per month? Eventually, this framework makes your development cycles to slow down without this one third of a mythical man-month, and as a result, you’ve increased your costs, not decreased them. Giving advantage to the fast webframework based on server costs is obviously a loser’s game. Of course, if you’re not the owner of a giant corporation where a few milliseconds can save tens of thousands per month. Until you’re not Pinterest, your requests don’t require such grandiose changes.

Write Using Tools That Make You Happy Contrary To Trends

You can notice a tendency to use only the newest technologies among contemporary engineers. There’s a type of them who will never be happy implementing software which isn’t on the “new hotness stack”. Such an aspiration to constantly learn and develop skills is commendable but it doesn’t mean you should rewrite each “оbsolate app” using the newly emerged framework or language. The reason is developers are concerned about their professional and career growth with accompanying financial benefits. Some of them think devotion to older technologies leads to intellectual stagnation and unemployment. However, all these thoughts are just fears and doubts caused by influencers like TechEmpower, but not real concerns for the requirements of a high-performing web application.

The issue of performance is still important and actual, but summarizing all aspects considered in this article, you should understand how little technology choice matters in the performance of your web application. If you have a good Ruby app, don’t hurry to upgrade it by means of the latest development trends. You can hear so many conversations about performance and concurrency when in practice, the margins are narrow and the costs minimal and getting lower. Remember, technologies aren’t dying because of their performance and concurrency features alone. As well as Ruby is not dead. The most impactful and sensible conversation is about things that make you happy: it’s better to answer what technology helps you write more productively, with a high quality and naturally, with greatest happiness, and use it. No matter, whether it is Ruby on Rails, Phoenix or Node.