cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
435
Views
0
Helpful
4
Replies

Service total-reused-connection increasing despite "no persistent" set

Hi,

I've checked and double-checked all my rules using a given service (actually 5 rules) and they're all configured with "no persitent".

I've reset the service counters and I'm still seeing the total-reused-connections increasing for this service.

According to Cisco's "Load Balancer Configuration Guide", the total-reused-connections is "The total number of connections that were reused for multiple content requests during persistent connections."

BUT, persistency has been disabled on all content rule making use of this service !

Hence I don't understand what this means.

Any idea/help is welcome.

Thanks.

Arno

PS: the reason behind all this is strange behaviour/problems with our CSS and I'm digging as many information I can get from the CSS counters and statistics, but I need a clear understanding of these statistics to diagnose what the problem might be.

1 Accepted Solution

Accepted Solutions

Arno,

yes, the re-use refer to the connection on the back-end and this backend connection can only be associated with one front-end connection.

Persistence is a feature of HTTP/1.1.

Breaking persistence is interesting if you have a proxy connecting to your CSS and you are doing cookie stickyness.

Since the proxy can send requests from multiple client into a single connection, it is important to check the cookie for every reqyest. If the cookie is different, with 'no persistent' we will do a remap on the backend.

If the cookie is the same, there is no need for a remap and the counter you mentioned will increase.

Gilles.

View solution in original post

4 Replies 4

Gilles Dufour
Cisco Employee
Cisco Employee

Arno,

the CSS will reuse the connection if there is no reason to switch to another one.

So, even if you have configured 'no persistent', if the request does not match a different server, the CSS will reuse the same server.

For troubleshooting CSS issues, the best option is to collect simultanous sniffer trace on the client side and server side.

Multiple failures should be captured to confirm if there is a pattern and from there we can decide if this normal or not.

Gilles.

Gilles,

Many thanks for your answer. Just to dig this a little bit more and improve my understanding:

1. This total-reused-connection regards back-end connections only, is this right ?

2. If YES then, can this backend connection be re-used to serve different clients, OR, is it associated to a "flow" and in this case should serve only one client ?

Also, the behaviour you're describing seems to me like the rule "persistence criteria" explained in this document "http://www.cisco.com/warp/public/117/ServiceRemapping.html" and I then don't see the difference between "no persistent" and "persistent" rule if both of them tend to re-use the backend connection as long as the criteria "does not match a different server" is met.

Does it have something to do with HTTP/1.0 vs HTTP/1.1 where several requests can be made on the same TCP connection ?

If I understand correctly, if HTTP/1.0 is used, the TCP connection is torn down after each content requests, hence the corresponding flow is torn down as well and as a result the backend connection should be torn down as well (unless used to serve another client request)

I'm a bit lost :-)

Thanks in advance,

Regards,

Arno

Arno,

yes, the re-use refer to the connection on the back-end and this backend connection can only be associated with one front-end connection.

Persistence is a feature of HTTP/1.1.

Breaking persistence is interesting if you have a proxy connecting to your CSS and you are doing cookie stickyness.

Since the proxy can send requests from multiple client into a single connection, it is important to check the cookie for every reqyest. If the cookie is different, with 'no persistent' we will do a remap on the backend.

If the cookie is the same, there is no need for a remap and the counter you mentioned will increase.

Gilles.

Merci Beaucoup | Thank you very much !