Forum Discussion

Sekhar's avatar
Sekhar
Icon for Nimbostratus rankNimbostratus
Feb 12, 2015

Slow page response acessing for first time

Hi, we have a web app running on windows IIS servers which opens instantly, but when trying through LTM it is taking around 3 min to open for first time only and opens immediately when accessed second time on wards.

 

I am having client side and server side SSL 's and cookie, src_addr persistence enabled to the VIP.

 

Please help me in troubleshooting this issue.

 

Thanks, Sekhar

 

application delivery
deployment
LTM
performance

3 Replies

  • StephanManthey's avatar
    StephanManthey
    Icon for Nacreous rankNacreous
    Feb 12, 2015

    Hi Sekhar,

    did you try to run a tcpdump to capture the traffic and see where it slows down?

    I guess after first request you will have keep-alive connections established which improves the browsing experience.

    Please run a trace as follows: 
    tcpdump -i 0.0:nnnp -s 0 -w /var/tmp/issue001.cap host

    Get the trace via SCP from /var/tmp/issue001.cap and load it into WireShark. Make sure to have the F5 WireShark plugin installed to decode the ethernet trailer data.

    Maybe you are using a WAN optimized TCP profile with the Nagl´s Algorithm enabled which uses to slow down things sometimes.

    Thanks, Stephan
  • Sekhar's avatar
    Sekhar
    Icon for Nimbostratus rankNimbostratus
    Feb 13, 2015

    Hi Stephan,

     

    We are using tcp profile on both client and server. I have tried capturing tcpdump and i am seeing a lot of tcp window full/tcp segment of a reassembled PDU's in the dump file. Could it a buffering problem?

     

    • StephanManthey's avatar
      StephanManthey
      Icon for Nacreous rankNacreous
      Feb 13, 2015
      Hi Sekharchandra, the TCP payload is segmented to fit into IP datagram. That´s why you see the "segment of a reassembled PDU" information. The "TCP window full" (information from WireShark) just indicates, that the sender makes use of the allowed window size. Both is fine from my perspective. Are you seeing messages in /var/log/ltm while observing the problem? tail -f /var/log/ltm Any indication for exceeded http header size there? You can try to test with lan-optimized-tcp profile. It is using increased window sizes and ramps up faster. You can look as well after delays caused on server side. Perhaps you are using SNAT and the server tries to resolve the client IP versus a reputation list? You can also try to apply a OneConnect profile which allows KeepAlive conversion and connection pooling both on client- and serverside. Thanks, Stephan