Server load calculation on CSS

[r.underwood]

With a CSS, according to the documentation, the service load is based on the time it takes to complete a flow from SYN to FIN.

Unfortunately, this doesn't represent the load on the server (for our application at least) as it takes very little time to generate the page - the bulk of the time is attributable to the connection speed of the client.

Because of this, the load is more or less random - depending on whether the clients are modem users, etc. This makes the aca load-balancing method next to useless.

Is there any way of getting the CSS to calculate load based on the time to first byte, rather than the time for the entire flow? This would track the load much more accurately.

Software version is 7.40.

Thanks,

Richard

[Gilles Dufour]

Richard,

there is no way to modify the load calculation to be what you want.

All load parameters can be modified from config with the command 'load ...'.

I personally would not recommand to use ACA but instead leastconn. If a server is getting busy, it would keep connections open longer and receive less of them.

Gilles.

[r.underwood]

Thanks for the reply. It's set to least-conns at the moment, but there's still a problem:

Server 1 takes 1 second to generate the page and between 6 and 30 seconds to deliver it to the client.

Server 2 takes 3 seconds to generate the page and also takes between 6 and 30 seconds to deliver it to the client.

Server 1 will hold the connection open for between 7 and 31 seconds, Server 2 by 9 and 33 seconds.

In this situation, Server 1 will only get (on average) 17% more traffic than Server 2, rather than 3:1 which might be appropriate given the page generation time.

Worse, because there's such a large variation in delivery time, the difference due to server performance gets lost in the noise.

I have the situation where Server 2 is sitting at 100% load churning out pages, while Server 1 is doing nothing for a large part of the time, except transmitting data (which doesn't require much at all).

Thanks,

Richard