Introducing libcurls multi socket API

So, finally a first beta of pecl_http 1.6 has been released.

This is the first version which supports libcurls multi socket API introduced in 7.16 through libevent.

Here's a not very impressive comparison of the performance of the traditional multi API vs. the new multi socket API:

mike@honeybadger:~/build/php-5.2-debug$ cli 
    ~/cvs/pecl/http/scripts/bench_select_vs_event.php 
    -u http://honeybadger/empty.html

>   1.134667s

mike@honeybadger:~/build/php-5.2-debug$ cli 
    ~/cvs/pecl/http/scripts/bench_select_vs_event.php 
    -u http://honeybadger/empty.html

>   1.151088s

mike@honeybadger:~/build/php-5.2-debug$ cli 
    ~/cvs/pecl/http/scripts/bench_select_vs_event.php 
    -u http://honeybadger/empty.html

>   1.131867s

mike@honeybadger:~/build/php-5.2-debug$ cli 
    ~/cvs/pecl/http/scripts/bench_select_vs_event.php 
    -u http://honeybadger/empty.html -e

>   0.993878s

mike@honeybadger:~/build/php-5.2-debug$ cli 
    ~/cvs/pecl/http/scripts/bench_select_vs_event.php 
    -u http://honeybadger/empty.html -e

>   0.998832s

mike@honeybadger:~/build/php-5.2-debug$ cli 
    ~/cvs/pecl/http/scripts/bench_select_vs_event.php 
    -u http://honeybadger/empty.html -e

>   0.997121s

Above empty.html is, well, empty. The following test requests a 100k file:

mike@honeybadger:~/build/php-5.2-debug$ cli  
    ~/cvs/pecl/http/scripts/bench_select_vs_event.php  
    -u http://honeybadger/100k.bin

>   2.205190s

mike@honeybadger:~/build/php-5.2-debug$ cli  
    ~/cvs/pecl/http/scripts/bench_select_vs_event.php  
    -u http://honeybadger/100k.bin

>   2.210525s

mike@honeybadger:~/build/php-5.2-debug$ cli  
    ~/cvs/pecl/http/scripts/bench_select_vs_event.php  
    -u http://honeybadger/100k.bin

>   2.254281s

mike@honeybadger:~/build/php-5.2-debug$ cli  
    ~/cvs/pecl/http/scripts/bench_select_vs_event.php  
    -u http://honeybadger/100k.bin -e

>   2.007220s

mike@honeybadger:~/build/php-5.2-debug$ cli  
    ~/cvs/pecl/http/scripts/bench_select_vs_event.php  
    -u http://honeybadger/100k.bin -e

>   1.945564s

mike@honeybadger:~/build/php-5.2-debug$ cli  
    ~/cvs/pecl/http/scripts/bench_select_vs_event.php  
    -u http://honeybadger/100k.bin -e

>   1.969575s

So, apparently time savings are not huge, but noticable.

Silence

It's been more than 3 months that I brought back to mind, what was happening in my PHP/HTTP/CURL world, so here we go.

February:

pecl/http with support for persistent handles has been released.

A proposal of mine at internals to change the behaviour of read_property/write_property and get_property_ptr_ptr object handlers has successfully been ignored.

The idea was the following:

---

Wouldn't it be reasonable for the engine to use get_property_ptr_ptr() whenever it wants to modify a property and get rid of using read_property() for write access?

That would make rather simple ops like concatenation, in-/decrementation etc work again with overloaded internal classes. Just make the engine use read_property() followed by a write_property() when there's no get_property_ptr_ptr().

---

Nobody was interested.

March:

I added a comparison object handler to the DateTime class, which means that comparisons of DateTime objects should work in recent PHP5 versions.

I started development of pecl/libetpan, but dropped it again because of pretty huge differences between how the library works and how PHP is supposed to work. What a pity.

A less fine guy, some Omid, wanted me to write a PHP extension which calculates the strength of "poker hands", but he jumped off when I had done the algos.

April:

A fine guy, pretending his name was Andreas Weber, noticed that pecl/http's request method implementation was completely b0rked. Thanks to his report it was fixed in 1.5.3.

All fame Lukas Smith, queried me about what might have changed with my new output layer implementation for PHP6, but I noticed too late that it's been for a conference talk he was preparing, so I feel like I didn't spend enough attention to his questions. Sorry Lukas.

I started to implement libcurl's new multi_socket AKA hiper API in conjunction with libevent, but stumbled across a few problems.

May:

My journey with libcurl's multi_socket API continues, which eventually causes the delay of a first pecl/http 1.6 release candidate.

I tried Drupal for the first time.

---

Well, that'd be it. If it reads like an extrusion of junk, it probably was. ;)

Phar vs World

Recent discussions about inclusion of pecl/phar into the core distribution shows again that we are missing a defined process of handling additions to the PHP main distibution. How many people are really reading through all mails of 100+ message threads?

It's going to be a chaos. Always. Once a developer has got his new, shiny and soon-to-be-world-dominating extension into the core, he'll be a even stronger advocator of the "no-new-extensions" camp. Not to disrespect any work, but this is pure rivalism, masculine--really!

The idea of moving extensions from core to pecl is honorous, but we all know the current problems of this ideology.

Many people have asked me when pecl/http will be included in the main distribution. My answer is short and simple: "Never" (I usually add a tiny sentence, but that's nothing encouraging either).

Ah... and please do me a favour: rather keep your comments to yourself :) (...or toss it into the nonsense thread@internals).

Two pitfalls in one afternoon

This is not my day.

<quote url="http://dev.mysql.com/doc/refman/5.0/en/fulltext-search.html">
words that are present in more than 50% of the rows are considered common and do not match
</quote>

RTFM! ;)

Apache MultiViews are evil

Suppose you've got a similar setup to:

RewriteEngine On
RewriteBase /

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule .* - [QSA,L]

RewriteRule ^network/?(w+)?$ network.php?path=$1

Apache will expand e.g. "network/foo/bar" to "network.php/foo/bar" which won't be expanded to "network.php?f=" because it --of course-- exists (RewriteCond -f).

Evil! :)

Upgrading to 5.2

So I finally came around to upgrade to PHP 5.2 (I was running 4.4 on the production server until now). I know, what a shame! :)

Anyway the only issue I really had, in spite testing the code really well over time, was with class_exists() and millions of warnings becaus of a missing __autoload(). I blame the people who introduced the second parameter to class_exists() and changing the default behaviour at the very same moment. Actually, it was an annoying but rather easy to fix compatibility brake.

APC in conjunction with PHP-5.2 seems to work very well either, it even feels a lot less memory exhaustive than running APC+PHP-4.

Ah yes, just on a side note, I also upgraded to Apache-2.2 in the same run. Somehow I now have a warm and fuzzy feeling running this up-to-date software, it really was already like a brinck in my stomach. Anyway, what's left is to migrate from the Apache module to the FastCGI SAPI and switching to the worker MPM... but I'm done already.

Something I didn't even know I was missing

$ php --ri extension

Nice.

HTTP, CURL and stuff

News, news, yawn.

Daniel Stenberg, head of the cURL project, accepted a patch for sub second time out support within libcurl. That means that you can use float values as time outs with a millisecond resolution, as soon as you use libcurl >= v7.16.2, that is, a minimum supported time out of 0.001 seconds (which is not reasonable, just in case you wonder). On a side note, you should build libcurl with c-ares to get working sub second DNS lookup time out support, AFAICT.

Clay Loveless, usually killing people softly with his random strings, mashing up APIs or providing compatibility libraries, kindly asked me, if there were persistent connection support in pecl/http.

Is there an option in pecl_http that I'm overlooking that would be the equivalent of STREAM_CLIENT_PERSISTENT?

I was already about to answer that libcurl already does that all for us, realizing that we destroy the used CURL handles at the end of each PHP request at the latest, thus killing any alive connections. This happened about two weeks ago, and pecl/http 1.5, of which RC1 had just been released, will support per process persistent CURL handles. It can be enabled at compile time only, as it's a quite intrusive feature. Yet I'm still unsure about the implementation of this feature and it might change in the future to become a bit more user-friendly.

To use it, there's nothing else to be done than tossing --enable-http-persistent-handles at configure.