Not true, and I have it directly from several Yahoo employees. They uses PHP for a bunch of server-side include type of stuff, but a huge amount of their business logic is in perl. Nearly every property in Yahoo uses Perl, especially My Yahoo. They do lots of pre-generation of pages with Perl and then stitch things together with PHP when serving requests.
FYI, if you run PHP as an apache module, it does not run with the privileges of the user. That only happens if you run it through CGI, and of course the same is true of Perl when run through CGI.
Actually, mod_perl is running larger sites than Java or PHP right now. ticketmaster.com, citysearch.com, imdb.com, and of course slashdot itself. Although they don't use mod_perl, Yahoo and Amazon use Perl for major parts of their sites. So, it is a popular choice for building very large sites.
Coding with mod_perl is nearly identical to using Java servlets or ASP in terms of the processing model.
SizeLimit is actually not for catching runaways but for managing the slow growth that most perl scripts exhibit over time. It allows you to replace MaxRequestsPerChild with a better measure.
The front-end proxy is very helpful with dynamic content because it handles buffering for clients and lets your mod_perl processes move on immediately. This is also explained in the docs.
Glad to see people using mod_perl for fun stuff. Keep up the good work.
You should also reduce MaxClients to the point where they will not push you into swap, use Apache::SizeLimit to control process size, and run a front-end proxy. This is how large sites handle it. All of this is explained in more detail in the performance tuning docs on the mod_perl site, and we can answer any questions you may have on the list.
If you'd like some help tuning your mod_perl server, we'd be happy to oblige over on the mod_perl mailing list. Off-hand, I would say MaxClients at 256 sounds pretty high and may send your server into swap unless it has tons of memory.
Quality? My IBM ThinkPad is the worst laptop I've ever used. It has had two drive failures in a year, and it uses some bizarre wireless chip that is unsupported by most Linux distributions. I'd rather have a Gateway or Dell any day.
Not correct. The benchmark ran Resin for several minutes. You can download the code and run it yourself, or e-mail the author of the benchmark with any questions you may have. A company I used to work for sent Caucho a correction for their benchmark code years (literally) ago and they wrote back acknowledging that they know very little about mod_perl, but they never updated the benchmark page.
Actually, Perl and PHP do compile to their own opcode trees which get cached (by default in Perl or with an "accelerator" in PHP). Despite the flawed benchmark shown here, mod_perl is faster than Caucho. See this benchmark for more.
This benchmark is both ancient and wrong. I can't speak for the PHP code, but the mod_perl code is not done in the way that an experienced mod_perl programmer would do it, and thus does not demonstrate the best performance mod_perl can give in this situation. It would be better to look at this benchmark instead.
I worked at a large publishing company where IBM was pitching a new e-commerce system. They succeeded in concvincing our gullible CTO to buys their whole package, including proprietary hardware and AIX to run on it. When I suggested that Linux on Intel systems would be a better choice for a relatively low-traffic web service like this, they immediately starting running down Linux. They had nothing good to say about open source software in general, implying that the apache server they bundle is somehow a different species from the one anyone can download. In short, they like Linux when they can make money off it, and will rip it to shreds if they think they can sell you something more expensive.
Here in New York, employment is booming. The job posting lists I monitor are buzzing comared to where they were a year ago. I've started getting cold calls from recruiters again. And the last tech conference I went to was much fuller than last year's. I don't know anyone who would say the job market for programmers isn't dramatically better in 2004.
Meanwhile, a few months back their sales people talked the VP of technology at my last job into choosing AIX over Linux for a bunch of new hardware to run WebSphere on. Can you believe that? AI freaking X. Yes, I left that job.
It also turned out that their WebSphere IDE was not fully functional and up to date on Linux, only on Windows, and the web-based app for running their commerce system used JavaScript stuff that only works on -- you guessed it -- Internet Explorer.
That site is full of so much flaming and mindless shrieking, it makes me wonder how Java gets anywhere. Seriously, there are a few exceptions, but the average quality of comments there make Slashdot seem like a community of polite geniuses by contrast.
Not complex at all? Take a look at the UML diagram in this introductory article. I don't think form validation is really the point of JSF, but if you want to look at form validation in Perl, it is as very simple. Take a look at this example in the docs for CGI::FormBuilder for example.
I want Java to succeed, but I don't think it will ever be simpler than Perl for web applications.
You may have this perception because people rarely use PHP code to do heavy lifting. Or it may be that you've encountered many servers where people were actually running code as CGI, not mod_perl. CGI is slow.
Regardless, I have never seen a benchmark where PHP ran faster than mod_perl, and for the most part, performance differences between them are negligible compared to the performance differences resulting from well-written code vs. poorly-written code.
The previous poster was saying there were more PHP programmers, which is not supported by that stat. And of those PHP projects, how many have code that is reusable, i.e. not tied to specific HTML, won't clash with other people's function names, written as components, etc.?
Now with systems like Java Server Faces and Creator you can design a web form in a few seconds using a drag-and-drop designer, clip in some data validators, and visually design navigation through a complex website. A few more clicks and you have an single archive file that can be dropped into any J2EE application server, using any JDBC database on any platform.
I'll believe it when I see it. Right now, the situation is that Java Server Faces is a very complex API and mature tool support does not appear to be freely available. Beyond that, experienced coders (heck, even HTML monkeys) will usually tell you that the GUI tools only get you so far before you have to crack open the lid to get what you want.
Drag and drop dev tools have been promised for years, and they just never deliver enough to make coding obsolete.
I would actually consider JSP a bad example, unless you use taglibs. Something like WebMacro or Velocity would be better.
There are some large and complex sites written in Perl: TicketMaster.com, Amazon.com's newer stores, imdb.com, and others. PHP can be made to work in many situations, but Perl has more features for progamming in the large with teams and sharing code.
Slashdot Mirror
You clearly didn't actually read about the frameworks I pointed you to if you think they are just templating tools. Start with OpenInteract.
It gets better performance that way.
There are several frameworks for Perl.
Not true, and I have it directly from several Yahoo employees. They uses PHP for a bunch of server-side include type of stuff, but a huge amount of their business logic is in perl. Nearly every property in Yahoo uses Perl, especially My Yahoo. They do lots of pre-generation of pages with Perl and then stitch things together with PHP when serving requests.
FYI, if you run PHP as an apache module, it does not run with the privileges of the user. That only happens if you run it through CGI, and of course the same is true of Perl when run through CGI.
Coding with mod_perl is nearly identical to using Java servlets or ASP in terms of the processing model.
SizeLimit is actually not for catching runaways but for managing the slow growth that most perl scripts exhibit over time. It allows you to replace MaxRequestsPerChild with a better measure.
The front-end proxy is very helpful with dynamic content because it handles buffering for clients and lets your mod_perl processes move on immediately. This is also explained in the docs.
Glad to see people using mod_perl for fun stuff. Keep up the good work.
You should also reduce MaxClients to the point where they will not push you into swap, use Apache::SizeLimit to control process size, and run a front-end proxy. This is how large sites handle it. All of this is explained in more detail in the performance tuning docs on the mod_perl site, and we can answer any questions you may have on the list.
If you'd like some help tuning your mod_perl server, we'd be happy to oblige over on the mod_perl mailing list. Off-hand, I would say MaxClients at 256 sounds pretty high and may send your server into swap unless it has tons of memory.
It's the Atheros chipset, in an R40. You have to get Madwifi for it, which is not part of Fedora Core 3.
Quality? My IBM ThinkPad is the worst laptop I've ever used. It has had two drive failures in a year, and it uses some bizarre wireless chip that is unsupported by most Linux distributions. I'd rather have a Gateway or Dell any day.
Not correct. The benchmark ran Resin for several minutes. You can download the code and run it yourself, or e-mail the author of the benchmark with any questions you may have. A company I used to work for sent Caucho a correction for their benchmark code years (literally) ago and they wrote back acknowledging that they know very little about mod_perl, but they never updated the benchmark page.
Actually, Perl and PHP do compile to their own opcode trees which get cached (by default in Perl or with an "accelerator" in PHP). Despite the flawed benchmark shown here, mod_perl is faster than Caucho. See this benchmark for more.
This benchmark is both ancient and wrong. I can't speak for the PHP code, but the mod_perl code is not done in the way that an experienced mod_perl programmer would do it, and thus does not demonstrate the best performance mod_perl can give in this situation. It would be better to look at this benchmark instead.
I worked at a large publishing company where IBM was pitching a new e-commerce system. They succeeded in concvincing our gullible CTO to buys their whole package, including proprietary hardware and AIX to run on it. When I suggested that Linux on Intel systems would be a better choice for a relatively low-traffic web service like this, they immediately starting running down Linux. They had nothing good to say about open source software in general, implying that the apache server they bundle is somehow a different species from the one anyone can download. In short, they like Linux when they can make money off it, and will rip it to shreds if they think they can sell you something more expensive.
Here in New York, employment is booming. The job posting lists I monitor are buzzing comared to where they were a year ago. I've started getting cold calls from recruiters again. And the last tech conference I went to was much fuller than last year's. I don't know anyone who would say the job market for programmers isn't dramatically better in 2004.
INterestingly, PHP has the same problems in hosting environments, i.e. other users can mess with your stuff.
welcome to the party, PHP.
It also turned out that their WebSphere IDE was not fully functional and up to date on Linux, only on Windows, and the web-based app for running their commerce system used JavaScript stuff that only works on -- you guessed it -- Internet Explorer.
That site is full of so much flaming and mindless shrieking, it makes me wonder how Java gets anywhere. Seriously, there are a few exceptions, but the average quality of comments there make Slashdot seem like a community of polite geniuses by contrast.
I want Java to succeed, but I don't think it will ever be simpler than Perl for web applications.
Regardless, I have never seen a benchmark where PHP ran faster than mod_perl, and for the most part, performance differences between them are negligible compared to the performance differences resulting from well-written code vs. poorly-written code.
The previous poster was saying there were more PHP programmers, which is not supported by that stat. And of those PHP projects, how many have code that is reusable, i.e. not tied to specific HTML, won't clash with other people's function names, written as components, etc.?
I'll believe it when I see it. Right now, the situation is that Java Server Faces is a very complex API and mature tool support does not appear to be freely available. Beyond that, experienced coders (heck, even HTML monkeys) will usually tell you that the GUI tools only get you so far before you have to crack open the lid to get what you want.
Drag and drop dev tools have been promised for years, and they just never deliver enough to make coding obsolete.
There are some large and complex sites written in Perl: TicketMaster.com, Amazon.com's newer stores, imdb.com, and others. PHP can be made to work in many situations, but Perl has more features for progamming in the large with teams and sharing code.