0

I have an Apache server with 16GB of Ram. The script cap.php returns a very small chunk of data (500B). It starts a mysql connection and makes a simple query. However, the response from the server is, in my opinion, too lengthy. I attach a screenshot of the Developer Tool Panel in Chrome. enter image description here

Beside SSL and the TTFB there is a strange delay of 300ms (Stalled). If I try a curl from the WebServer:

 curl -w '\nLookup time:\t%{time_namelookup}\nConnect time:\t%{time_connect}\nPreXfer time:\t%{time_pretransfer}\nStartXfer time:\t%{time_starttransfer}\n\nTotal time:\t%{time_total}\n' -k -H 'miyazaki' https://127.0.0.1/ui/cap.php

Lookup time:    0.000
Connect time:   0.000
PreXfer time:   0.182
StartXfer time: 0.266

Total time:     0.266

Does anyone know what that is?

gdm
  • 7,647
  • 3
  • 41
  • 71
  • If your cap.php establishing connection to mysql and runs a query for each request then this delay can be expected I think, To confirm this is try to calculate the time taken by your PHP to connect to mysql and fetch data. ref here : http://stackoverflow.com/questions/1200214/how-can-i-measure-the-speed-of-code-written-in-php – kakurala May 03 '16 at 16:31
  • I also tried to jump over the query, for example just sending "hello". Same result: the stalled phase remains. – gdm May 03 '16 at 16:55
  • Then it could be network, try to get `cap.php` with Wget or CuRL command in same server itself, if you are seeing same delay then your configuration need to be tweaked a bit. – kakurala May 04 '16 at 08:49
  • I made a test with curl. The total time is similar. I think is a problem related to SSL, isnt'it? – gdm May 04 '16 at 13:01

2 Answers2

0

Eventually, I found that if you use SSL it is really better and it does really matter to switch on the KeepAlive directive into Apache. See the picture below.

enter image description here

gdm
  • 7,647
  • 3
  • 41
  • 71
  • So the screenshot in question is without `keepalive` enabled and the screenshot here is with `keepalive` on ? but am wondering how does a single request make much difference here. – kakurala May 04 '16 at 14:23
  • becuase I think you are under ssl. If there is an error in the SSL handshake (think of CNAME mismatch) the connection is reopened.Checked with chrome://net-internals/#events – gdm May 04 '16 at 15:16
0

According to the Chrome documentation:

Stalled/Blocking

Time the request spent waiting before it could be sent. This time is inclusive of any time spent in proxy negotiation. Additionally, this time will include when the browser is waiting for an already established connection to become available for re-use, obeying Chrome's maximum six TCP connection per origin rule.

So this appears to be a client issue with Chrome talking to the network rather than a server config issue. As you are only making one request I think we can rule out the TCP limit per origin (unless you have lots of other tabs using up these connections) so would guess either limitations on your PC (network card, RAM, CPU) or infrastructure issues (e.g. You connect via a proxy and it takes time to set up that connection).

Your curl request doesn't seem to show this delay as it has just a 0.182 wait time to send the request (which is easily explained with https negotiation) and then a 0.266 total time to download (including the 0.182). This compares with 0.700 seconds when using Chrome so don't understand why you say "total time is similar" when to me it's clearly not?

Finally I do not understand your follow up answer. It looks to me like you have made request, presumably after a recent other request as this has skipped the whole network connection stage (including any grey stalling, blue DNS lookup, orange initial connection and purple https connection). So of course this quicker. But it's not comparing like for like with your first screenshot in your question and is not addressing your question.

But yes you absolutely should be using keep-alives (they are on by default in most web server so usually takes extra efforts to turn them off) and https resumption techniques (not on by default unless you explicitly add this to your https config) to benefit any additional requests sent shortly after the first. But these will not benefit the first connection of the session.

Barry Pollard
  • 40,655
  • 7
  • 76
  • 92