Slashdot Mirror


Is Apache 2.0 Worth the Switch for PHP?

An anonymous reader writes "It seems like some of the members of the Apache Software Foundation are a little angry with the PHP Community because they don't recommend using Apache 2.0 with PHP. Since PHP is installed on half of all Apache servers this is a major issue for them. A number of high-profile PHP community members such as John Coggeshall and Chris Shiflett have blogged about this decision in light of a recent posting by Apache Software Foundation Member Rich Bowen which called PHP's anti-Apache2 stance FUD. Is there any real reason for the PHP community to start recommending Apache 2.0, especially when the 1.3.x series of Apache is rock solid and proven? Note Rich did later commend PHP for being a great product, so it's not all flames."

16 of 465 comments (clear)

  1. FUD in it's purest form ... by Sonic+McTails · · Score: 5, Informative

    The problem that PHP can be linked against non-threadsafe libraries, and this causes issues with Apache 2 when it's using the Worker MPM. However, if PHP died and takes the thread with it Apache simple restarts it. I had Apache2 and PHP in this configuration for almost a year, and expect for threads randomly restarting because of PHP, I had no issues. If you want to solve the thread problem, change the MPM to prefork (which is the default last I looked), which emulates the Apache1 behavior, and stops that problem.

    --
    This signature was left intentionally blank.
  2. Re:It's a threading issue by TheTomcat · · Score: 5, Informative

    All due repect (and I have a lot of it), but:
    Either PHP itself, or many PHP applications, are not written to deal with the multi-threading offered by Apache 2.0.

    That's just plain not true. The underlying threading problem has little to do with PHP, and absolutely nothing to do with PHP applications, but libraries to which PHP links (libmysqlclient, libpdf, libmcrypt, etc etc etc). It's these third-party libraries (over which the PHP developers have no control) that cause Apache2 to be unstable in the various threading modes (prefork works fine, but is just not officially supported).

    S

  3. Slashdot uses Boa for images by Tim+Macinta · · Score: 4, Informative
    I beg to differ. Apache 1 or 2 for that matter is no where near the maximum performance level when it come sto serving static content. As projects such as thttpd, tux, boa, lighttpd and many others clearly demonstrate. In fact the performance of Apache 1/2 is no where near what the solutions I've mentioned offer.
    Quite true. I've improved the performance in the past of a very high traffic website by switching what content I could from Apache to Boa. Boa performed substantially better than both Apache 1.3 and 2.0. If you need further evidence, look at the HTTP response headers for one of Slashdot's own images - they are serving images using Boa instead of Apache for a reason.

    This isn't to say that Apache is worthless. On the contrary, it is an exceptionally good server. It just doesn't scale as well as some others for static content.

  4. Re:Why are there two?? by Anonymous Coward · · Score: 5, Informative
    I checked the front page of Apache and there were release announcements for the latest version of both lines. Neither announcement carried a statement indicating when you should use it over the other.

    It's on the download page:

    "Apache 2.0.52 is the best available version"

    "Apache 1.3.33 is also available"

    The message would appear to be '2.0.52 is the best, but if you insist you can get a lesser version'.

  5. Re:Why are there two?? by rbowen · · Score: 5, Informative

    It's very simple. We want people to move to 2.0, but since people have not done so, we're not going to leave them high and dry.

    --
    Apache guy, Open Source enthusiast, runner
  6. How many hits? by dsb3 · · Score: 4, Informative

    I sustain 5 million hits per day on an Apache2+PHP server that (for me) indicates it's a "do-able" platform to run with.

    --

    Slashdot? Oh, I just read it for the articles.
  7. Re:It's a threading issue by Bruce+Perens · · Score: 5, Informative
    No problem with the respect, this is an area in which I don't have tremendous expertise. But I submit that if PHP itself is in charge of its interface to a non-thread-safe library, it can put a lock around calls into it - effectively single-threading each library and that would perform at least as well as going to a less efficient threading model for apache, and potentially better depending upon where contention happens. And given that this is Free Software, thread-safe successors of those libraries can be developed.

    Bruce

  8. Re:It's a threading issue by pthisis · · Score: 4, Informative

    Most of the benchmarks I've seen for Apache 2.0 on linux have been pretty ambivalent; the prefork MPM is generally better at ramping up to handle large numbers of connections, and serves more reqs/sec under high load, while the worker MPM serves large numbers of requests to small numbers of connections more efficiently. But those numbers seem to fluctuate based on the application and the number of processors used, and I've seen some applications where one model was nearly twice as efficient as the other--and I've seen that big a difference work in favor of both models, for different apps (which probably points to some MPM-specific design decisions in that particular application).

    As always, the decision over whether to use threads or processes should be based primarily over whether you want to give up protected memory within your application or not (unless you're dealing with a platform like Windows where the process model simply isn't flexible enough to avoid throwing memory protection out the window).

    --
    rage, rage against the dying of the light
  9. Re:It's a threading issue by Bruce+Perens · · Score: 5, Informative
    It's because there are potentially random problems because of two threads writing the same data at the same time. Code that depends on the value of a global variable not changing from one line to the next might break. Imagine that you increment a variable and then assume that its value is one greater than before, but it's really two greater.

    To their defense, the PHP folks say the problem is with libraries they don't control. But there could be a thread-safe PHP interface to them.

    And I guess the bottom line is that they don't want to keep answering questions about this, so they just say don't upgrade to Apache 2.

    Me, I use Zope. I think it's always been multithreaded.

    Bruce

  10. Efficiency is not entirely a web server function by Bruce+Perens · · Score: 4, Informative
    For most web servers on Linux, once the server has figured out what static file to send, it calls sendfile() and the rest of the work is entirely in the kernel until the file has been transmitted. On certain network cards, sendfile() has the property of being able to DMA from the disk to the network card without intermediate buffers. At least for big files, this is probably running very close to the hardware limit. For small files, the server efficiency is more of a factor.

    Bruce

  11. Re:Apache 2.x memory model is bizarre by Bruce+Perens · · Score: 4, Informative
    Consider that this could be a speed vs. space tradeoff. They are inefficient in terms of memory use. However, it's nice to have memory that is private to a thread such that only that thread accesses the entire memory page. That means that the caches and the TLBs don't invalidate as often because some other CPU has touched the data. Remember that in a multi-processor system the cache and TLBs have to watch what is happening on the bus, and invalidate themselves when they see someone else do a write to some data that they hold. Given that we have really fast processors and slow memory, this can get expensive.

    Bruce

  12. Re:PHP used to be an ASF project by Matt+Perry · · Score: 4, Informative

    IIRC, it was a license issue. The AFS wanted the PHP project to switch to using one of the ASF licenses while the PHP folks did not. PHP is still listed as a sister project. It's just not under the official ASF umbrella.

    --
    Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
  13. Re:PHP used to be an ASF project by Ath · · Score: 4, Informative

    No, the PHP folks specifically tell you not to run PHP with Apache 2.0. It is in their FAQ on their website.

  14. Re:PHP used to be an ASF project by killjoe · · Score: 4, Informative

    What seems to be lost in the noise is that PHP guys are not saying there is anything wrong with apache2. They are acknowledging that not all the extentions in PHP are thread safe.

    In other words it's PHP at fault and not apache2 and they are admitting it.

    --
    evil is as evil does
  15. Re:It's a threading issue by pthisis · · Score: 4, Informative

    You raise an excellent point. If the data you are serving up is highly sensitive then you are better served by the forking model which has a process wall between the data in your HTTP connections. You never know what kind of bugs a module will exhibit in a multithreaded scenario.

    Absolutely. But it's not merely protecting sensitive data--OS architects worked hard for years to implement protected memory, and threads circumvent a lot of those gains (a bug in one thread can affect them all, all memory access needs to be synchronized, etc).

    There are good times to use them, but the choice should be based on whether you need to share all (or most) of the memory as opposed to sharing little or none (when processes, possibly with shared memory segments, are the correct choice).

    Too many people think that somehow "threads are faster" when (excepting egregious disparities a la Windows) that isn't necessarily true--and even when it is, the performance benefits are often tiny compared to the costs you pay.

    --
    rage, rage against the dying of the light
  16. this is untrue. by vena · · Score: 4, Informative

    from the docs:

    Do not use Apache 2.0.x and PHP in a production environment neither on Unix nor on Windows.