Web Application Performance

How to Increase The Scalability of a Web Application

Time is money. That’s a worn out expression by now. But think how this influences your product success.

The average user expects the web page to load within 2 seconds. Some “patient” types will wait up to 10 seconds before bouncing off your website for good. Now, imagine when a couple of thousands of users want to use your web product simultaneously. All of them still expect it to perform the desired operation within 2 to 5 seconds.

At this point, you are bound to think more about your web app performance. Will it handle the load? How much load can it handle while still maintaining a reasonable response time?

What Stands For an Excellent Web Application Performance?

Web Application Performance

Application performance may mean many things, but for web app developers, it means just two key factors:

Response Time

This refers to the amount of time it takes from an initial user request to receipt of a response. Obviously, it must be rapid, given today’s user demands.


More people online stand for the increased number of users all making requests. The application must be scalable, that is, be able to process those increasing numbers just as rapidly as before. This means adding more hardware in a proactive way so that correct scaling and architecture is in place and ready to handle the increased load.

Just consider SkyScanner web app for a minute. They are catering to over 8.5 million visitors per months. If the scalable web architecture had not been in place for this exponential growth, it would have “died” as quickly as it rose without becoming the go-to tool for finding airfare.

Infusing Scalability Into Your Web Application

A web application consists of three things – the Internet, the application server, and a database server. Building scalable web applications, that is, the architecture that will allow the app to grow, however, is another matter. There can be many architecture issues to account for.

While it may not be initially wise to invest in full scaling, the potential for such should be considered when the MVP (Minimum Viable Product) is first built. If you want to increase performance and scalability of existing applications without such upfront considerations, you will need more time and resources down the road. Still, it can be done.

Brief Look at Key Factors of Application Scalability

Application Scalability

Conditionally, you can organize the segments of a web application that are the most affected by the performance and scalability issues into the following groups:

  • Static resource tier (browsers; web servers; client-side languages such as HTML, JavaScript, CSS).
  • Business logic tier (Server-side programming and scripting languages such as PHP, Java, Python; server operating systems; application servers).
  • Permanent storage tier (data storage engines used; data access mechanisms such as SQL, ORM, GQL etc; operating systems; file storage).

Each of these three areas can pose a different set of challenges when it comes to increasing the performance and scalability of a web application. Let’s specifically look into the common scenarios and solutions to them.

Specific Methods for Increasing Web Application Performance and Scalability

Remember, a simple web application is based upon the Internet, an app server, and a database server. Usually, the app server is a node that is of shared-nothing architecture. This means that it stands alone, sharing no memory or disk storage with other nodes, and is easily scaled horizontally.

The real work of providing storage and access scalability, then, rests with the database server. There may be a huge amount of data, such as that housed on the mortgage loan application, and when there are many users and each wants just small pieces of it, certain issues may arise – the app suddenly becomes unresponsive, takes too much time to load and so on.

In this case, you need to have at least solutions that will increase scalability and maintain high performance – performance tuning, vertical scaling, and horizontal scaling.

Performance Tuning

Performance Tuning

Performance tuning assumes conducting a massive troubleshooting session to identify the key product bottlenecks and other issues causing the loss in performance. Typically, that may also include refactoring the web application source code, analyzing the current configuration settings, implementing new caching strategies and conducting a series of investigative procedures towards different tiers of the web app.

Some of the best practices, in this case, are the follows:

  • Create a list of very specific functional requirements. It might sound like a no-brainer, but a lot of requirements are often summed up as “the application must load fast” without specifying the exact number (2, 5, 15 seconds etc). Set very precise goals such as: “97% of “Create an account” requests should respond in less than 2 seconds measured on a web server”
  • Automate. If you face time and/or budget constraints use automated testing to measure the app’s performance and load. The good tools for that are JMeter and Ranorex.
  • Don’t over optimize. Performance tuning means that your team should only try to fix those issues, which do not meet the set requirements. The more you optimize your application, the more code you will need to fix, which may result in new unexpected issues and longer delivery time.
  • In terms of how to improve scalability, caches are no exception. The concept is this: the most recently requested “writes” are likely to be requested again. So, that information is kept “up front” where it is retrieved faster. Yet, be aware that having more cache on the outside of the web app will increase its performance, yet pose a certain set of other limitations.

Performance tuning should give a better idea of the key areas that need improvement in order to increase performance and scalability of existing applications. Yet, unlike scaling the procedure would be more invasive and require more time, expertise and budgets to be conducted successfully. Hence, it’s always worth considering the alternatives you have.

Vertical Scaling

Vertical Scaling

Vertical scaling occurs when more resources are added to a single computer system. For instance, one of your web app elements “suddenly” requires more physical memory for processing the requests. But it is limited to the capacity of that one “box” (node).

To fix the issue, you can equip this node with more CPU, Memory. Bandwidth or I/O capacity to reduce the app’s sluggishness. If you are able to perform this action, you have scaled the application vertically.

Vertical scaling is often deemed cheaper and simpler as it does not need any significant changes to the web application’s source code. However, the major draw of this approach is that it may not fix the issue for the long term as you can’t merely add more and more resources to a node. At some point, you’ll hit the “wall” posed by the limitations of the operating system itself.

Here are the common constraints to account for:

  • Limited TCP Ports: For instance, if your OS features only a single set of TCP ports, you won’t be able to run two web servers or two proxies required for the vertical scaling.
  • Provider hardware architecture. Certain OSs come with inbuilt limitations and do not allow you to squeeze it to the multiple resource capacity. The hardware you are using may not be capable of allocating even more resources. For instance, your web hosting provider has a lower resources threshold than those suggested by the OS vendor. In that case, the efficiency of vertical scaling will suffer unless you’ll opt for another service provider.
  • Security and management constraints assume that for either of these purposes the web application is split into two or more operating systems.

While vertical scaling may be faster and cheaper to implement, it may not be a viable long-term solution for your product. That’s when you should consider the other options.

Horizontal Scaling

Horizontal Scaling

Horizontal scaling occurs when more “boxes” (computer systems) are added, all of which are responsible for processing user requests and which increase app response because of processing/handling users’ requests in parallel. Meaning you split the web application’s single node into multiple new ones. And the boxes can be then differentiated by shards. If horizontal scaling is the right solution for you, distributed system architecture must be built into the initial architecture, such as Java web applications do. It is a long and tedious development challenge to do it later.

The best practices for improving scalability, in this case, would be to decouple your web application using the tier system mentioned earlier:

  • Static content tier, which stands for certain elements of your web app visible interface such as – static JPG images, cascading style sheets, Javascript libraries etc.
  • Business logic tier is the framework your solution deploys for processing user data or the one available in the permanent storage tier. That could be Java, PHP, Ruby on Rails and other options.
  • Permanent data storage is the place where all the retrieved data is located. Most web applications use relational database systems for that.

One of the most common approaches to increase the response time of a large scale web application is to separate the permanent storage tier into a separate node. The most up-to-date permanent storage solution is the design with decoupling in mind, meaning experienced developers should not have much trouble when transferring the permanent storage on its own node. Now you have some resources freed for the rest of application to run faster.

Yet, here’s another common scenario – the permanent storage has migrated yet the web app becomes sluggish after some time again. At this point, you can choose to either scale the new node vertically or to keep scaling other nodes horizontally and try to separate the business tier from the static content tier.

In this case, your web app is using the same node to deliver both static and dynamic content to users, which may create hiccups in its performance. To tackle this issue it may be worth migrating static content tier to a separate node as it is easier to decouple compared to the business logic tier. Further down the road, you may want to apply horizontal scaling to the newly separated tries to enhance the application performance even further.

As you can see from this post building an app is one thing. Making them scalable, either upfront or after they have already been developed, is quite another matter. Increasing scalability takes time, expertise, and money. If any of these are lacking an individual or enterprise should consider outsourcing this endeavor.

Romexsoft has a long history of application scalability implementation and improvement, and we would be happy to discuss what we believe we can do for you. If you would like some initial information about our expertise in increasing application scalability, check out our SavvyMoney project for starters.  

Written by Romexsoft on April 14, 2017

Serhiy CEO & Founder of Romexsoft, a tech entrepreneur having vast experience in software outsourcing business and Managed IT Services. Want to do some great stuff? Hit me on LinkedIn
Share The Post

Leave a Comment