Website slow when stickyness added

[eamonconnolly]

Hello All

I have an ongoing issue where adding stickness to a vserver on our csm causes the website to take 3 to 4 minutes to load.  If I remove stickyness from the VIP then the website loads instantly.  We have tested this many times and get the same results.  Is anyone aware of an issue that would cause this sort of problem.  We have many other vips with stickyness enabled and have no probs which makes me think is something with the website or something networking between the load balancer and the server.  Does anyone have any suggestions of what may cause an issue like this.  I have done packet captures and things like that but they are not revealing anything at the minute.

If anyone has any suggestions they would be very welcome at this point as we are at a bit of a dead end.  There is currently only one server inservice in the farm, this is just for testing purposes and there normally would be a few.

Thanks in advance

Eamon

Here is the config

vserver PHQGWTEST

  virtual 10.7.30.50 tcp www

  vlan 830

  serverfarm PHQ

  sticky 120 group 43

  persistent rebalance

serverfarm PHQ

  nat server

  no nat client

  real 10.7.30.82

   inservice

  real 10.7.30.85

   no inservice

  real 10.7.30.141

   no inservice

  real 10.7.30.142

   no inservice real 10.7.30.82
   inservice
  real 10.7.30.85
   no inservice
  real 10.7.30.141
   no inservice
  real 10.7.30.142
   no inservice

  health retries 1 failed 30

  probe LNI.NET_PROBE

sticky 43 cookie LNI_POOL_SELECTOR timeout 120

[jlamousn]

Eamonconnolly,

When you add cookie sticky in the configuration, the CSM has to proxy the connection, parse the http request and perform Layer 7 load balancing.  With cookie sticky removed, the CSM does not parse the http layer, and simply load balances the tcp packets at Layer 4. There could be a number of issues causing the slowness. It would be best to open a TAC case for troubleshing this type of issue, we would need a sniff of the of the csm port-channel (See Attached Instructions) so that we can see how the traffic is entering and leaving the csm to identify the problem. Also before and after show tech would help identify any incrementing drop counters on the CSM. I would also run "show mod csm # tech-support processor 4" and look for any incrementing "LB Rjct: L7 max parse len" errors, this could indicate you may need to increase the default max-parse length for the vserver.

Joel Lamousnery

Cisco TAC - ANS