Live, always busy, never stop.

Live, always busy, never stop.

Recently, take a sneak, tidy up their technical knowledge system, write casually, right when mark.

Problem definition

Identify problems and solve problems.

case one: high concurrency and MongoDB interaction

Problem Description: The CPU load is high when the job run starts.

Dump Analysis: View Thread Call stack information, there are 42 threads in the following state

Note that when the concurrency is slightly higher, there is a problem with logging, and the Doappend will lock the current object when the anti-compilation can see it.

Instead, the code takes one instance and sets the buffer size to 2, overriding the Sendbuffer method and MongoDB interaction.

Therefore, this is due to frequent and mongodb interactions caused by high CPU Load.

Optimization scenarios:

1. Change the buffer size and set a larger value. But if the log is not enough, it may be a long time to write.

2. Customize a log pool, based on the time and number of dual dimension control, asynchronous batch and MongoDB interaction.

case Two: The interface takes more time

Problem Description: CPU load is very high.

Dump Analysis:

The number of threads is checked before the call stack information for each managed thread is printed, and no obvious problems are found.

To continue, look at the thread's time-consuming and find that there are two threads that take 30 seconds to view from the call stack information, which is the same interface.

The pressure test of the interface, 5 concurrent CPU at more than 90%, so it is because the interface time-consuming, resulting in high CPU Load concurrency.

Performance Analysis:

Using the VS Analyze tool to perform performance analysis on the interface, it was found that the method of fetching a particular cache data from Redis was repeatedly invoked

Tracking code, found that for the same cached data, in two ways to repeat the fetch:
1. Loop, take a single cache.
2. Fetch all caches at once.

So here is the repetition, a little more time-consuming, through debugging can verify this conclusion. Therefore, the first thing is to eliminate repetition.

After that, see why the cache from Redis is so slow because it accesses redis in JSON string format, so it needs to be deserialized, and you can consider optimizing the access scheme for this.

Infrastructure architecture

Quartz.net, ActiveMQ,Unity,autofac, Git, and more.

Among them, interprocess communication, in addition to Webapi, also includes:

Distributed series

Hadoop has not practiced, just read the book before, have almost forgotten ...

Layered

H5 and ASP. NET MVC are not particularly familiar, user performance layer does not say ha ~ ~

Data Persistence layer

SQL Server,MySQL,MongoDB, and so on.

Data warehousing Layer

Interact with the database through ORM tools such as ADO or EF.

Data Cache Layer

Use memcached, Redis, or a self-built cache system.

Business Domain Layer

C#

Data structure and algorithm design

Code Warehouse

Details, have time to come again slowly.

Live, always busy, never stop.