High loading times in Apache Bench
I am testing slim as framework for a RESTful API. I love the
neat OO interface and clear documentation. There is however 1 issue
that is frustrating me.
Whenever I test a very simple slim app (for example the hello world
example) the loading time in the browser is blazingly fast, but
when testing the loading times with AB, I never get a loading time
< 5000 ms.
I ruled out several possible causes (autoloader, overhead from my own framework, checking a 200 is really returned, testing both from localhost as remote) but whatever I try the loading times are very very high.
I did google around, but didn't find anything. Any pointers are highly appreciated.
Keyboard shortcuts
Generic
? | Show this help |
---|---|
ESC | Blurs the current field |
Comment Form
r | Focus the comment reply box |
---|---|
^ + ↩ | Submit the comment |
You can use Command ⌘
instead of Control ^
on Mac
Support Staff 1 Posted by Josh Lockhart on 01 Feb, 2012 01:35 PM
That certainly seems odd as there really isn't anything that would slow Slim down that much by default. I'd double-check your AB flags when you run the benchmarks. Otherwise I'll defer to others on the forum who are more familiar with it.
2 Posted by M. Fischer on 09 Feb, 2012 04:12 PM
I have the same problem, here is my ab2 Result with the hello world example from the homepage:
3 Posted by M.Fischer on 09 Feb, 2012 04:39 PM
Perhaps this helps solving the problem:
Using the switch -k (Use Keep-Alive) helps to solve the problem, so I believe Slim has a bug, if no keep-alive is used.
The working command line:
Support Staff 4 Posted by Josh Lockhart on 09 Feb, 2012 04:44 PM
I found this thread on StackOverflow that may provide some further help. If you can narrow down what is causing the slow down I'll work on a fix.
http://serverfault.com/questions/254765/apache-benchmark-keep-alive
5 Posted by merlijn on 09 Feb, 2012 05:17 PM
Yup, i can confirm that. With the keep-alive option, loading times are as expected.
6 Posted by M.Fischer on 09 Feb, 2012 05:32 PM
I tried to find some clue by using an strace, both on client and on the server-process. Each process hangs in an epoll_wait and seems to wait for some input. The apache benchmark times are exactly the setting for the keep alive timeout (Apache 2.2.17 used).
In some way, Slim does not closes the output all right (other PHP-Apps and Frameworks behave better on the same server).
I tried to hack Slim in some parts, closing the output buffering or using a die(), but nothing solved the problem, so I believe, the bug has to be somewhere in the initialization.
Support Staff 7 Posted by Josh Lockhart on 09 Feb, 2012 05:47 PM
Slim will read from
php://input
to fetch POST/PUT request bodies (in Environment.php). Do you think that may cause the wait?8 Posted by M. Fischer on 09 Feb, 2012 06:01 PM
I've set the line to
but it did not help. With some further hacking by uncommenting header()-functions I found the buggy line in the function sendHeaders():
It seems, that the trailing space after the status code leads to this behavior, just removing the space solves the Problem, at least for status 200. But do not ask me, why this causes the problem ;-)
Support Staff 9 Posted by Josh Lockhart on 09 Feb, 2012 06:12 PM
Hmm... can you post the changed code that resolved the issue? I don't understand what you changed. The
sprintf('HTTP/%s %s', args)
will outputHTTP/1.1 200 OK
, which is correct. Maybe I misunderstand what you changed.Support Staff 10 Posted by Josh Lockhart on 09 Feb, 2012 06:29 PM
This problem may also be with Apache Bench... read this:
http://seancoates.com/blogs/http-1-and-the-connection-header
What happens when you send a
Connection: close
header with the request?Support Staff 11 Posted by Josh Lockhart on 09 Feb, 2012 06:34 PM
My own tests with a Hello World example:
And the results:
And the test WITHOUT sending the
Connection: close
header:The result:
12 Posted by M. Fischer on 10 Feb, 2012 09:15 AM
Sorry,
the working (but not useable) line is:
I just removed the space between the two "%s" placeholders. I believe, a real bugfix needs some further investigation of the problem.
13 Posted by merlijn on 10 Feb, 2012 09:24 AM
I've done some more testing, ruling out my own autoloading mechanism and XDebug as possible causes. The problem really seems to be the connection handling of ab. I am not a HTTP guru. Again, the problem doesn't exist in the browser or when accessing the script by Curl.
The 5000 ms is typical in my case, and very consistent... in other tests people are reporting for example 15000 ms. Sounds to me as an OS/Kernel specific tcp timeout value.
14 Posted by M. Fischer on 10 Feb, 2012 09:56 AM
I did not find the bug with other tools than ab2, either. In some way apache benchmarking has some problems with the header-line Slim sends, perhaps this is a bug in ab2 itself.
The timeout is the keep-alive-timeout, wich is set by the webserver. The server closes the connection exactly after the time as expected.
15 Posted by MarcosBL on 10 Feb, 2012 10:48 AM
My own try, i can't reproduce, Apache/2.2.17 Slim latest stable
No change with
nor with
Maybe ab version bug ?
16 Posted by merlijn on 10 Feb, 2012 10:52 AM
Same version of ab... different os maybe...
I am using freeBSD.
$ ab -V
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
17 Posted by MarcosBL on 10 Feb, 2012 11:02 AM
Ubuntu Server 11.04 here
Linux 2.6.38.2-grsec-xxxx-grs-ipv6-64
18 Posted by M. Fischer on 10 Feb, 2012 11:07 AM
Well, in the morning everything is a bit more clear... The space between is nonsense, causes a 500, but uncommenting the header-line works. Switching to HTTP/1.0 does the same, but we already know that keep alive has to do something with it.
19 Posted by M. Fischer on 10 Feb, 2012 11:10 AM
Testsystem:
openSUSE 11.4 (x86_64) with Apache 2.2.17 and Linux 2.6.37.6-0.9-desktop #1 SMP PREEMPT 2011-10-19 22:33:27 +0200 x86_64 x86_64 x86_64 GNU/Linux using PHP 5.3.5
20 Posted by MarcosBL on 10 Feb, 2012 11:17 AM
Forgot PHP version:
Support Staff 21 Posted by Josh Lockhart on 10 Feb, 2012 01:58 PM
I'm running the stock
ab
that comes with OS X 10.7.x.Also using Apache/2.0.64 with PHP 5.3.5.
I'm very confident this entire issue is due to
ab
mishandling the connection with the web server. I believe Slim is irrelevant in this case. For me, sending aConnection: close
header resolves the issue. So does enabling Keep-Alive withab -k
. So I'm recommending that you upgradeab
to a version that works for you or use an alternative testing tool likesiege
.Will leave this thread open more comments.
Josh
22 Posted by eko3alpha on 25 Mar, 2014 10:45 AM
I'm having this exact same issue! I was wondering what the heck was going on! Im on OSX 10.8.5
AMPPS
Apache 2.2
ab -V
This is ApacheBench, Version 2.3 <$Revision: 655654 $>
As you can see below the test is rather light! and I have a host record for dev.slim-app.com
Support Staff 23 Posted by Josh Lockhart on 25 Mar, 2014 01:20 PM
@eko3alpha As described above,
ab
has an issue with closing connections. Be sure you pass along an HTTP header with yourab
call, like this:-H "Connection:close"
24 Posted by eko3alpha on 26 Mar, 2014 12:40 AM
Wow, Im not sure how I missed that! Thanks! Here are the new results
25 Posted by Taleveteonext on 27 Mar, 2014 05:43 PM
comment_body
26 Posted by Oscar on 08 May, 2014 12:29 PM
I solved the issue by adding the following:
$app->response()->header('Connection', 'close');
... and finally;
$app->run();
I hope it saves your time.
27 Posted by Aaron on 22 Jul, 2014 06:38 PM
I've run into the same problem and I think it's caused by a mismatch between the HTTP version of the request and the response.
If you change (in Slim\Slim.php) the default value of
http_version
to$_SERVER['SERVER_PROTOCOL']
rather than'1.1'
and also change this:header(sprintf('HTTP/%s %s', $this->httpVersion, self::getMessageForCode($this->status())));
to this (just removes the 'HTTP/' as it's already provided from
$_SERVER
):header(sprintf('%s %s', $this->config('http.version'), \Slim\Http\Response::getMessageForCode($status)));
then responses will automatically follow whatever the request used.
Before this change all requests to Slim via ab or
file_get_contents()
were taking 5 seconds, now they are nearly instant. Browsers were fine for me either way, but I think that's because the ones I tried were using HTTP/1.1 already.Hope this helps.
28 Posted by razorness on 23 Jan, 2015 03:07 PM
If anybody does still have this problem:
Check if you create responses in a regular way Slim is offering. The problem is probably that you do not close your connection in a way that ab is understanting. To ensure this, read:
http://stackoverflow.com/questions/138374/close-a-connection-early?answertab=active#tab-top
The 5000ms is the timout ab waits.
29 Posted by xuhifula on 06 May, 2017 01:51 AM
High Loading time for site opening. http://leanbellysecret.com/
30 Posted by ulg on 06 Jun, 2017 02:44 AM
I am also having same problem of Apache Bench at Red Smoothie Detox Factor Review - Reviewprotocol