Web Application Scalability

When it comes to web application development, scalability is one of the most important topics. Web applications are designed to serve many users. While for some apps a few simultaneous users can be the maximum, for other applications 100 can be the minimum. It is one of the major differences between a desktop app and a web application. A desktop app serves one user at a time, but a web application serves multiple users simultaneously. As the number of users grows, scalability issues may start to show. Many of such issues are related to flawed application design. A web application must be able to serve multiple simultaneous sessions, and it should take care of the increased resource usage.

Consider that you are porting a desktop application to a web application. In your desktop application, you have a TDataset and a TDBGrid which load all available rows from a table. Now assume that each time a new session starts, thousands of rows are fetched from the table and added to the grid. Consider that each time the table becomes active, both data structures may consume up to a few megabytes of memory. It would pose no issue if it were a desktop application, as all system resources could belong to the desktop app. However, in a web application, each new session will consume this amount of memory. In this case, if you have 100 active sessions and each session consumes 10 MB of RAM, the total required memory will be 100 x 10 = 1,000 MB = 1 GB.

As you can see, memory consumption can become huge if your sessions are not optimized for resource usage. It shows the importance of resource optimization for applications where scalability is important. There can be cases where scalability doesn't have the highest priority. For example, if you develop a web application for a system with up to 10 users, scalability is not an issue, but for a web application where 100 users are the minimum, resource management should make sure your application will never run out of resources.

The Stress Test Tool can assist in finding scalability issues. Running a stress test can precisely show the maximum amount of memory that your server will consume when a certain number of sessions are running. It can be used to test your web application in a worst-case scenario and see if it can pass the test under such rare conditions. If your application can pass the stress test, it will be ready to deploy to a production environment.

uniGUI itself is optimized in many aspects to deal with resources. To give some examples, it stores bitmaps in cache files, creates forms when opened and destroys them when the user closes them, keeps ImageLists in cache files, etc. Likewise, developers should consider adopting a Create Resource on Demand principle to optimize resource usage.

One good example could be database tables and related datasets. In a classical Delphi approach, a developer may place the connection component and all related datasets on a DataModule, but in uniGUI it would force creating all datasets every time a new session starts. This will pose even more problems if datasets are Active by default.

In uniGUI the correct approach is to place connection components on MainModule and place the datasets on the forms or on DataModules owned by the forms. When you place a dataset on a form, it will be created when the form is shown and destroyed when the form is closed. This approach will optimize memory usage related to datasets.