Web application Extension Series (1): Architecture Chapter

Original: Web application extension Series (1): Architecture Chapter

In this article, I'll try to cover some of the architectural issues that you might encounter with Web App extensions or performance tuning.

First, let's unify the concepts of some nouns or projects, and I'll list some of the issues that you might encounter when extending a web app, including:

• Architecture bottlenecks
• Database extensions
• CPU-dependent applications
• IO-dependent applications

And how to determine the content that optimizes the size of the Web App thread pool will be given in the next article.

Performance (performance) the term for Web applications usually means some metrics, and for most developers, their primary concern is response time (response) and Extensibility (scalability).

• Response time

Response time refers to the time it takes for a web app to receive a request to its return. The application response time should be controlled within a reasonable range, if the corresponding time of an application beyond the acceptable time range, then this application is not a good application.

• Scalability

An application can be said to be extensible if its ability to request a service increases linearly as the resource is increased. There are two modes of increasing resources:

• Scaling up:-Increases the amount of computing power or the performance of computing power in a single service unit.
• Scale out:-Add more service units.

Scale-out vs vertical expansion

Scale-out is about taking advantage of relatively inexpensive hardware to replace some expensive equipment that requires special acquisitions (such as hyper-counting). However, it is equally important to increase the number of requests that a service can respond to on a single, inexpensive hardware unit. We say that the performance of an application is that it can handle more requests without prolonging the response time by adding more resources.

Response Time vs Extensibility

Response time and scalability do not change in the direction you want. For example, some applications may have good response times, but only a certain number of requests, while others can handle growing requests, but they take a long time to consume. So we have to make a balance between the two to get the best application performance.

Capacity Planning

Capacity planning (capacity planning) is an activity that clarifies how much hardware resources a product needs to handle the desired load. Typically it involves figuring out the limits of the performance of the application, which is to respond to the maximum number of requests and the performance of a single service unit based on fewer service units. Finally, a load performance test is performed to verify.

Extensible architecture

If an application is multi-layered and extensible (scale-out) at each level, the architecture of the application is extensible. For example: As shown, we can add additional computational units linearly at the application layer or database layer.

Extended Load Balancer

The load balancer can be scaled by specifying DNS to multiple IP addresses, or by using DNS polling. Another approach is to use a tiered load balancer that distributes requests to the next level of load balancers by the front-end load balancer.

Adding multiple load balancers is rare for a single computational unit that uses Nginx or Haproxy, a powerful software that can handle more than 20,000 concurrent connections on a single unit, much more powerful than other Web application containers. As a result, they can handle requests from multiple Web application units through their individual load balancer units.

Extending the Database

The extension of a database is one of the most common extension issues. Adding additional business (stored procedures or functions) to the database tier presents additional burden and complexity.

relational database

A relational database can be extended through a master-slave pattern, which allows for read-write separation, where the main library is responsible for reading and writing, and from the library. Master-Slave mode provides a limited read extension, and in addition to this, developers typically partition the database for scale-out.

Nosql

The CAP theory is clear that it is not possible to satisfy both consistency, availability, and partition fault tolerance. NoSQL databases typically sacrifice consistency to get high availability and partition fault tolerance.

Database partitioning

The partitioning of a database can be either vertically divided (partitioned) or horizontally partitioned (fragmented).

• Vertical partitioning (partitioning): A database can be divided into multiple, loosely sub-Libraries based on domain concepts. For example, a customer database, a product database, and so forth. You can also move a small number of columns from one entity to a different database. such as customer database, customer contact database and customer order database.
• Horizontal partitioning (sharding): A database can be horizontally divided into multiple libraries based on discrete attributes. such as the U.S. customer database, European customer database and so on.

Using partitioning or sharding, converting a database from library mode to multi-Library mode is a challenging task.

Architecture bottlenecks

The bottleneck of the expansion is mainly due to two problems:

• Centralized component: A component in the application architecture that cannot scale out horizontally by increasing the maximum number of requests processed by the entire schema or request channel.
• High-latency components: a slower component that pulls down the lower bound of the application request channel response time. The usual solution is to execute this high-latency component as a background task or asynchronously using the queue's method.

CPU-intensive applications

If the throughput of an application is limited by the CPU, then we call this application CPU-intensive (CPU Bound application). By increasing the operating speed of the CPU, the response time of the application can be reduced.

Some possible CPU-intensive scenarios:

• Applications are used to calculate or process data without IO operations (financial or trading applications)
• The application relies heavily on caching without generating IO operations
• Applications are asynchronous (non-blocking) and do not need to wait for external resources (passive mode applications, NODEJS applications)

In the scenario mentioned above, the application is already running efficiently, but there are a handful of application instances that may be due to code-level reasons, and there are some completely unnecessary actions to calculate or poll each request, thus making CPU utilization very high. Analysis makes it easy to find inefficiencies and make improvements.

These issues can be resolved in the following ways:

• Cache the previous calculation results
• Running calculations in separate background tasks

Caching in different ways, how caching can reduce the load to improve performance and the extensibility of Web applications will be detailed in the next blog post.

IO-intensive applications

If the throughput of an application is limited by IO or network capability and cannot be increased by the method of increasing CPU speed, then this application is called IO intensive application (IO Bound application). Most applications are IO-intensive, because most applications rely on curd operations, and it is difficult to improve performance or expansion in these applications because it relies heavily on other downstream systems.

Some of the following are possible IO-intensive scenarios:

• Applications rely on databases and a large number of CRUD operations
• The app uses the Web service to do its own work

The next post will talk about how to optimize the size of your Web app's thread pool.

Web application Extension Series (1): Architecture chapter (GO)