CSM : Slow Start not working with leastconns predictor

[yves.haemmerli]

In my configuration, I have 2 real servers. The serverfarm is configured with "predictor leastconns slowstart 60". The current REAL_SLOW_START_ENABLE variable is set to its default value of 3. To test the slow start feature, I suspended on server and established 50 sessions on the working server. Then, I reactivated the first server and sent 50 new sessions. I observe that all new sessions are established on the "new" server ! the second server has still 50 sessions. The slow start seams not to be working...

What is the exact algorithm of the CSM with this setup (variable = 3 slowstart = 60) ?

Thank you

Yves Haemmerli

[Gilles Dufour]

is this still you're 2.1(2a) CSM-S ?

Did you send your new 50 connections all within 60 sec after enabling the server or after ?

What if you increase the slowstart timeout to 600 instead of 60 ?

Also, was there any active connections on the server before you turned it down ?

If there is an active connection, slowstart does not kick in.

What is interesting is that once again I tried to reproduce your scenario and once again everything is fine for me :-)

Connections were sent to the first server and then a few to the 2nd server and finally after 60sec they all went to the 2nd server.

The slowstart algorithm assigns the average number of connections to the newly activated server. These are dummy connections.

So, the new server looks as if having the same number of connections as the other servers.

The dummy_connections counter is decremented slowly until it reaches 0 or the timeout expires.

I'll try to verify this in the code just to be sure.

Gilles.

[yves.haemmerli]

Hi Gilles,

It seems that your CSM is more cooperative as mine ;-).

So to be sure that the CSM itself is not in question, I did the test on another CSM with only two servers in the serverfarm (instead of 8 as in the original case). Yes, the version of the CSM-S is still 2.1(2a). Yes the new sessions have been sent within the slowstart window. The same is observed when the slowstart timer is set to 600 actually. No connections were established on the first server at the time of its reactivation.

To document this problem , I attached a file showing all relevant configuration elements and a sequence of show commands demonstating the sessions ramp-up when the 50 new sessions are sent. In addition, I give you at the end of the attached file, the TCP script I use to generate session from my PC. I don't think that it is the problem however.

Thanks again Gilles for your support, it great. We are in trouble with this issue, which prevent us to put our Global portal in production...

Yves Haemmerli

[Gilles Dufour]

not sure what happened, but I started seeing the same problem with your script, so went back to my own to see what was the difference, and my script also shows me the same thing now. ??

Not sure what I did the first time.

Anyway, I'm still investigating.

Gilles.

[yves.haemmerli]

Gilles,

Thank you for your investigations, this is very stange that you got the same problem after a successful test... I investigates also, please let me know if you have some new info on this.

Thank you for your support

Yves

[Gilles Dufour · Accepted solution]

Yves,

set the following variable to 1 or 2 and you should see better result with small number of connections.

REAL_SLOW_START_ENABLE

Here is what I get with a value of 1

gdufour-cat6k-2(config-slb-real)#do sho mod csm 3 real | i LINUX1

L1 LINUX1 8 OPERATIONAL 5

192.168.30.27 LINUX1 8 OPERATIONAL 95

This is because the algorithm will assign a number of fake connections to the slow-start server. This number of connection is divided by 2 the power of this variable.

Gilles.

[yves.haemmerli]

Gilles,

I tested with REAL_SLOW_START_ENABLE 1 and 2. I got acceptable results now. Thanks again for your great support.

Yves Haemmerli