Pool, balanced load, time space idea

0803

Today, the main learning is the object pool reuse and load balancing technology and time-space-change thinking

Object Pool Reuse:

We know that the creation and destruction of threads, as well as the opening and closing of databases, is a drain on system performance. So we introduced the object pool multiplexing technique. When the thread finishes the task and does not destroy it, instead puts him in the thread pool, and then takes out a thread to complete the task, when there is another task. Similarly, the database connection pool is the same, and when the transaction completes it does not close the database connection pool, but instead puts it directly into the database connection pool. When there is another database transaction action pool, a database connection object is pulled out of the database connection pool. This not only shortens the response time of object creation, but also reduces the system GC pressure. A way to improve system performance. But this is only relative to the heavyweight object, it is not bad to know the efficiency of new.

Load Balancing Technology:

When the system concurrency is large, a server is not enough to bear heavy load. This is often required for multiple servers to balance load client requests.

Let's take a look at Apache's balanced load:

When using Tomcat cluster mode, there is sticky session mode and copy session mode. When sticky, all session information is evenly distributed to each tomcat server for a balanced load. However, once a Tomcat node is having problems, the session information it maintains will disappear. And the same user can only interact with one Tomcat server because the other nodes do not save this user information.

In the complex mode, it makes all the sessions consistent at all nodes, and when a node information changes, this node will broadcast to the other nodes, so that the session information of all nodes is consistent. When a user request is assigned to another node, the assigned node will have sufficient information to process the request. But it is easy to cause the network storm, affect the system efficiency.

Terracotta, as a cross-JVM, is a distributed cache framework.

Terracotta also enables Tomcat session sharing

This is a major improvement over Apache, as the terracotta does not replicate at all, but merely transmits the changed parts. Can effectively avoid cyber storms.

Of course terracotta can also share caches, or other objects.

For terracotta embodiment please go to http://terracotta.org/download

Time swap: Interchange does not reference intermediate variables:

A=a+b;

B=a-b;

A=a-b;

Space Change Time: Caching is a big performance

Pool, balanced load, time space idea