Forgot your password?
PHP Software Programming Apache

Is Apache 2.0 Worth the Switch for PHP? 465

Posted by michael
from the play-nicely-children dept.
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."
This discussion has been archived. No new comments can be posted.

Is Apache 2.0 Worth the Switch for PHP?

Comments Filter:
  • by hey (83763) on Tuesday December 21, 2004 @02:32PM (#11150744) Journal
    Anybody still running Apache1 on Windows is nuts.
    Apache2 works way better on Windows.
  • by Sonic McTails (700139) on Tuesday December 21, 2004 @02:33PM (#11150751)
    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.
  • by Sonic McTails (700139) on Tuesday December 21, 2004 @02:36PM (#11150787)
    Slashdot Mirror of Text: --- PHP's anti-Apache2 FUD My biggest objection to PHP is the anti-Apache2 FUD that they spread. Indeed, they seem to be the ones primarily responsible for the anti-Apache2 FUD. This is unfortunate, since there are few remaining legitimate reasons for avoiding Apache2, and it's a shame that they feel the need to manufacture one. So, to quote the PHP docs: Do not use Apache 2.0.x and PHP in a production environment neither on Unix nor on Windows. This is further clarified in the FAQ with a long description which starts, unfortunately, with a misconception, namely: The major feature that draws people to Apache 2 is threading. It then goes on to explain why threading is, potentially, a problem with PHP, why this is not, technically, PHP's fault, and so PHP cant fix it. All very correct, really. And, so, very logically, it concludes that there's no reason to move to Apache 2, and that everyone should stick with Apache 1.3. This argument suffers from one main flaw. That is, that the initial assumption, from which everything flows, is just plain wrong. Yes, threading is cool, and is a major shinyness with Apache 2. However, it is not, by any stretch of the imagination, the only, or even the main, reason for moving to Apache 2.0. There are a *lot* of other much better reasons for moving to Apache 2.0, none of which pose any threat to PHP. I've covered those in my OnLamp article, and so won't repeat them here. Apache 2.0, running with a prefork MPM, works great with PHP, and gives you all those other benefits. The additional benefit is a little more subtle. Apache 1.3 is becoming "legacy". Meaning that the real developers are focusing more on 2.0. The 2.0 docs are better. 2.0 (and 2.1) gets the new features, the documentation improvements, and the newly clarified directives and error messages. Thus, 1.3 becomes harder and harder to support. So, increasingly, the PHP questions are coming from folks that are running 1.3, and the solutions offered just don't work, because they are things added in 2.0 to solve exactly the irritations that these folks are having. So, I entreat the PHP folks to remove this incorrect anti-Apache 2.0 tirade from their documentation, and replace it with a more balanced and correct explanation of the issues involved, and the recommended solution. Namely, that people go ahead and move to Apache 2.0, but stick with a Prefork MPM. This gives them most of the benefits of Apache 2.0, but removes the irritating threading issues. Nobody blames PHP for those threading issues (at least, people who have taken the trouble to actually understand the issue don't), so there's no slight on the PHP developers implied here. I'd be glad to participate in this to any degree that you like. I actually enjoy writing documentation, and I'm increasingly using PHP for my own work. Please?
  • by Daeron (4056) on Tuesday December 21, 2004 @02:39PM (#11150826)
    I guess the only reason i can think of not to use PHP on Apache-2 ... is if you absolutely HAVE to use a threaded version of Apache-2.

    THe apache-2 (Worker MPM) itself is rock solid and definately seems to boost performance of ones http-server compared to traditional apache-1.3.

    I am not exactly sure about a prefork-MPM vs apache-1.3 comparison.

    The biggest problem with PHP on any threaded Apache-2 (i am not sure if this holds true for the 1.3 series as well) ... is the fact that PHP keeps continuously crashing your httpd-processes.

    Switching to the prefork MPM makes everything rock-solid again ... but looses the benefits the threaded-MPMs offer.

    If PHP could actually solve their problems with running in a threaded Apache-2 ... i would jump right on it :)

    Again .. i never experimented with a threaded apache-1.3 (not even sure if that's possible) ... but for Apache-2 with the current state of PHP .. it's not recommended ...
  • by cybermint (255744) * on Tuesday December 21, 2004 @02:40PM (#11150830)
    Apache 2.0 has proven to have so many new features that it was well worth the upgrade. Early on we encountered some minor issues with the threads, so we switched to pre-fork and have had no issues. We have been running PHP and mod_perl in pre-fork mode without a single issue for the last year. Unless you cannot switch because you use a module with no 2.0 support, I would make the switch immediately. And don't forget, you can always install both apache 1.x and 2.0 to give it a test run.
  • by TheTomcat (53158) on Tuesday December 21, 2004 @02:40PM (#11150838) Homepage
    Read the thread, here []

  • by jdew (644405) on Tuesday December 21, 2004 @02:42PM (#11150864)
    From what I've gathered, Apache2 is a reimplementation and 1.x is just in maintenence mode (security fixes etc)
  • by einhverfr (238914) <> on Tuesday December 21, 2004 @02:44PM (#11150892) Homepage Journal
    However, the issue is that many PHP extensions are not threadsafe. This becomes an issue on Windows because the default MPM is multithreaded, while the default MPM for UNIX is multiprocess.
  • by TheTomcat (53158) on Tuesday December 21, 2004 @02:46PM (#11150932) Homepage
    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).

  • by Tim Macinta (1052) * <> on Tuesday December 21, 2004 @02:48PM (#11150954) Homepage
    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.

  • Making the sqitch (Score:3, Informative)

    by haplo21112 (184264) <haplo AT epithna DOT com> on Tuesday December 21, 2004 @02:48PM (#11150966) Homepage
    I amde the switch over to Apache 2.0 and PHP 5 about 3 weeks ago at this point and have found it to be rock solid so far. My impression was that the PHP guys are recommending PHP4 for Apache 1.3.x and PHP5 for Apache 2.0.x. So in translation what they are not recommending is PHP4 on Apache 2.0.x. Perhaps I have gotten the wrong impression but that's what I got...
  • by markv242 (622209) on Tuesday December 21, 2004 @02:50PM (#11150982)
    FYI, PHP compiled in CGI-mode completely eliminates the threading issues that PHP has with Apache 2, and allows you to continue to use Apache in worker mpm mode (which is, by far, the most efficient -- think orders of magnitude better performance on the same hardware).

    The CGI may be a little slow to start up a PHP interpreter, etc etc, but it is rock solid. That said, using a real multithreaded application server (like, oh, any of your Java app servers) with Apache 2.0 is the best solution.

  • by Anonymous Coward on Tuesday December 21, 2004 @02:51PM (#11151008)
    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'.

  • by Anonymous Coward on Tuesday December 21, 2004 @02:55PM (#11151058)
    The memory pools in Apache 2.x (apr_pool_t) are quite inefficient []. They have per-thread pools of memory that are only released when a thread finishes processing an HTTP connection. Apache 2.x uses more memory than Apache 1.3.x as result. I see no reason to switch from the very efficient Apache 1.3.x line.
  • by rbowen (112459) on Tuesday December 21, 2004 @02:56PM (#11151064) Homepage
    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.
  • How many hits? (Score:5, Informative)

    by dsb3 (129585) on Tuesday December 21, 2004 @02:58PM (#11151103) Homepage Journal
    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.
  • by Bruce Perens (3872) <> on Tuesday December 21, 2004 @03:02PM (#11151157) Homepage Journal
    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.


  • by rbowen (112459) on Tuesday December 21, 2004 @03:06PM (#11151207) Homepage
    Allow me to clarify something if I may. I'm not suggesting that everyone needs to migrate to Apache 2.0 today. I'm suggesting that PHP not strenuously discourage people from doing so. Those are two rather different things.

    I hardly think that my posting (which, of course, nobody can read now because my server in my bedroom is melting. *sigh*) qualifies as unimitigated flames.

    And I *certainly* don't presume to speak for the whole Apache community. It was just some (I thought0 harmless observations.
  • by pthisis (27352) on Tuesday December 21, 2004 @03:07PM (#11151218) Homepage Journal
    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).
  • by Bruce Perens (3872) <> on Tuesday December 21, 2004 @03:10PM (#11151255) Homepage Journal
    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.


  • Re:Nobody told me! (Score:3, Informative)

    by Anonymous Coward on Tuesday December 21, 2004 @03:12PM (#11151282)
    PHP depends on a large number of external libraries that may or may not be thread-safe, and in many cases they are claimed to be thread-safe but aren't. Throw in the fact that some of these libraries are system libraries and the problems may not be reproducible on other systems, and you realise that making "PHP" thread-safe (in reality, making all the libraries it depends upon thread-safe), or even just tracking down where the problem lies, is a massive problem. The PHP devs have essentially said "not our problem, and we can't fix it".

    None of this, of course, is a reason to avoid Apache 2. Apache 2 can run in prefork mode, just the same as Apache 1. That's why the PHP documentation telling everyone to avoid Apache 2 is FUD.

    Unfortunately, the threaded models Apache 2 could otherwise use are one of the major attractions of upgrading. In particular, running different websites under different uids is only possible with the threaded MPMs, which is a *huge* deal for hosting providers, PHP's main installed base. Well, it's possible by running multiple copies of Apache and a proxy on port 80, but nobody wants to do that.
  • by Bruce Perens (3872) <> on Tuesday December 21, 2004 @03:15PM (#11151337) Homepage Journal
    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.


  • Re:Frontpage (Score:3, Informative)

    by Jokkey (555838) on Tuesday December 21, 2004 @03:20PM (#11151413)

    In my experience, FrontPage actually works quite a bit better with Apache 2.0. FrontPage for Apache 1.x requires patching your Apache or downloading pre-patched binaries from or Microsoft. FrontPage for Apache 2 can load cleanly as a module, no server modifications needed.

    If you want the offical notice of Apache 2 support, see here [].

  • by ivan37 (149147) on Tuesday December 21, 2004 @03:23PM (#11151467)
    lighttpd [] is a pretty good up-and-coming alternative I've been testing lately. It's faster than apache for both static and dynamic (php, python, ruby) content.
  • by Bruce Perens (3872) <> on Tuesday December 21, 2004 @03:27PM (#11151527) Homepage Journal
    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.


  • by DarkBlack (5773) <.darkblack. .at.> on Tuesday December 21, 2004 @03:54PM (#11151919) Homepage
    You can run both Subversion and PHP 4 concurrently in Apache 2.0. We've been doing it sucessfully for several months now with no problems in prefork mode. No need for two versions of Apache when one will do.

  • by Matt Perry (793115) <perry,matt54&yahoo,com> on Tuesday December 21, 2004 @03:56PM (#11151953)
    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.
  • by sean_gabriel (516287) on Tuesday December 21, 2004 @04:07PM (#11152125) Homepage
    Well perchild was supposed to provide this functionality, but it's unmaintained and nonfunctional from what I understand. Even if it does work it has security problems. On top of that it's a threaded MPM, so it carries the same thread-safety issues that worker does for PHP.

    There are some of us who are attempting to provide a working alternative. The MetuxMPM project can be considered a working implimentation of perchild, although still in development. It still uses the threaded model but doesn't suffer the same security issue.

    I required a non-threaded solution, so I started my own MPM project, using prefork as a base but copying in a lot of code from metuxmpm. I call it "peruser". Right now it's a lot more clunky than metuxmpm. I'm also not a professional C or apache programmer, so if anyone out there wants to help I'd really appreciate it.

    Neither of these projects is really well-suited for a small number of websites that do a lot of traffic. They're more aimed at shared hosting providers who want to provide better security than php's safe_mode.

    Here's the links:
    MetuxMPM []
    Peruser (nonthreaded version of metuxmpm) []
  • by Anonymous Coward on Tuesday December 21, 2004 @04:27PM (#11152409)
    As much as I respect you after meeting you at the NC Biotech center in May of 97(?), I think you need to think that through completely. I've tried this with a site so I could use an old version of pdflib. Performance was a major problem. If you have only a single Apache thread that can access an often used library function at a time, you have a bottleneck. With multiprocess servers, that isn't a problem. The original UNIX process model works well and is simply safer.
  • by Ath (643782) on Tuesday December 21, 2004 @04:41PM (#11152619)
    No, the PHP folks specifically tell you not to run PHP with Apache 2.0. It is in their FAQ on their website.
  • by killjoe (766577) on Tuesday December 21, 2004 @05:00PM (#11152956)
    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.
  • by pthisis (27352) on Tuesday December 21, 2004 @05:03PM (#11152989) Homepage Journal
    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.
  • Rewriting libraries (Score:3, Informative)

    by Bruce Perens (3872) <> on Tuesday December 21, 2004 @05:11PM (#11153102) Homepage Journal
    What we are asking for in these rewrites is for what are presently global variables to be made part of a structure that is allocated per-thread by a library call and then passed to all calls to that library as an argument. You don't have to use any magic POSIX thread-local memory stuff to do this, and it's portable. No software logic need change. If this point is made effectively to the maintainers of these libraries, they'd do it.
    If the thread gets destroyed or exploited outside of PHP in one of these other libs, HOW is that PHP's fault?
    Some programs do unwind context on catching a signal. Especially those that provide an exception mechanism.

    It still seems to me to be an architecture issue.


  • er, no... (Score:4, Informative)

    by MenTaLguY (5483) on Tuesday December 21, 2004 @05:20PM (#11153209) Homepage

    Kill-9ing does not always clean memory, open files, sockets, etc.

    Yes it does. The only exceptions are SYSV IPC objects which don't get automatically reaped, and temporarily created filesystem objects that still have links.

    Assuming your kernel isn't buggy, anyway.

  • this is untrue. (Score:5, Informative)

    by vena (318873) on Tuesday December 21, 2004 @05:40PM (#11153438)
    from the docs: []

    Do not use Apache 2.0.x and PHP in a production environment neither on Unix nor on Windows.
  • by Foolhardy (664051) <csmith32@gmail.MONETcom minus painter> on Tuesday December 21, 2004 @11:48PM (#11155989)
    True, NT does favor threads vs processes as they are much lighter, but even more than that, NT favors a very small amount of threads running as asynchronous workers. NT inherited the heavily asynch IO model from VMS.

    On NT, instead of creating 64* threads [] (or whatever the maximum number of concurrent clients will be, possibly hundreds) where one thread waits on each connected client, it would be better to create about 1 thread per CPU and have them take work items off of a completion port []. Instead of blocking on IO, always do it asynchronously and have the result posted as another work item.
    Both files and sockets can be connected to completion ports. Always have a pending read on open sockets so when a packet is recieved, the OS posts a work item.
    Client wants dynamic content but you have to read something first? Start the read now and immediately go back to waiting for another work item in case you could be doing something else in the meantime. When it completes, the OS will post it and you can finish the operation: do the necessary processing, start an asynch write of the result to the socket and go back to waiting for more work.
    Client wants a static file? Start the transfer with TransmitFile [] (it's like UNIX sendfile) and immediately wait for another work item.
    The only thing you should be blocking on are locks to synchronize multiple threads. Never IO.

    On a single processor machine, you might as well only have one worker thread since it should never be blocked except for lack of work: this means that nothing has to be threadsafe. The buggy PHP extensions could live in a happy single-threaded world without sacrificing any performance. Hopefully you can upgrade to better software if your server has multiple CPUs to take advantage of, or use one process per CPU.

    * Apache has to have 200 threads if I ever expected that many clients to connect at one time, just in case? Can't they at least be started dynamically? No wonder it doesn't perform well on Windows. I just hope they aren't used round-robin.
  • by bedessen (411686) on Friday December 24, 2004 @05:15AM (#11175503) Journal
    If you know anything about webhosting you know that cPanel/WHM (and competitors, e.g. DirectAdmin, Fantastico, etc) still support the stodgy old Apache 1.3/mod_php model. The vast majority of sites out there run on cPanel or some other type of shared/reseller type of control panel/managed hosting software. Until this changes, don't expect Apache 2.0 to make any inroads.

    That said, everyone should hope 1.x to die ASAP. Basically the Apache developers have to do double duty maintaining two completely seperate branches. If everyone could let 1.3 die then there would be a LOT more manpower available to concentrate on 2.0. For many many years they have said that no new features are going into 1.3 -- everything is happening on 2.x. Yet they still have to maintain security fixes and chase down bugs on the 1.3 branch which is very creaky. There is a reason, after all, that they decided to rewrite everything for 2.x.

Optimization hinders evolution.