Slashdot Mirror
Mod Perl or Servlets?
A nameless submittor dropped this in my inbox: "I've heard people comment that Java Servlets are better than Perl CGI scripts. I've also heard the counter comment that while Java Servlets beat Perl, Mod Perl beats Servlets. I don't want to start a flame war, but I'm like to see the meat of this debate. Which is the better tool for server side web development? This is an area I'm about to get into and I'd like to see the pros and cons of each." I won't comment, if I did it would show my obvious Perl bias.
I personally have only used perl (and mod_perl) and I can tell you that mod_perl is *fast*. And it does encourage you to write cleaner perl code. But, as with most things perl, you can also twist it and kludge around mod_perl's requirements/limitations with even uglier code :)
Given that performance was similar, I would probably choose to use Java servlets, if only because Java is a cleaner language than perl (IMHO).
Have a peek at http://www.chamas.com/hello_world.html. This is a comprehensive benchmarking site for all types of backkends for webservers and includes mod_perl and jserv/servlets.
According to the site your servlets will be running about 10 times slower than perl.
Firstly, who is going to be maintaining the code? If you're going to be the only programmer working on the project, the decision is easier, but if there are several people involved, you need to take overall effort into consideration.
:)
Secondly, which language is more familiar? To programmers who have worked primarily in strongly-typed languages (especially C/C++), trying to learn Perl is quite often a maddening process, whereas Java requires a much smaller mental shift. A Perl programmer trying to learn Java or C++, on the other hand, often finds it restrictive or unforgiving.
Thridly, which do you prefer? Personal preference for one language or another can change the way you feel about a project, and how much time you're going to devote to making things 'just right' even if it's already 'good enough'.
In fact, the only reason I've found to prefer one over the other on a purely funcional basis is that (IMHO, anyway) Java code is easier to share between programmers, because it tend to develop in better-defined blocks (let's hear it for OOP!).
And in the end, of course, trust your own experience above the opinions of others
Unless, of course, scissors can't cut rock...
First of all, I recommend the O'Reilly Servlet book.
Second, pick your servlet engine carefully. I saw the reference to some hello world tests in a previous post. The servlet tests look like they were run on Apache's servlet engine. Too bad its dog slow (last I read about it that is ~6 months ago--I'm sure that they will catch up). We used Servlet Exec, and it works well. Also, be careful to not to let yourself be misled by micro benchmarks.
Third, consider your needs. In our servlets we were able to take advantage of object caching, sophisticated object to relational mapping tools and CORBA connectivity to back end services. There's a very nice java servlet framework called Webmacro, which is free (as in software not beer). I also see potential in JSP's, although I have no direct experience with them.
I also saw some comments about Java being slow. Yes, that's true. However I would venture to guess that its fast enough for all but the most demanding applications. Comments from another post said that you'll require serious hardware to do servlets. No doubt. However, computers are getting faster and so are Java VM's. I'm sure that Java will be fast enough for those demanding applications in the next couple of years, and my opinion is that if you want to be ready to slide down that slippery slope (like Chevy Chase in Christmas vacation) when its slick enough, then there's no better time to start greasing up with the right lubricant and getting the experience than now.
In short, we've had good luck with servlets. Developement has been quick (most of the development speed gained in Java is cut out from debugging when compared to c/c++ I can't compare it to perl though). The web sites have performed well. Personally, I believe that developer time is more valuable than CPU time, so I would recommend (IMHO) spending the extra dollars on hardware, and saving on the developement and maintenence.
Good Luck
I've finally found the off by one erro
...at my place of work, and settled on mod_perl. Part of the decision was based on performance: our site will have a lot of other junk slowing things down, so the scripting language has to be as fast as is practical. The main reason, though, was the documentation available. In a few weeks of scouring the net and the bookstores for information about doing the sorts of things that we'll be doing, I was much happier with the quality and quantity available for mod_perl.
ISP's, Programming languages, Operating systems, CPU Architecture, Pretty coloured workstations... can you see a pattern developing here?
Everyone has their own personal favorites be they better or worse, faster or slower, and most people will defend to the death their personal choice even in the face of logical debate. I wouldn't be so naive to state for one moment that PERL is the definitive and only choice. It happens to be my personal favorite for many reasons. I'm always happy to learn new code, new tricks and new languages to get results but always consider the options within my current capabilities first.
One word I would prefer not to involve in this debate is the word "better". I wouldn't say that PERL is necessarily "better" than Java Servlets, nor vice-versa. What I would say is that I am comfortable with PERL, I can bodge a script together quickly and see results with the minimum of debugging time. Determining what language is "better" in a particular scenario depends very much on the programmer as much as on the language options themselves.
I'm quite sure that I've used PERL where Java Servlets may be mare efficient, possibly quicker and perhaps even more versatile. What is important to me is that I can achieve the end result I require, and I can hack and hack at the script to my hearts content should my end result change at any time. There may come a time when I decide that investing the time to learn Java to a high level is a valid use of my time, but for now I'll stick with what I know for as long as it works.
My advice would be not to start a holy war with both sides adamant their code is better. If it works and you're comfortable with it, use it. If you're struggling and perhaps starting out and wondering which path to choose, then listen to both sides and then decide. Most importantly, a script that works reliably is infinitely better than a flashy, high speed application riddled with bugs.
Incidentally, although you can see my obvious bias towards PERL, much of the work for my customers does actually contain Java Servlets - just that I don't personally write them. I have a team of 4, and don't particularly care how we achieve results as long as I have the backup and knowledge in my team to ensure our products work reliably and we can confidentally put our names to them.
I never forget a face Madam, but in your case I'l make an exception - Groucho Marx
Philosopher (n) - a wise person who is calm and rational; someone who lives a life of reason with equanimity
I see the opposite in those same benchmarks. I'm not promoting Java. I'm just looking at the table you refer to. Look at the hits per second *per MHz*, not the simple hits/s column. Java is running on a machine with only half the processor speed, and when you compensate for that, Java servlets outperform mod_perl (again, in *these* benchmarks, for what they're worth.)
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
I don't think anybody's mentionioned Python yet. Without extensive knowledge of the other alternatives, all I can say is that with a little care PyApache works for me. It's much like usual CGI in use, with some tricks like a dictionary for each Apache child process.
There's a different implementation of the same idea (embedding the python interpreter) called httdapy, I think, that's a little deeper into Apache interface-wise; I seem to recall it would work with Zope, too. That project is a "web application server" done in Python, if you haven't heard of it yet.
For quick and dirty sites, and if you already love Perl, then mod_perl is fine (personally I think PHP is easier). For sites that have a very limited scope, and for those which code maintanence does not matter, go ahead and pick a scripting language you are comfortable with. The whole point of those scripting languages is to enable rapid development. mod_perl allows you to take the rapid development to a web server.
If your application is large, or needs to scale, you will need to engineer the site, not just hack/script it. Today's extensive interactive sites need to cope with thousands of users and millions of hits. True, mod_perl will handle it as far as execution is conserned, but a n-tier, engineered application will create a better solution.
For those n-tier type applications, servlets are only part of the solution.
In a true n-tier web application, you will see many partitions emerge. Some of those partitions are
You will also see that servlets (and Java Server Pages) only fit in the presentation layer. To create a scalable application, you will want to abstract the business logic from the presentation. There are many solutions for business logic, and the Java universe promotes EJB.
The point is that to correctly choose a development environment, look at the scope of the application. If it's large, it must be correctly engineered, and a true OO language such as Java has a lot of advantages going for it. Those advantages include architectures such as servlets, JSP, fast server side VMs, rich class heirarchy, EJB, and support for latest XML/XSL technologies.
Please don't bullshit us with your biased benchmarks of servlets vs Perl CGI. This "Ask Slashdot" is talking about mod_perl vs servlets.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
I work purely with mod_perl, so I won't disservice you with biased rumblings of how I think mod_perl is better - follow the advice of another poster here: Pick whichever tool your company/team has more experience with, and feels most comfortable working with. That's the only decision that should matter. Good perl people are expensive (as are good Java people - but the perl ones are harder to find/employ) though.
My tip is simply if you go the mod_perl route, please don't pick the no-brainer Apache::Registry route (this is a CGI-emulation mode). It will just in the long term cause you more troubles than it's worth. If you're working on an application complex enough to require choosing between either mod_perl or servlets then it's large enough to sit down and design it well. First design it without even thinking about the language: Think objects. Then work that into mod_perl. And use the mod_perl API to the full - there are some very cool things in there, like the $r->notes and $r->pnotes methods.
Also, mod_perl is far more than just a way to develop applications. You can do anything you can imagine to the actual Apache server with mod_perl - which makes it an indispensible tool for sysadmins. Witness Randall Schwartz's recent web techniques column on stopping naughty IE5 offline downloaders from sucking all available bandwidth, all done in mod_perl. (may not be available on stonehenge.com yet - try the mod_perl mailing list archives).
Finally, buy some books:
"Writing Apache Modules in Perl and C" by Doug MacEachern and Lincoln Stein. Excellent guide to everything mod_perl.
"Object Oriented Perl" by Damian Conway. Superb guide to doing things right the OO way in perl.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
The first book you name seems to imply that you have to use CGI.pm to do things like take apart POST requests, and therefore you couldn't avoid ::Registry altogether. There's a ::RegistryLite (or somesuch) that does the same with slightly less emphasis on strict CGI compatibility, and there's a module designed to do away with the need for ::Registry but that hasn't been released to CPAN yet because it's barely ready.
So what am I missing?
--
Xenu loves you!
Taking apart requests is really really simple. You can either do it yourself (rip the code out of CGI.pm if you want to - it's only about 40 lines if you ignore the extraneous crap), or use the aprequest library and Apache::Request, which is on CPAN in DOUGM's directory (called libapreq IIRC). Read the book. It's all there.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
Read the context though. The whole question is about mod_perl or servlets. In that context, "which" becomes "which (mod_perl or servlets)". So please don't give us biased benchmarks. If you have benchmarks to give comparing mod_perl to servlets (and not using Apache::Registry), then I'd love to see them.
Matt. Want XML + Apache + Stylesheets? Get AxKit.