Slashdot Mirror

← Back to Stories (view on slashdot.org)

Benchmarking 3 PHP Accelerators

Posted by ryuzaki0 on 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)."

81 comments

  1. Forgive me for my stupidity, by remembertomorrow · · Score: 1
    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?
    --
    Registered Linux user #421033
    1. Re:Forgive me for my stupidity, by tonigonenstein · · Score: 2, Informative

      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.

      --
      The sooner you fall behind, the more time you have to catch up.
    2. Re:Forgive me for my stupidity, by WoodstockJeff · · Score: 1
      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 compile the PHP is only a fraction of the time to run the program. What's the use of cutting a tenth of a second off the load time, when you're dealing with queries that take 5 to 10 seconds to run? Or if you've got a host that runs PHP as a CGI program?

    3. Re:Forgive me for my stupidity, by Doug+Neal · · Score: 1

      Excuse the pedantry, but that's five words!

    4. Re:Forgive me for my stupidity, by slackmaster2000 · · Score: 1

      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 seconds under moderate load. The PHP cache accounts for a majority of the difference. Start piling on users and it becomes quite critical to server load and overall user experience.

    5. Re:Forgive me for my stupidity, by Oopsz · · Score: 1

      You know the turck codebase has been forked and supplanted by eaccelerator, right? There's no reason to use turck-mmcache anymore, especially since it hasn't been worked on since late 2003. EA is turck's logical successor.

    6. Re:Forgive me for my stupidity, by slackmaster2000 · · Score: 1

      I use it because I've been using it for years without a hitch. I'm still running PHP 4. No need to fix what isn't broken.

      Assuming the development on eAccelerator is on the right track, I'm sure I will be using it at some point down the road.

  2. not really scientific by Keyframe2 · · Score: 1

    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 hidden things. " and so on...

    1. Re:not really scientific by richdun · · Score: 1

      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.

    2. Re:not really scientific by passthecrackpipe · · Score: 1

      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 future." good effort....

      --
      People who think they know everything are a great annoyance to those of us who do.
    3. Re:not really scientific by Albanach · · Score: 1
      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).

    4. Re:not really scientific by SillyNickName4me · · Score: 1

      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. Assuming that amount of traffic is what generates the desire for an optimizer is not wrong or such, but it is by far not the only, and in many cases not the most compelling reason.

      I have made a lot of use of eAccelerator (and before that turk-mmc) to get a somewhat more complicated site to run on a small server. This is hobby and if I couldn't run it like that, I wouldn't run it, instead of spend money on either a bigger machine or a commercial optimizer.

      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).

      If you are running some commercial service with PHP, you most likely want that, yes.

  3. Three? by kailoran · · Score: 1

    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..

  4. Like all scripting languages? by Bogtha · · Score: 3, Informative

    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. 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.

    --
    Bogtha Bogtha Bogtha
    1. Re:Like all scripting languages? by Anonymous+Crowhead · · Score: -1, Flamebait

      Well if you are using PHP, you are already riding the short bus - if you know what I mean. And I think you do...

    2. Re:Like all scripting languages? by Anonymous Coward · · Score: 0

      Agreed, if you are using mod_perl for instance, your scripts are compiled and cached (in RAM). And many folks use fastcgi with Ruby, which basically compiles your code once. Lisp folks keep a running Lisp image going (and can log into it and change the running code without restarting, oooh, gotta love lisp).

      PHP really is the odd one out here. Just to get it to "adequate" requires commercial products.

      Of course, part of the problem is the utter brain-dead "design" of PHP. With all that global stuff, it's hard to reliably keep code around in RAM. And based on my own experience trying to write a long-running maintance daemon in PHP, the damn thing leaks RAM like you wouldn't believe. I haven't looked at the source code but I bet it's pretty scary.

      So, folks who use PHP would be best served moving to pretty much anything else. Having a cleaner language design and a community that isn't 95% newbies doesn't hurt either.

    3. Re:Like all scripting languages? by pxuongl · · Score: 1

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

    4. Re:Like all scripting languages? by Bogtha · · Score: 1

      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.

      --
      Bogtha Bogtha Bogtha
    5. Re:Like all scripting languages? by Scarblac · · Score: 1

      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...

      --
      I believe posters are recognized by their sig. So I made one.
    6. Re:Like all scripting languages? by suv4x4 · · Score: 2, Interesting

      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.

    7. Re:Like all scripting languages? by Anonymous Coward · · Score: 0

      ASP .NET is *compiled* to MSIL which itself is then compiled into native code upon first invocation, and again any time the files involved change. Python is compiled into bytecode and that bytecode is interpreted each execution. It's an advantage Microsoft has by sheer virtue of not having to be cross-platform. PHP is worse than either as it stands, since as a scripting language, it is inherently interpreted. If it were not interpreted, it'd not be a scripting language.

      Regards,
      -Steve Gray
      -Cobalt Software

    8. Re:Like all scripting languages? by Bogtha · · Score: 2, Insightful

      Rasmus Lerdorf has posted a PHP 6.0 wishlist 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.

      --
      Bogtha Bogtha Bogtha
    9. Re:Like all scripting languages? by masklinn · · Score: 1

      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.

      --
      "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
    10. Re:Like all scripting languages? by Just+Some+Guy · · Score: 2, Informative
      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 of choice doesn't have this same functionality or its equivalent, then the problem is with the language and not the concept.

      --
      Dewey, what part of this looks like authorities should be involved?
    11. Re:Like all scripting languages? by Anonymous Coward · · Score: 0

      Are you trying to make somebody look stupid by signing their name at the bottom of that steaming pile of shit? On the off-chance that you are actually that clueless (and your misplaced admiration for Microsoft would leave no doubt), I suggest you go and read this.

    12. Re:Like all scripting languages? by Jerf · · Score: 1

      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" beyond "what people have traditionally called scripting languages"; about the only criterion left is "statically typed" vs. "dynamically typed", and it's much more descriptive to actually use those terms instead of "scripting language" in that case.

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

    13. Re:Like all scripting languages? by drinkypoo · · Score: 1

      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.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    14. Re:Like all scripting languages? by poot_rootbeer · · Score: 1

      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?

    15. Re:Like all scripting languages? by Bogtha · · Score: 1

      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.

      --
      Bogtha Bogtha Bogtha
    16. Re:Like all scripting languages? by gomoX · · Score: 1

      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.

      --
      My english is sow-sow. Sowhat?
    17. Re:Like all scripting languages? by Bogtha · · Score: 1

      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 executed once every time an httpd process starts up, giving you loads more options when it comes to performance. Yes, that flexibility comes at a cost of complexity, but PHP's approach of simply making it impossible so people don't get confused is hardly optimal.

      --
      Bogtha Bogtha Bogtha
    18. Re:Like all scripting languages? by mcasaday · · Score: 1

      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 can generate x86 instructions from Python code in a manner very much like a JIT compiler
    19. Re:Like all scripting languages? by masklinn · · Score: 1

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

      --
      "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
    20. Re:Like all scripting languages? by Ambush+Commander · · Score: 1

      "And based on my own experience trying to write a long-running maintance daemon in PHP"

      Maybe that's because PHP isn't supposed to be used for writing daemons. ;-)

    21. Re:Like all scripting languages? by sr180 · · Score: 1

      Microsoft Foxpro does this with its 'programs', which are scripts that are compiled into form. However, unlike Python, Foxpro quite often manages to get itself with out of date compilations.

      --
      In Soviet Russia the insensitive clod is YOU!
    22. Re:Like all scripting languages? by gomoX · · Score: 1

      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.

      --
      My english is sow-sow. Sowhat?
    23. Re:Like all scripting languages? by Anonymous Coward · · Score: 0

      Perl does it with the B::Bytecode compiler backend module.

    24. Re:Like all scripting languages? by lon3st4r · · Score: 1
      I don't know where they got the idea that all scripting languages must always parse the script on every invocation.

      From wikipedia: 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 *

    25. Re:Like all scripting languages? by TLLOTS · · Score: 1

      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.

  5. Turck MMCache by slashflood · · Score: 2, Informative

    What about Turck MMCache?

    1. Re:Turck MMCache by hhnerkopfabbeisser · · Score: 3, Informative

      The project died when the developer was hired by Zend. Last Version released in late 2003.

      Reincarnated here: http://eaccelerator.net/

    2. Re:Turck MMCache by gbjbaanb · · Score: 1

      turck is a dead project. It was forked to become... eAccelerator. It is mentioned in the article.

    3. Re:Turck MMCache by slashflood · · Score: 1

      What about Turck MMCache?

      Ah, I see:

      eAccelerator 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.

    4. Re:Turck MMCache by martinultima · · Score: 1
      “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, and I've been using it extensively on my own server as well, because it's a slow server and literally everything on there is generated by some PHP script or other...
      --
      Creative misinterpretation is your friend.
    5. Re:Turck MMCache by slackmaster2000 · · Score: 1

      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.

    6. Re:Turck MMCache by matlhDam · · Score: 1
      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.
  6. PHP sucks by Anonymous Coward · · Score: -1, Flamebait
    For those of you hunting to an even uglier alternative to Perl, you'll find a friend in PHP. From the awkward string manipulation routines (who the fuck would want to use C-like functions to manipulate strings in a scripting lanugage?) to the horrendously crappy object oriented programming model, PHP has everything that nobody wants or needs in a language. Hell, you can even embed Perl in HTML pages these days in the same manner.

    So, to recap, folks, PHP is...

    • Prone to security holes and misc. bugs
    • An awful pain to program
    • Slow as a dog, even in it's intended "niche" use as a web scripting language. Anyone intending to do something serious with a website would use Servlets or at least mod_perl.
  7. Parsing? by imroy · · Score: 0, Flamebait
    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 web app(s). My templates are (I'm sure) parsed on each invocation though. The situation is probably similar for other real scripting languages e.g Python and Ruby.

    1. Re:Parsing? by Jerf · · Score: 1

      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.

    2. Re:Parsing? by onlyjoking · · Score: 1

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

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

  8. MOD PARENT UP, MOD STORY/PHP/PHP FANBOYS DOWN by SirJaxalot · · Score: -1

    MOD THIS POST UP.

    --


    Geminatron
  9. Comparison against other languages by digerata · · Score: 1

    I would very much like to see a comparison of the three against established performers in different languages. For example: mod_perl.

    --

    1;
  10. "Accelerating" PHP is a waste of time by Anonymous Coward · · Score: -1, Troll
    PHP is crap. It's essentially just like ASP, except unlike ASP you're:

    • locked into a language worse than VBScript,
    • locked into an extension model worse than ActiveX,
    • have a database interface a billion times worse than ADO (for example, the standard PHP MySQL interface has no paramatarized queries!!! Who's the supergenius who thought that up?), and
    • lack almost all the functions, procedures, methods, or objects that would make web programming useful.


    For a few glaring examples where PHP doesn't give you even the most basic requirements for first-generation web language, there's no equivilant to ASP's Response.Redirect(). There's no equivilant to ASP's Server.MapPath(). The handling of forms with multiple fields of the same name (like checkboxes) is so hideously broken I don't know if I should laugh or cry.

    I want to avoid saying that most PHP sites are amazingly insecure. Certainly, this must be a function of the pathetic losers who use PHP, instead of some function of the language. But after spending even a week on BugTraq, one begins to wonder exactly what most PHP developers are smoking when they write sites.

    In short, I think PHP sucks. It's little suprise to me that the editors on this site find it so endearing.
    1. Re:"Accelerating" PHP is a waste of time by masklinn · · Score: 1, Redundant

      I want to avoid saying that most PHP sites are amazingly insecure. Certainly, this must be a function of the pathetic losers who use PHP, instead of some function of the language.

      The language helps though, the easiest example one can give is the dozen of different functions just to escape DB query parameters (there are at least 3 for mysql alone -- addslashes, mysql_escape_string and mysql_real_escape_string, only the latter being safe), or the wonderful built-in magic quotes that basically addslashes() everything and require you to stripslash every single parameter when they're activated (cause addslashes doesn't provide safe-to-inject values and fucks them up so you can't just *_escape_string them), or the wonderful Register Globals that was finally turned off by default (not even removed) in PHP 4.2.0.

      --
      "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
    2. Re:"Accelerating" PHP is a waste of time by fractalus · · Score: 2, Insightful
      PHP may indeed be crap, but not for the reasons you specify.

      • Whether you prefer Perl-like syntax (that PHP uses) or VBScript syntax is largely a matter of preference. I've personally found that VBScript is more of a pain in the ass than PHP.
      • You can have ADO if you want it, or you can use PDO which does support parameterized queries. Or you can use mysqli instead of mysql.
      • I honestly found VBScript lacking more basic convenience functions than PHP ever did.


      The extension model may be a matter of taste. I'll give you the benefit of the doubt. PHP's handling of multiple form fields with the same name does suck, but at least it isn't too hard to work-around (just re-parse the posted data the way it should have been done).

      PHP security doesn't suck any worse than ASP or Perl or ColdFusion or anything else, once you disable things like magic_quotes and register_globals (which is recommended practice). However, there's a lot of crappy PHP code floating around, and if you're new to web programming, you don't know enough to tell the good code from the bad. Nor do you really grok the notion that your code can be hammered on by every malcontent on the planet. Those problems are also not unique to PHP. But since PHP is so widely available, lots of amateurs write code with it.
      --
      People are never as simple as their stereotypes. This applies equally to Christians, Muslims, and Emacs-lovers.
    3. Re:"Accelerating" PHP is a waste of time by mogrify · · Score: 2, Informative

      /* libAnonCoward.php */

      function Redirect($location) {
        header("Location: $location");
        die;
      }

      function MapPath($file) {
        return realpath($file);
      }

      --
      perl -e 'foreach(values %SIG){$_="IGNORE";}while(){}'
    4. Re:"Accelerating" PHP is a waste of time by masklinn · · Score: 1

      Whether you prefer Perl-like syntax (that PHP uses) or VBScript syntax is largely a matter of preference. I've personally found that VBScript is more of a pain in the ass than PHP.

      Wrong, PHP doesn't use Perl-like syntax, it uses what it things of as Perl-ish "$" prefixes, the point that these wonderful PHP devs missed is that prefixes actually have a meaning in Perl, in PHP they don't (yes I do know that they're data access shit(1), and I do also know that this is retarded). PHP also removed much of the cryptic-but-useful Perl syntax. PHP definitely does not have a Perl-like syntax unless by perl-like you mean "not like perl's syntax at all".

      You can have ADO if you want it, or you can use PDO which does support parameterized queries. Or you can use mysqli instead of mysql.

      Remind me when PDO and mysqli finally made their way into the language? PHP5.1 and PHP 5? Are we supposed to be impressed? ADO was born in 1996 for god's sake, that's 4 years before the Zend devs managed to release PHP4 and and programmers had to wait 4 more years to finally get a non-braindead DB interface?

      And we're only talking about ADO here, Perl's DBI was specified in 1994, Python's DBAPI was first released in 1996 and it's evolution (DBAPI 2.0) was born in 1999...

      PHP security doesn't suck any worse than ASP or Perl or ColdFusion or anything else, once you disable things like magic_quotes and register_globals (which is recommended practice)

      The point was why the hell do they exist in the first place?. PHP is insecure by design (in the broadest sense of the term, since PHP has no language design to speak of). Doesn't it bother you that the Zend devs built that level of insecurity in the core language, enabled it by default and are only now thinking of removing it for the next version or the one after that?

      --
      "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
    5. Re:"Accelerating" PHP is a waste of time by wonko_el_sano · · Score: 1
      PHP security doesn't suck any worse than ASP or Perl

      Have you even heard of "taint-mode" in Perl? It's a built security mode to make sure no user supplied data can ever make it's way into sensitive areas (system calls, filenames, etc) without have been "untainted" first. I'd say that's a pretty big difference in the security of the languages.

    6. Re:"Accelerating" PHP is a waste of time by 00lmz · · Score: 1

      You say that VBScript is bad, but please note that the ASP object model is pretty nice, and that you can access it through any ActiveScript language. Windows comes by default with VBScript and JScript, but you can also use PerlScript, ActiveRuby, and Python (with the Win32 extensions). That also means you get to use the libraries of those languages, which are a lot better than what VBScript itself has to offer.

    7. Re:"Accelerating" PHP is a waste of time by Anonymous Coward · · Score: 0

      I'm trying to remember the last time I witnessed such a content free display of a poster's complete lack of clue, and I must say, I cannot; well done sir, well done.

      While it is true that there is much to dislike about PHP, and many of its purported advantages over other languages for web development do in fact not exist, you have managed to completely miss all such in favor of ill-informed and cliched phlegm du jour.

      I should not poke fun, it is surely not easy being so ignorant; my apologies and condolences.

    8. Re:"Accelerating" PHP is a waste of time by houseofzeus · · Score: 1

      It checks that you do *something* that *could* untaint it. The fact of the matter is a lot of people (read: the same types of people who write shit PHP) still have ample opportunity to screw up. PHP does have design flaws (though gradually these are being weeded out it has taken longer than it should have) but at the end of the day I think its bad rep has a lot more to do with the kind of 'developers' it has attracted.

    9. Re:"Accelerating" PHP is a waste of time by Anonymous Coward · · Score: 0
      or the wonderful Register Globals that was finally turned off by default (not even removed) in PHP 4.2.0.

      Of course it's not removed. It's perfectly possible to write PHP code without any security problems even with register_globals on.

      Some people were able to write non-shite PHP -- quite a feat, since it's still PHP -- even when the language went out of its way to make it easy to fuck things up. No reason those folks should have to rewrite their working code just because you and the other droolers bought computers.

    10. Re:"Accelerating" PHP is a waste of time by mdfst13 · · Score: 1

      register_globals is only a security flaw if you write bad code. Yes, it allows variable poisoning. However, it *only* does so if you use undefined variables.

  11. Farewell PHP/Zend by Anonymous Coward · · Score: 0

    http://nekovm.org/

    1. Re:Farewell PHP/Zend by masklinn · · Score: 0, Troll

      Woonderful, these tools reimplemented ECMAScript, fucked it up with ugly, $-prefixed builtins, dumbed it some more and then sprinkled their spec with illegible english. What an awesome language not to code in.

      --
      "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
    2. Re:Farewell PHP/Zend by Anonymous Coward · · Score: 0
      What an awesome language not to code in.

      Correct.


      Neko was intended as an intermediate language, designed to be easy to generate and parse, not to be hand-typed by humans. The VM is lightweight and performing well with JIT due in the next release. It's all in the documentation if you care to read it before spouting off like a child. ( I know, I must be new here. )

    3. Re:Farewell PHP/Zend by masklinn · · Score: 1

      Yeah, that's probably why the very first paragraphs of the front page tell me i can code in neko...

      --
      "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
    4. Re:Farewell PHP/Zend by Anonymous Coward · · Score: 0

      Well you can, you can also code in assembler or binary if you have the time. No reason to say that a scheme compiler shouldn't produce C which is then compiled to platform specific assembly and finally to native executable. Neko is already bootstrapped, take a look at nekoML.

  12. Yeah, but do they even work? by Anonymous Coward · · Score: 0

    I've tried to use these PHP accelerator thingies (except Zend's) on a large Horde/IMP installation. It turns out we started getting random bugs and disconnections, as well as corrupted data. Do these things even work? Specially with PHP5, object-oriented code and in a large system with thousands of simultaneous users?

  13. eAccelerator is great by bahwi · · Score: 1

    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.

  14. Easy by Anonymous Coward · · Score: 0
    all the accelerator products are for .net, making me wonder what microsoft's internal acceleration features are good for.
    Those features are for accelerating sales, not run-time performance.
  15. PHP5.1 + eAccelerator Re:eAccelerator is great by NuShrike · · Score: 1

    Eh? I'm running Wikimedia 1.6.3 with PHP 5.1.4 and eAccelerator 0.9.5.b2 http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/ea ccelerator/ ...

    OH I see.. I'm using a version that works fine with PHP 5.1+. Fairly quick on this quad-550Mhz Dell.

    The only stupid part is updating from PHP 5.1.2 required a recompile of eAccelerator.

  16. But there's nothing uglier than Perl ! by Anonymous Coward · · Score: 0

    Variables global by default? Default variable $_? Auto-converting arrays to array_size in scalar context? Parentheses hell when using multi-dimensional arrays?

  17. Really necessary? by MrZaius · · Score: 1

    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?

    1. Re:Really necessary? by rgigger · · Score: 1

      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.

  18. 21 hosts == thermo-nuclear meltdown by Anonymous Coward · · Score: 0

    Your bottleneck would be database load which varies per page (or per request). Typically, you wouldn't run into PHP performance issues with hundreds of users and your machine will probably run up against hard limits in your httpd.conf well before then. If you want a better answer, you can use the Apache benchmark tool ( $APACHEROOT/bin/ab ) to test your specific application and fill up your httpd logs.

  19. bah by Anonymous Coward · · Score: 0

    what a waste of webspace.

  20. learn your perl pragmas: use strict; by Ayanami+Rei · · Score: 1

    And if you want to confuse lowly developers just omit that in a module and start throwing around implicit function compositions too:

    sub fix_bad_words {
        shift;
        my $BADWORDREGEX = shift || "(fuck|shit|cunt)";
        join map split $IFS, {/$BADWORDREGEX/ ? "*bleep*" : $_;}, $,;
    }

    Bonus points: So what does it do?

    --
    THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
  21. xcache from lighttpd by randommemoryaccess · · Score: 1
    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/
    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)
  22. Not ruby. by Anonymous Coward · · Score: 0

    Ruby is not compiled like perl, python, PHP, pike, etc, etc, etc. It's interpreted line by line just like a shell script. This is one of the reasons why it is so incredibly slow.

  23. PHP not copied from ASP by mgkimsal2 · · Score: 1

    (*: 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 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 soliciting input on what people liked/wanted in a web scripting system. However, I can't find any reference to that story anymore, and I might have just made it up in my head. :)

    --
    creation science book