Slashdot Mirror
Benchmarking 3 PHP Accelerators
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)."
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
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...
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..
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
What about Turck MMCache?
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.
I would very much like to see a comparison of the three against established performers in different languages. For example: mod_perl.
1;
http://nekovm.org/
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
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.
/* libAnonCoward.php */
function Redirect($location) {
header("Location: $location");
die;
}
function MapPath($file) {
return realpath($file);
}
perl -e 'foreach(values %SIG){$_="IGNORE";}while(){}'
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?
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.
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.
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".
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...
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
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.
Variables global by default? Default variable $_? Auto-converting arrays to array_size in scalar context? Parentheses hell when using multi-dimensional arrays?
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?
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.
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.
what a waste of webspace.
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
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.
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.
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.
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.
(*: 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
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.