Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×

Benchmarking 3 PHP Accelerators 81

Posted by timothy from the ack-phpttht dept.
jfbus writes "PHP, like all scripting languages, suffers from having to parse all script files each time a page is displayed. Accelerators (opcode caches) are necessary to speed PHP enough for large websites. Here is a benchmark of the major PHP accelerators (Zend platform, apc and eAccelerator)."
This discussion has been archived. No new comments can be posted.

Benchmarking 3 PHP Accelerators More

Benchmarking 3 PHP Accelerators

Comments Filter:
  • but how does this work? If one makes something like this:
    if($var) {
    function Example() { echo "Hi!\n"; }
    } else {
    function Example() { echo "Bye!\n"; }
    }
    How does a function defined inside a condition get changed into opcode? Does it place a copy of both functions everywhere where Example() is called?
    • In such a case you would compile each version of the function and implement the condition by an opcode that put a reference to the correct version into a pointer. Then every call to the function use the reference contained in the pointer. In a word, you use indirect function calls.
    • Not just functions - conditional includes. In most cases, the accelerator deals with them poorly.

      When someone says they have a "can not redeclare class X" error, it's probably because of a caching program being added. It's kept a copy of the compiled script... but keeps hitting those pesky "include()" calls, and reloads what it previously included in the compiled version, or it fails to include the correct file, because it already finished reading its includes.

      With some applications, though, the time to c

      • In some applications that may be true, but overall accelerators do make a huge difference. I'm seeing over 2-3 times faster page generation times for most standard web applications (forums, CMS) using Turck mmcache (forced into memory only). No side effects that I've ever noticed after a couple years of running it. Taking advantage of MySQL's (4.1+) query cache also helps quite a bit.

        It's a substantial difference, with heavy php+database pages like forum indexes generating in 0.3 to 0.5 seconds vs. 2 - 3
  • from TFA: "Zend Platform has roughly the same performance as eAccelerator and apc (you'll have to believe me, I don't have any numbers to give you), but is the only one to have an official support (provided you pay for it...). Unless you need a real support, unless you need the specific features of Zend Plaform or you really want to pay for the software (one never knows...), you probably do not need Zend Platform. I don't like Zend setup process : it does change a lot of things within php.ini, does many
    • What, you want numbers and objective reasoning to back up conclusions comparing three software platforms in an empirical manner? You kids and your obsession with not believing truths that aren't supported by facts.
    • yeah, I thought the same thing - TFA goes something like "I am going to compare and benchmark 3 things for you, except that I am not really going to compare one of them, but while we are on the subject, the one I can't compare for you sucks anyway". The conclusion is just as good: "You can either choose one, or the other. You should choose the one I did, because it r0x0rz and is only better at one thing, but you may want the other one, because my test show it is performs better. Also, theone like has no fut
    • Yes, it looks very much like the kid couldn't afford Zend Platform so just bashes it then disregards it.

      Of course if your PHP site is seeing the sort of traffic levels that require an optimzer it's very likely you will in fact want the support that comes with Zend Platform - not to mention the integration and debugging features with Zend Studio. (I have no relationship with Zend other than being a happy customer).

      • Of course if your PHP site is seeing the sort of traffic levels that require an optimzer

        You see, you want an optimizer for quite another reason then the amount of traffic you get.

        Simply put, it makes running the website less resource intensive, which means that you can host it at a lower cost. You can afford a lot more complexity with the same amount of resources, so you can offer more/better functionality, your web hosting will interfer less with other services on the same physical machine etc etc. Assumin
  • Is it just me or do they only benchmark eAccelerator vs apc (vs bare php), only mentioning Zend here and there? Not as useful as it might be..

  • Like all scripting languages? (Score:4, Informative)

    by Bogtha ( 906264 ) on Wednesday May 31, 2006 @02:39PM (#15438270)

    PHP, like all scripting languages, suffers from having to parse all script files each time a page is displayed.

    This isn't something common to all scripting languages. For example, when Python scripts are executed, they are compiled to byte-code, and the result is saved for faster execution next time. Of course, in typical web hosting situations, the web server doesn't have permission to write to the filesystem, but you can quickly and easily compile the bytecode yourself [incutio.com]. ASP.NET also compiles once only.

    In fact, I believe it's an oddity of PHP that it needs add-ons in order to do this, and I think the next version of PHP will have fixed this. I don't know where they got the idea that all scripting languages must always parse the script on every invocation.

    • when developing code, having saved precompiled scripts automatically done is the most annoying thing in the world....

      • Only if your setup isn't smart enough to notice when the source has changed and there's no way of disabling the caching. It's an old problem sure, but one with plenty of solutions.

        • Dude, mod_python sucks in precisely that aspect. Have you ever used it at all? You can't reload code without restarting Apache or using PITA code such as Vampire. PHP kicks python's ass in this respect.

          • Dude, mod_python sucks in precisely that aspect. Have you ever used it at all?

            Yes, I use mod_python a fair bit. The reloading rules can be confusing if you aren't used to them, but once you understand them, it's easy to set up a sane development environment.

            The trouble with the way PHP does things is that even when you cache opcodes, you are still executing everything for every request. Since the Python interpreter is persistent across multiple requests, the expensive operations only need to be e

            • Would you mind enlightening me on this aspect? I have never suceeded in getting sane behaviour out of apache/mod_python when developing other than having a bash script looping over "true" that restarts apache and waits for a keypress to do it again. And I do this quite a while.
      • Only if the implementation of the language is idiotic enough not to be able to notice that the source has changed and should be recompiled to bytecode. While I agree this would probably be an issue with PHP, it's not in most other interpreted languages.
      • Does any language do that?

        Python's loading algorithm goes something like this:

        1. A module tries to import another module named "foo".
        2. Find "foo.py" in the search path.
        3. Does "foo.pyc" ("c" for "compiled") exist in the same directory? If so, is it newer than foo.py? If both are true, then load it.
        4. Otherwise, compile "foo.py" and attempt to write the compiled bytecode to "foo.pyc".

        Never in my time developing Python have I once encountered a problem with stale compiled objects. If your language

    • Yes, and things like mod_perl just keep the Perl interpreter in memory, and load modules only once. I think all traditional "scripting" languages use something like that now, CGI is rather 1996...

    • In fact, I believe it's an oddity of PHP that it needs add-ons in order to do this, and I think the next version of PHP will have fixed this.

      That's one of Zend's main revenue sources. They developed PHP, they developed the accelerator. But they sell the accelerator and offer PHP free with sources as a lure.

      What I'm saying is, no, it won't be fixed in the next version of PHP.

      • Rasmus Lerdorf has posted a PHP 6.0 wishlist [php.net] that includes an opcode cache. Rasmus is the founder of the PHP project.

        Zend might sell an accelerator, but that doesn't mean they can simply forbid the founder of PHP from adding the feature to his own project. At this point, I think the question is which opcode cache gets added to PHP, not whether it will happen.

        • I believe it's more than a wish. In fact I read previously that they had selected the APC opcode cache for integration with PHP, the main reason being that it had a compatible license with PHP whereas other opcode caches did not.
    • I don't know where they got the idea that all scripting languages must always parse the script on every invocation.

      Some people have used that as part of the definition of "scripting language". Pre-dot-Net ASP* also worked that way, although I got out of that a long time before .Net and for all I know Microsoft shipped an accelerator at some point before .Net.

      There was a time when this idea had at least some value. However, it's been a while now since I've heard a useful definition of "scripting language" be
      • AFAIK Microsoft never provided an ASP accelerator - at least, I've never heard of one :P If I do a websearch I can't find anything either - all the accelerator products are for .net, making me wonder what microsoft's internal acceleration features are good for.

      • However, it's been a while now since I've heard a useful definition of "scripting language" beyond "what people have traditionally called scripting languages"

        I think the definition that most closely mirrors what people consider to be scripting languages these days is that it's a scripting language if the compilation step is automatic, optional or non-existent.

      • (*: Which seems to be what PHP copied itself from, which actually explains a lot about PHP.)

        PHP was *not* copied from ASP. PHP was originally started in (late?) '94, and was growing in popularity by 1996, when MS introduced their HTC stuff. IIRC "ASP" wasn't in real use until some time in 1997, by which time PHP was widely used.

        http://en.wikipedia.org/wiki/Active_Server_Pages [wikipedia.org] says ASP 1.0 was out in Dec 1996. IIRC Rasmus has mentioned that some Microsoft engineers were on an early PHP dev mailing list so
    • This isn't something common to all scripting languages. For example, when Python scripts are executed, they are compiled to byte-code, and the result is saved for faster execution next time.

      It's not a True Scripting Language if there's a just-in-time compiler involved, now is it?

      • It's not a True Scripting Language if there's a just-in-time compiler involved, now is it?

        Python doesn't come with a JIT compiler. The .pyc files it saves out are byte code, not machine instructions.

        As an aside: the .pyc files simply keep Python from having to re-compile from source to byte code every time the module is loaded. It doesn't provide any performance advantage past that initial module import stage.

        That said, Pyco [sourceforge.net] can generate x86 instructions from Python code in a manner very much like a JIT

      • Why wouldn't it be? JIT compilation is merely a rather advanced kind of interpreter. AFAIK Python already has one [sourceforge.net] (even though dev on it has more or less stopped) and PyPy [codespeak.net] will supposedly include one out of the box, and I think Matz would like Ruby2 to have a JIT compiler.

    • I don't know where they got the idea that all scripting languages must always parse the script on every invocation.

      From wikipedia [wikipedia.org]: Those languages which are suited to scripting are typically called scripting languages. Many languages for this purpose have common properties: they favor rapid development over efficiency of execution; they are often implemented with interpreters rather than compilers; and they are strong at communication with program components written in other languages.

      * lon3st4r *

  • Turck MMCache (Score:3, Informative)

    by slashflood ( 697891 ) <flow.howflow@com> on Wednesday May 31, 2006 @02:40PM (#15438282) Homepage Journal
    What about Turck MMCache [sourceforge.net]?

    • Re:Turck MMCache (Score:4, Informative)

      by hhnerkopfabbeisser ( 645832 ) on Wednesday May 31, 2006 @02:47PM (#15438340)
      The project died when the developer was hired by Zend. Last Version released in late 2003.

      Reincarnated here: http://eaccelerator.net/ [eaccelerator.net]
    • turck is a dead project. It was forked to become... eAccelerator. It is mentioned in the article.
    • What about Turck MMCache?

      Ah, I see:

      eAccelerator [sourceforge.net] was born in December 2004 as a fork of the Turck MMCache project. Turck MMCache was created by Dmitry Stogov and much of the eAccelerator code is still based on his work.

      But it would've been nice to see a comparision between MMCache and eAccelerator as well.

      • “But it would've been nice to see a comparision between MMCache and eAccelerator as well.”

        I'd have to agree with you on this one – I've never used eAccelerator, and in fact I've never even heard of it up until just now, but I happen to like MMcache a great deal. I know that Wikipedia uses MMcache [wikimedia.org], and I've been using it extensively on my own server [dyndns.org] as well, because it's a slow server and literally everything on there is generated by some PHP script or other...

        • I'm glad this came up because I was wondering why there haven't been any new versions of mmcache.

          I still use it because it's rock solid reliable and the performance is still fantastic. I'm now tempted to try out eAccelerator, but my gut tells me that any performance improvements would be fairly small. Anyhow, I'm adding it to the bottom of my "stuff to try" list.
          • I'm now tempted to try out eAccelerator, but my gut tells me that any performance improvements would be fairly small.

            They are. The big advantage of eAccelerator over Turck is its PHP5 support, rather than performance enhancements.

  • Parsing? (Score:1, Flamebait)

    by imroy ( 755 )

    PHP, like all scripting languages, suffers from having to parse all script files each time a page is displayed.

    Speak for yourself, PHP weenie. My Perl code is parsed and "compiled" only when I restart the FastCGI handler(s) for my Catalyst [catalystframework.org] web app(s). My templates [tt2.org] are (I'm sure) parsed on each invocation though. The situation is probably similar for other real scripting languages e.g Python and Ruby.

    • My templates are (I'm sure) parsed on each invocation though.

      I'd be surprised. I know Apache::ASP compiles each web page ("template") down to a Perl subroutine once per execution (unless you change it); I'd bet the TT works the same way. The speed gains are too large to ignore, especially in a web environment, and Perl makes it too easy.

    • My templates are (I'm sure) parsed on each invocation though.

      Apache::Template with mod_perl will allow you to have Template-Toolkit preloaded.

  • I would very much like to see a comparison of the three against established performers in different languages. For example: mod_perl.
  • But, it doesn't work with 5.1. And, 5.1's performance is pretty close to that of PHP 5 with eAccelerator(not php4 w/), and close to PHP 5 with. I can't wait for eAccelerator to come out for php5.1, but until then, APC compiles cleanly and works well. With a kickass control panel.

    Zend's tragedy core dumps apache every 20 minutes.
  • The most heavily used PHP/apache/mysql-type server on my network (probably never used by more than tweny hosts at a go) never seems to have any speed issues.

    It's a modest machine. Dual 600mhz p3, 256mb of ram. How bad/good/busy do things have to get before a php accelerator becomes necessary?
    • There are a lot of factors here so trying to give you some kind of numbers would be rediculous without knowing your setup. But the simple answer is: If your CPUs get pegged at 100% all the time and all of that CPU is being used up by apache processes running php scripts then it's a good sign that it's time to install an opcode cache. Depending on what your doing they can make a HUGE difference.
  • The guys over at lighttpd.net have released a new opcode cache for php - still in beta (i think), but some might find it useful: http://trac.lighttpd.net/xcache/ [lighttpd.net]
    XCache is a fast, stable php opcode cacher that has been tested and now running on production server under high load. It support and is tested on all lastest php cvs branches, such as PHP_4_3 PHP_4_4 PHP_5_0 PHP_5_1 PHP_5_2 HEAD(6.x)

Slashdot Top Deals

"The only way for a reporter to look at a politician is down." -- H.L. Mencken

Close