Hello everyone,

I have some clients that need phpexpress. I recently switched to Apache 2 worker and I can't seem to make php express work anymore.

I have php 5.2.9
Centos 5.2

In php.ini I have set:
extension=phpexpress-php-5.2.so

The error I get is:
PHP Startup: Unable to load dynamic library '/usr/local/lib/php/extensions/phpexpress-php-5.2.so' - /usr/local/lib/php/extensions/phpexpress-php-5.2.so: undefined symbol: executor_globals in Unknown on line 0

Can anyone help me on this issue ?

Thank you!

PHP is not threadsafe. It depends on many 3rd party libraries which are not threadsafe.
Please do never use Apache Worker mode with PHP loaded as Apache module or you'll get sporadic crashes under sufficiently high load.

Php loaded as CGI/FastCGI will work fine with Worker, but it doesn't have to be compiled with threadsafety turned on.
That's why we don't provide PhpExpress for unix/linux platforms with threadsafe turned on. It just makes no sense.

thank you for your answer.
I know about the issues that appear when running Apache with worker and php as a module, I did not know that phpexpress does not come with a threadsafe version, I will switch to FastCGI.

May I ask you why you tried to install this combination?
I know, people who care of php performance are often trying various combinations... But can't get why thread"safe" is that attractive
Its safety is just a myth, so even php.net posted a warning http://www.php.net/manual/en/faq.installation.php#faq.installation.apache2

well I am running a worker apache for 2 days now without any seg faults. I choose this because of performance.

Regarding performance, do you have real numbers? I mean performance in for example number of requests that your server can handle with adequate number of concurrently connected clients.

Regarding stability, it's just matter of server load and time. Try to load your web with 5-10 concurrently connected clients, make sure they are usign keep-alive HTTP/1.1, run them with different URLs, and pretty soon you'll see that php is not that stable when it works under multithreading Worker. It's not because of PHP core itself. The core it's almost threadsafe (which is not proven btw), but the extensions using 3rd party libraries which are known to be threadunsafe.

well the server tested has about 70-80 concurrent connections with keepalive. KeepAlive could not work before because of too many apache processes for example. I do not have real numbers yet but it's obvious that a bunchs of threads work better than some processes. I know that the php core claims to be thread safe and for now everything tested worked ok. I was having a lot of segfaults at first but that was because of eaccelerator that was replaced with xcache, everything else seems ok for now. Anyway I am going to try worker with fastcgi and see what happends.

70 or 80 concurrent connections tells almost nothing about performance. What is the number of requests that your server processes in a second? Then divide this by number of connections and you'll get number of request in second per connection. Then compare the value with apache configured as PreFork case.



depends on extensions used.

yes, there are a lot of extensions that are unusable and others that claim to be thread safe when in fact they are not. Overall, having 1 little website will not justify the switching from prefork to something else. My problem is that I have hundreds of websites on one server and I am tired of this setup, prefork must be replaced, that is why I am looking at other methods of dealing with the load except buying/upgrading the hardware.

Seems what you need is perfromance under heavy load that would ideally be the same as performance without load. The common term that describes this is known as scalability. For example if your server can handle 2000 requests per second with one connection and 2000 requests pre second for 200 connections (10/sec for each in average), it'd mean that the scalability is ideal. From my experience, if you try to draw chart Total# of requests vs number of concurrent connections, you'll get horizontal line (100%) that propagates to some certain number of connections and then quickly (or slowly) degrades. Take number of connections that corresponds to 70% and focus on this. Continue running the tests with this number of connections and try to determine what is the bottleneck. Sometimes it's CPU, sometimes HDD, sometimes it's amount of memory. You may want to attach strace utility to all httpd children processes and check what they are actually doing. You'll see all the kernel calls with high-granularity timer. By knowing the bottleneck you can think about partial hardware upgrade, not replacement. For example if it's amount of memory (too much swaps), you may want to add extra modules. If you already have 3-4GB, you may want to switch to 64bit OS to get all the installed RAM used, if it's HDD, you may want to replace disks with higher capacity (they often have better performance because of data dencity) or better rpm, group 3-4 disks into raid5 array, and so forth. Also, don't forget about all php configure and run-time settings, such as always overseen ZEND_MM_MEM_TYPE, ZEND_MM_SEG_SIZE, ZEND_MM_COMPACT, USE_ZEND_ALLOC environment variables. BTW USE_ZEND_ALLOC=0 is what I'd start all the checks.

After you find and fix the bottleneck, re-run the tests, draw the line, and look for the new bottleneck


Anyway, I would not play with things that are known to be unstable (such as PHP under Threaded Worker). Even after the stability is announced, I'd wait for 6month or more Maybe it's just my conservatism.
If you believe "thread-safe" PhpExpress would help you, please contact me by email or pm and I'll do my best to help. On the other hands, I'd like to see "numbers" with and without

I am starting to hate the internet. Maby I am looking the wrong way and I sould start with the docummentation.
I haven't heard about ZEND_MM_MEM_TYPE, ZEND_MM_SEG_SIZE, ZEND_MM_COMPACT, USE_ZEND_ALLOC, USE_ZEND_ALLOC and I am glad I did, even now.
I have always believed that searching the internet for "php performance" will only give 5% good answers and the rest will be just copy&paste and useless information and I guess I was right.
Thank you for the tips above I will look into it.
I am not convinced that thread-safe is the solution yet, I am only testing because there are so many opinions on the internet that it's almost impossible to be sure of something. Right now what bothers me a lot is the realpath issue. I have straced httpd and built statistics and tried to reduce the number of system calls as much as I could.
So far an important difference I have seen with and without thread-safe is the fact that Apache will server a lot of websites faster since a lot of requests are for static content, that is why some folks use nginx for static content, but that is not a "safe" solution yet, it's just like my experiments with worker, there are always some problems
Thank you for your help so far, If I will have problems and I will need help I will contact you.

Correct. Either multithreading apache or lightweight without any huge code in all the modules web server will do.
As of PHP, it's not that obvious. If you try to optimize performance in non-loaded case (1 connection at a time) you'll end up with php cache and php loaded as module. If you try to optimize performance for max. loaded case (50%-70% degradation in perfomance as I mentioned before is a good point to focus on), you may end up with no caches at all, leaving all possible memory to OS to have disks and filesystem cached better and may be php loaded in FastCGI pool. At least it makes sense if most of the request are against plain files (html, js, css, images, other non-php).



I think, they were not discussed because Zend didn't even plan to document them.
Just fyi, Zend uses a kind of cache for memory blocks. When PHP VM releases a memory block, Zend's memory manager don't return it to the OS. Instead, it adds the block to the internal list of free blocks and will return it next time a block of the same size is requested. It works very good on a relaxing system, when a lot of memory is available and only a few processes are active. On a heavily loaded system, it may make more sense to release all non-needed memory to OS immediately.

I'd highly appreciate if you run tests and provide the results