Unknown Timeout under Win in. NET Core Migration Sleeping Pool Sequel

Time:2019-8-2

Following the previous episode, which talked about the various problems encountered and worked out n solutions, especially the solution for Problem 4, for switching over the HttpClientFactory

I used your home NETCORE 2.1 under the special solution before HttpClient mouth disease has been a panacea for a long time, full of confidence on the line. And then hang up. It’s time to continue overtime.

The odd thing about this is that timeouts are concentrated on two machines (commonly known as two brothers).

Because we don’t know what caused the truth, and then it’s May Day again. In order to celebrate the great and arduous task of May Day, and to prove the great glory of migrating core is correct, how should we solve this problem?

Step 1, confirm the recurrence of the problem

First, give up the idea of reproducing in any test environment directly, because before testing HttpClientFactory, many batches of scenarios have been tested in the test environment, no matter long-term low voltage, long-term high voltage, short-term high voltage has ever happened.

And even on-line, there’s a problem with two machines.

So let Operations and Maintenance provide ip, point to this server, and use superbenchmarker to pressure it.

This is found in the pressure measurement. It’s very stable.

Stable for 5 minutes, hang up for 2 minutes

The green line is the number of RPS requests per second, and the purple is the response time. When the green line is stable for 5 minutes, it will suddenly disappear (the request is stuck). After 2 minutes, the purple line will suddenly burst (the long-awaited request finally responds) and the green line will rise again (the request returns to normal).

Step 2. Identify what happened when the timeout occurred

The next day, the pressure test was done, because it was confirmed that every five minutes it would be two minutes overtime, waiting for about four minutes to run to Opviana and sit down to see what happened during the overtime.

Then I despaired.

Conventional things like CPU / memory are all right, considering the historical flaws of HttpClient. I have also paid special attention to port numbers and so on, and everything is normal.

Step 3: How come there is no problem with the Framework before the migration? Is it Core’s pot?

To prove this, two consoles were prepared

Call an external interface every 100ms using a static HTTP Client under a Framework

Using HttpClientFactory under a Core also calls an external interface every 100 ms

The result is the square of my despair.

The results show that everything works well under the Framework, only Core has problems.

Subsequently, several Core versions of console with different postures were added for testing.

Include

1. SetHandler Lifetime is set to InfiniteTimeSpan

2. New a static HttpClient without HttpClientFactory

It’s still going to run out of time.

Because Google on the Internet did not find a similar statement

The inner thought at this point: Am I going to reverse the wheel of history (Am I the only one with a problem? Or is there a problem with my posture? How can everyone else be okay? Is everyone else fake? All the blows on the Internet are blind BB? All kinds of grass-mud horses gallop past.

Willows are dark and bright. Find organizations when you are in despair.

Then it sends out a distress signal in a group of micro-messengers.

Finally, we got a scheme that looked a little reliable.

(The content in the screenshot,)

Text Description: Set UseProxy to false when creating HttpClient. The default value is true.

Then, using this modification and testing it with a console package, the results are finally promising.

Because according to the previous rule, it will hang up for 2 minutes every 5 minutes, and can live for 10 minutes, which basically proves that the modification is effective.

Following this, the site was modified to use Proxy = false and packaged for pressure testing.

Running for several hours, so far there has been no problem of overtime again, now the basic real hammer problem has been solved.

Final summary

Whether you’re a new static HttpClient or creating HttpClient through HttpClientFactory, remember to use Proxy = false (unless you use proxy, of course).

Of course, I’m not too sure about the last few doubts.

such as

Why is there a constant problem with two machines on the line?

Other machines are more stable (nearly 30 servers on the actual line)?

Why is the timeout 2 minutes after 5 minutes steady (where is this 5 and this 2 set)?

What role does UseProxy play here?

The group of small partners gave such an explanation.

But I still don’t quite understand T-T.

The world of Net is really vast and profound.

summary

The above is an inexplicable timeout under Win, the sequel of. NET Core’s migration and reclining pit. I hope it will be helpful to you. If you have any questions, please leave me a message and the editor will reply to you in time. Thank you very much for your support to developpaer.
If you think this article is helpful to you, you are welcome to reprint it, please indicate the source, thank you!

Recommended Today

Implementation of PHP Facades

Example <?php class RealRoute{ public function get(){ Echo’Get me’; } } class Facade{ public static $resolvedInstance; public static $app; public static function __callStatic($method,$args){ $instance = static::getFacadeRoot(); if(!$instance){ throw new RuntimeException(‘A facade root has not been set.’); } return $instance->$method(…$args); } // Get the Facade root object public static function getFacadeRoot() { return static::resolveFacadeInstance(static::getFacadeAccessor()); } protected […]