Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Perl Programming

Mod Perl or Servlets? 49

Posted by Cliff from the choices-choices-choices dept.
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.
This discussion has been archived. No new comments can be posted.

Mod Perl or Servlets? More

Mod Perl or Servlets?

Comments Filter:
  • Santa was very good to me and brought me the java servlets book, as well as the mod_perl book. A recent project forced me to look for a way to implement pooled database connections. The servlet implementation seems quite nice, and I intend to invest some time with java. But as I wrote it in perl, I would be interested in how to do it under mod_perl. Is it as simple as never destroying the dbh? I found very little information, much less code snippets, but did discover that mod_perl makes you write clean CGI!
  • Um, maybe this is throwing another log into the fire, but did you look into PHP?

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

  • This has been hashed b4 countless times.
    To recap :
    [a] Perl is a quick hack of a shell scripting language that has grown exponentially by adding crap to it.
    [b] Java is a properly structured OO language that requires massive CPU power to do anything useful, hotspot VM engine or no hotspot engine.

    In short :
    [c] If your project is really small (think search engine/ website candy etc) and runs on shit hardware choose perl.
    [d] If you have a large maintainable project to write (think large banking app) choose Java..and your hardware better be decent or else.
  • We are in the same position here - we are a traditional mod_perl house, however a new project has us deplying Java servlets interfacing with GSP (Gnu Server pages - a kinda embeddable in html java) all running on mod_jserv.

    Have a peek at http://www.chamas.com/hello_world.html [chamas.com]. 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.

  • Ease-of-use (Score:3)

    by DarkRyder ( 103165 ) on Sunday January 02, 2000 @01:58PM (#1414761)
    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 :)

  • Servlet Experience (Score:3)

    by billr ( 71335 ) <bill.tekbot@com> on Sunday January 02, 2000 @03:04PM (#1414762) Homepage
    First of all, I recommend the O'Reilly Servlet book [oreilly.com].

    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 [newatlanta.com], 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 [webmacro.org], 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

  • ...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
  • I used to use mod_perl on my machine but I found
    php (http://www.php.net) to be much easier and
    very nice built in database support makes it easy
    to link to a database. Coding php is very similar
    to asp but with more power, yet is not as complex
    as perl. I still use perl for system scripts (cron jobs)
    and stuff but php is my web backend.
  • I am writing a servlet application to replace a large Perl app. The Perl app has performance problems and scalability issues. It is also proving difficult to maintain and enhance.

    Some of these problems could have been fixed with a redesign of the perl code (such as using a database to manage all the data we have).

    The replacement app uses database access, XML, XSL, business rules, etc. It also has to support thousands of sites.

    I've chosen to implement the replacement with Java servlets. Specifically I'm using Apache JServ, with MySQL as the database (soon to be Oracle). JServ11b3 performance is now on a par with the other servlet engines (they did some work with thread re-use). But more critically it is hardware scalable (i.e. you can cluster a bunch of machines together to increase your throughput). The Tomcat project (www.jakarta.apache.org) will also be an implementation to look out for.

    I've posted some material on servlet and Perl performance on my web site at Working Java [objexcel.com]. This includes a comparison of Perl to Servlet performance in a real life application.

    There are also a set of 'pure' helloworld benchmarks for Perl, Servlets, PHP, etc on lots of different hardware at ..... (the URL escapes me, anyone?)

    As the other posters have pointed out, your choice will depend on your requirements.

    For a simpler problem I may have gone with a simpler solution: Perl or PHP. (Actually I probably wouldn't becuase I'm comfortable/productive in the Java environment, but someone who was into Perl may do).

    I can vouch for a trouble-free time developing with servlets, lots of reference material, good implemetations of the spec to choose from, acceptable performance (and scalable across hardware), a productive environment, decent maintenance prospects (how does the joke go? Java is WORA - write once run anywhere. Perl is WO - write once and never understand again.

  • According to the site your servlets will be running about 10 times slower than perl.

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

  • (ker-thump) Another log for the fire (Score:4)

    by h2odragon ( 6908 ) on Sunday January 02, 2000 @10:36PM (#1414769) Homepage
    I don't think anybody's mentionioned Python [python.org] yet. Without extensive knowledge of the other alternatives, all I can say is that with a little care PyApache [egroups.com] 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 [zope.org], too. That project is a "web application server" done in Python, if you haven't heard of it yet.

  • Two Different Tools For Two Different Uses (Score:5)

    by marvinx ( 9011 ) on Monday January 03, 2000 @05:02AM (#1414772) Homepage
    Yes, you can certainly build interactive, dynamic web sites with both servlets and mod_perl. But to correctly build the site, you have to look at the scope of the site.


    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

    • client
    • presentation
    • business logic
    • data


    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.

  • mod_perl tip (Score:5)

    by Matts ( 1628 ) on Monday January 03, 2000 @05:45AM (#1414774) Homepage
    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.
  • I think you'll find the only question in the post is:

    Which is the better tool for server side web development?

    Maybe there is more to choosing a web development environment than mod_perl vs perl?

    (Expecting to get at least the 2 points for this post that the above flame got)

  • I cannot agree with the Apache::Registry comment more. That way lies pure madness. If you don't know what a closure is or do not understand the intracies of perl's scoping rules then do not use Apache::Registry for more than your simplest application. Weird things happen. Your variables will take on values that mystify you. You will post lame questions to the modperl list about it.

    mod_perl has so much more to offer than just Apache::Registry. Do not try to maintain CGI compatibility. Just bite the bullet and start writing mod_perl-specific scripts.

  • true. i dislike badly structured languages. it leads to badly structured code. so ?
  • I thought that Apache::Registry was the "good" way to use mod_perl and Apache::Perlrun was the "bad" way to run "dirty" CGI scripts. What am I missing? What do you use instead of Apache::Registry?
  • 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?
    --
  • 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.
  • 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.
  • "For quick and dirty sites, and if you already love Perl, then mod_perl is fine (personally I think PHP is easier)."

    Oh I hate this sort of flamebait. I've built a few non-quick and dirty sites in mod_perl. They've been n-tier. They've been maintainable. And they ran well too. You can write crap in any language. Provided you stay away from Apache::Registry or Apache::PerlRun, then your n-tier ideas and object oriented way of working will be practically unavoidable in mod_perl. Same as in servlets+EJB.

    "mod_perl will handle it as far as execution is conserned, but a n-tier, engineered application will create a better solution."

    OK, so write an n-tier application. You can do that in mod_perl or servlets. mod_perl is not all about speeding up CGI's. If you think it is, then you're missing the best damn web tool around. Sadly, slashdot thinks it's just about speeding up CGI's. :)

    Base your decision on 1 point and 1 point only: Who is going to develop and maintain your site (and what are their skills). Both tools are adequate. Both tools have excellent XML capabilities. Both tools have superb database access classes. Both tools support object oriented coding and separating the presentation layer. Only one of those tools is controlled by Sun (OK, that was flamebait :))...

  • OK, so write an n-tier application. You can do that in mod_perl or servlets.
    Perhaps I'm missing something here, but how does execute the perl code on a different machine from the web server when using mod_perl? After all, mod_perl is an apache module.

    The thing I like about servlet engines (such as Apache JServ), is that the Apache module simply checks the cookie and passes the request on to a separate java server. This can be a process running on the same machine, or one running on another machine across the network. It will deal with distributing the requests to multiple servers if you have several servers running your servlets. This does a lot for the scalability of the application; no matter how big your application, you can simply add more java server machines, and your web server sees no more compute load.

    cjs

  • I just completed a project using Servlets. We were able to complete the project on time and close to on budget (we'd have been below budget except for a last minute scope change). This was an upgrade away from a system written in perl (not mod_perl though). The customer's complaint was that the implementors of the previous system hadn't done a good job in documenting their code and as a result, the in-house maintainers couldn't follow the code and that led to large amounts of rewrite. Our system was half the number of lines of code and was twice the speed. But a lot of that optimization could be attributed to a very good analyst who gave us solid specs to code by. It's been my experience (and I've been at this a while now) that perl code is useful for smaller or single-shot systems. If the code has to be maintained by anyone else (or a different team) be kind to them and use Servlets.
  • Perhaps I'm missing something here, but how does execute the perl code on a different machine from the web server when using mod_perl? After all, mod_perl is an apache module.

    You are missing something here. Tiers do not necessarily mean separate machines. They simply mean separate subsystems. Building your code in a model-view-controller style with objects modeling your data is no harder in Perl than it is in Java, and it doesn't need to split across many machines to make it multi-tier.

    This does a lot for the scalability of the application; no matter how big your application, you can simply add more java server machines, and your web server sees no more compute load.

    The preferred configuration of mod_perl works exactly the same way, with a vanilla apache server up front serving static pages and images and proxying requests that require processing to backend servers running mod_perl. Even if you don't bother to separate things like this, adding more machines is no harder with mod_perl than it is with JServ.

  • Use the straight apache API. Or use something like HTML::Mason, which is implemented on top of the apache API.
  • At my company, we benchmarked mod_perl (handlers written to the apache API, not Apache::Registry scripts) against the fastest servlet runner out there, which is currently Resin from http://www.caucho.com/. The guy at Caucho had some benchmarks that showed servlets beating mod_perl and PHP, and we wanted to see if it was true.

    What we found was that the perl code in his benchmark didn't take much advantage of mod_perl. When we tried it ourselves, mod_perl beat servlets handily, and servlets actually fell apart doing database access under high loads.

    I have a lot of respect for what the Caucho effort and other projects like it are trying to do, but I'm afraid that on Linux the JVMs just aren't fast or stable enough to compete yet.

    We tested using the final released IBM JVM on a dual P450 machine with Red Hat 6.
  • What about php? I really got into that, it seems fast and stable, and it's so easy to learn, for anyone who struggled with perl and cgi, learning php will be like eating candy. php and a SQL database is the perfect team to create a dynamic website.

    //till

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

    Have you ever used EJB? If not, you might want to read this report on the current EJB servers: http://www.techmetrix.com/ [techmetrix.com]. It pretty much rips them apart. Point being, just because Sun and a bunch of other app server vendors tell you the technology they're pushing is great doesn't make it so. You may be better off using a more traditional OO development style, even if your project is in Java.

  • [a] Perl version 5 is a complete rewrite of Perl.
    [b] Java has some inherent uglinesses, and _slownesses_ (this is the fault of the language itself, not just the implementations).

    I'd have to agree with an earlier poster, who noted that you haven't rehashed anything useful at all.

    /* Steinar */

  • Recently, I've investigated using Java, specifically Java Server Pages and Java Servlets, to develop web applications. I found some important benefits to using Java rather than Perl. They are as follows...

    Pros:
    1 - Java is object oriented, Perl is not (although this is debatable). From a developer's view, the lack of OO features in Perl made the development cumbersome and less than elegant. By using OO, the code and application should be more versatile. I also think the OO features make Java much easier to maintain than Perl.

    2 - By mixing JSP and Servlets one can use the Model-View-Controller pattern. (As far as I know there is no way to do this with Perl or PHP.) This is a great way to develop web applications because it allows you to separate the presentation of your data with the logic that processes your data. If you look at some of the perl pages, they are a huge pain to read because of all the HTML mixed with the code. This means that a graphic artist could develop the "look" of the web page, and a software engineer could add a few lines of code to insert the data rather than doing all the programming and presentation in the same perl page. This will allow for concurrent development of the presentation and the logic.

    3 - Maybe the biggest benefit is that JSP and Servlets are platform independent. This is a quote from one JSP/Servlet developer: "All of these packages are Open Source and Pure Java and should run in any JSDK 2.0 or higher servlet engine and on any platform that the engine supports. Without *any* code changes. How cool is that? ;-) "

    Cons:
    1 - The Apache JServ engine seems to be pretty fast, but a good JSP engine costs $$. The performance issues can be can be overcome with a native compiler.
  • The "offline downloader" blocker is part of an upcoming column idea, and has not yet been written as a column. I'm still slowly tweaking the code. The mod_perl mailing list archives do indeed hold an older version of what I'm using right now.
  • You don't need to rewrite this. Apache::DBI (which comes with either mod_perl or DBI, I can't recall) does this automatically. It's as simple as putting "PerlModule Apache::DBI" in your startup mod_perl conf. Your existing DBI scripts go unchanged, and yet now cache all connections.
  • Java is no more OO than Perl is. If you want OO, then use Smalltalk. Otherwise, stay away from the hybrids, or please lump them in the same category. Basic is not OO. Perl, Java, C++ are all hybrid OO. Smalltalk and Eiffel *are* OO.
  • But PHP is only for the "content delivery" phase of Apache. mod_perl has hooks into all 11 phases. You can use Perl to write custom authentication, authorization, logging, and even URI-to-resource translation. And yeah, you can write content handlers too, but that's just one piece.

    mod_perl makes Apache scriptable from top to bottom. PHP is just a faster CGI. :)
  • As far as server based applications Java is CRAP. As my boss put it "you could throw that thing on a 128 proccessor symmetric server and it would instantly consume ALL of the processor cycles."

    I strongly disagree. I have a multi-user server application written in Java running on my Linux box. It scales to 2500-3000 concurrent connections (and probably more, but that's the max I've got so far) on mid-range Intel hardware. And that's on a JVM that is roughly 50-60% as fast as the industry-leading JVMs (Sun's JDK1.2 for Linux).

    If what you say is true -- and I have no reasons to doubt that -- something else has to be seriously wrong with your project. What JVM did you use? Have you profiled the code? Sounds to me that it's a programmer error rather than a platform/language error (no offense).

  • What kind of security?

    From (cr|h)ackers getting your servlets to do bad things: Java can't execute system commands from my knowledge unless you do some serious work to call native methods. Perl you have to check your eval() and other such calls, but I believe this has been automated for you.

    From users putting in naughty servlets: From my understanding servlets run in the servlet sandbox(the servlet engine). Much like applets have a sandbox(your browser) that lets you can set what they are allow to do, you are supposed to be able to do this with servlets also. But I haven't actually seen this put into action. While glossing through a Java Security book I noticed this, but didn't read into depth about it. Last I checked there isn't a way to do something similar with perl.

    Encryption/Decryption: Java's JCA and JCE is pretty cool. I've been learning this lately and it is fairly nice. There are many implementations of JCEs that provide a variety of algorithms. Also with the JCA and javax.crypto package you can switch out your Provider without changing your code, mearly a one line change to the file jre/lib/security/java.security. As long as the new Provider has an implementation of the algorithm you specified you're golden. I imagine perl has a wealth of crypto modules but I've never used any of them.

    --

  • Okay, I'll respond directly to this since you
    can't play nicely with others... :-)

    I'm in the process of replacing a bunch of mod_perl scripts for a large internet game
    company. The problem the company had was that
    the mod_perl stuff was eating up all memory
    to the point where it was regularly crashing
    their machine - this, just to handle their
    daily newsletter and other subscription services.

    In my opnion, the scripts used to handle this
    basic service were hacked and not developed
    properly at all - I had to search down mutlitple
    scripts and lay out exactly what call what ...
    It was a mess and to top it off, no documentation.
    Also, the scripts were writing to a dbm file to
    store things that had grown to over 66Megs in
    size - incredible when I found that most books
    recommended dbm for only small database stuff...

    Anyhoo, I've replace this with jdbc talking to
    oracle to maintain the lists and registration
    info - and with a servlet, this is a one time hit
    to open and keep the database connection - huge
    saving compared to having to thwack IO everytime
    with the dbm implementation and mod_perl. Also,
    my java servlet doesn't grow - it's been at a stable
    size... - compared to the mod_perl parts that
    were growing to 20Megs each (with 7 - 10 of
    these running at a time)... not good on a
    machine that only has 256M... Finally, I
    get portability - the code easily transfers to
    other platforms as we will eventually upgrade
    to more powerful machines...

    Anyway, just my 0.02 - yer mileage may vary...
    Oh, we're running Sparc-intel with Solaris 7,
    Apache and jserv with mod_perl also...

Slashdot Top Deals

An authority is a person who can tell you more about something than you really care to know.

Close