Theory vs. Practice

Finally, that's the email of Tak, a long-time G-WAN friend, which gave me the idea that made it possible for G-WAN to support PHP.

---

The down-to-earth idea (the prehistoric CGI interface)

---

Tak asked me how to run an extern process from a G-WAN servlet and how to have G-WAN serve the output to remote clients.

Answering Tak's question, I started to wonder why this strategy could not be used to run PHP. After all, many PHP servers run an instance of PHP per request in order to achieve the concurrency that PHP does not support natively (not being thread-safe, it crashes).

At first glance, at least if you don't check the facts yourself, CGI sounds like a poor alternative to FastCGI – but in the real-life, with a multicore G-WAN, involving IPC (inter-process communication) via sockets (like FasCGI does it to query a persistent PHP process), is often a waste of time (CGI runs much faster, despite having to continuously reload the PHP process for each request!).

Why, how?

• In normal times: because the overheads of the PHP script to run might be smaller than the fastCGI overhead.
• In a multithread environment: because the PHP script will crash the thread-unsafe PHP runtime.

That started to look almost good: the design is atrocious, the means is crude, but, hey, this could work – and for the first time, knowing for sure if a PHP interface works would take very little of my time.

Animated by the pleasure of anticipating a likely result (G-WAN is serving scripts faster than others because it's a faster server), I prepared the stub code and an ab.c test, to see how well this very basic idea would work with the appropriate amount of threading.

---

Using PHP as a script engine

---

I have read that PHP runs best in Apache. I remember that on the (now defunct) G-WAN forum, it was tested with Nginx + PHP-FPM at 17k requests per second. In contrast, my attempts to run G-WAN with the PHP Embed library, using one single PHP thread (to avoid crashing the PHP runtime), were running at 170k requests per second.

I was ready to consider as a success anything (a) scaling with the number of worker threads and (b) surviving the [1-1,000] concurrency range with ab.c using weighttp and the 6 CPU Cores of my test machine.

But this unsophisticated strategy proved to run much better than expected (with a default Debian 6.0 64-bit PHP 5.3.3 installation):

G-WAN hello.php

First (good) surprise, PHP did not die despite being reloaded and re-initialized continuously during this 36 minutes and 57 seconds test.

The reported CPU & RAM usage were very low because the (many) PHP extern processes are not measured.

Third, the performance and the scalability were extraordinarily good, with PHP reaching 630k requests per second at concurrency 620.

Apache or Nginx "hello world" C modules can't even to do that!

The three much-slower requests at 151k requests per second are most likely to be due to an internal lock in the PHP runtime (the code is reloaded and recompiled for every request). This would be waved at the same time performance would be boosted at around 800k requests per second... if the PHP runtime was used properly as a thread-safe library.

G-WAN C, C++, C#, D, Java and Scala scripts do better (in the 800k range), but remember that here G-WAN is using PHP in the worse possible way (by invoking it as an extern process, and therefore not caching compiled code). In contrast, the other programming languages offer direct interfaces that allow to cache the pre-compiled code and to greatly limit the overhead involved in the transfer of their output – both things that are not allowed to PHP here.

---

Does Facebook's HipHop do any better?

---

Someone asked me the question. HipHop translates PHP into C++ which can then be compiled natively (instead of running byte-code in an interpreter). And the embedded HipHop server relies on libev which is probably faster than Apache. Out of curiosity, I installed the Ubuntu 12.04 pre-built package available from GitHub.

Other than that, I have found benchmarks claiming that HipHop provides a 5x boost as compared to plain old PHP:

Framework      Req/sec   Speed
------------   -------   ------
Regular PHP     15.10     100%
PHP + APC       46.90     310%
HipHop          77.01    510%

As we have seen that G-WAN boosts PHP by a factor 438, 88x more than HipHop, and doing so with the 'regular PHP' framework, I am not sure how or why HipHop, a subset of the regular PHP, should be used.

---

A PHP app. server which Scales?

---

The PHP interface used by G-WAN is 10 lines of code long. The request parameters (and any POST/PUT entity) are properly passed to PHP. But there's still code to write to have G-WAN pass its 'environment' variables to PHP. While trivial to implement, this will take time and there are surely other things that should be done that I ignore as I am not a PHP developer. This means that the current state of things, while fully-compliant since it does run the original runtime, is probably not (yet) a fully-featured PHP framework.

But, hey, never in history PHP has been seen flying so high... and for the first time PHP was given a chance to scale on multicore.

It means that if some among the PHP community (at least its users since Zend is not responding) collaborate with G-WAN then this PHP support will quickly surpass today's G-WAN crude PHP draft interfacing – in addition to already surpassing every server in existence in the (not-so-open) PHP ecosystem.

History will choose for you anyway: economic forecasts are rather unrosy – and this will not change any time soon.

Would you use a car that both wastes 99.9% of the fuel you buy and runs at 0.1% of the allowed speed?

Not me. And that's why I wrote G-WAN.