Slow performance on first connection

[dav...@indellient.com]

Hi all,

When I use Guzzle to connect to either a local API or network API, the results are similar. When hitting the API straight through using CURL, response time is reasonable at 50ms. However, using Guzzle, the very first connection takes nearly a full second. The bulk of the time, according to profiling is split between Client->get and Request->send(), each at about 300ms. After the initial hump, additional fetches are sent at around the 50ms benchmark.

Am I missing some configuration options (currently using default)? Or is this a sacrifice that other users experience?

I've seen and tried things like command.disable_validation, but there were extremely minor improvements in overall performance. Again - I stress that this is only on the first connection.

I'm running on Windows 7. PHP 5.3.19.

[Dowling, Michael]

When you say curl connects in 50ms, are you using the curl_multi or easy API? Guzzle uses the multi API, so be sure to compare apples to apples.

It's doubtful there is anything you could configure outside of curl to speed things up by a second. This is almost certainly a cURL configuration issue. Are you connecting to a server on the same machine or a sever with an extremely low latency? Have you tried applying http://curl.haxx.se/libcurl/c/curl_easy_setopt.html#CURLOPTTCPNODELAY?

--Michael

--
You received this message because you are subscribed to the Google Groups "Guzzle - PHP HTTP client and REST client framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to guzzle+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[David Found]

Hi Michael,

Yes - I have tried TCP NO DELAY, since the connection is to the same machine. I was previously not using curl_multi, but just changed to support this and cURL is still performing at expectation - approximately 50ms.

Based on my profiling dump, even the call to RequestFactory->create takes 158ms, the bulk of which is just loading classes and instantiating them. I am currently running Guzzle through the phar file, but I have also tried to extract it, but again to no avail.

I will continue to investigate, but if no one else is experiencing these first connect issues, I'll take it as an environment issue which I'll either deal with or move on. For the record, I moved code over to a staging server (Windows 2008 R2) and same results.

Thanks,

Dave

--
You received this message because you are subscribed to a topic in the Google Groups "Guzzle - PHP HTTP client and REST client framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/guzzle/ulzt8ZHQ2nM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to guzzle+un...@googlegroups.com.

[Dowling, Michael]

158ms is a pretty big delay. I haven't seen a perf hit like that before, but I've never profiled Guzzle or any other framework's autoloading on Windows. I suspect that the 158ms delay could be sped up by utilizing an opcode cache. I don't believe that APC caches phar files, but Opcache from PHP 5.5 does. Are you using an opcode cache?

--Michael

[dav...@indellient.com]

No - not at the moment. I'll do some further tweaking and playing with my environment as timing permits.

Thanks for the insight though.

[dav...@indellient.com]

Well - issue resolved. Guzzle is amazing. Here's a tip for anyone else out there experiencing similar issues - don't use your own code!

I realized I hadn't directly tried the Guzzle example, so I did and it was fast! Great news. After further investigation, I found out the culprit was a custom autoload function that I wrote. Since Guzzle presumably loads a lot classes - be sure your autoload function doesn't kill the performance.

Thanks to Michael for being so helpful - and I really do apologize. I hate when it ends up being something like this. And I should have known this prior to posting since no one else was having first connection issues.