http://qs1969.pair.com?node_id=487630


in reply to Re: Help prevent a ModPerl application from replacement by Java
in thread Help prevent a ModPerl application from replacement by Java

Fellow Joost

I'm actually using mod_perl, as Catalyst provides a content handler.

The Java test was made with just 5 seconds of "ramp-up" time. Perl was running under the same conditions. Is that fair?

My machine shares the Intel Pentium 4 Processor 2.8 GHz and 512Mb Ram with Oracle (nicely tunned to use less memory as usual) with the Tomcat (only when running Java) or Apache/ModPerl (only when running Perl). I know this is not the best situation, but this is what I have.

We're using the same machine to run tests, just shutdown the application (Java or Perl) that will not be tested and run tests against the other.

I don't know a lot about the Java code. I guess its simmilar to the Perl code, but this is only a guess. I'll ask about this to the Java programmer tomorrow moring.

I don't know about the templating system, also. Maybe just servlets, the java application was made on sunday, only for the benchmarks.

My Catalyst::Plugin::Session::Flex is trully serializable (and just hold some integers, anyway).

I choosen to use Apache::DBI to handle the database connections, and load it from my httpd.conf file.

Guess Java is using just one or two database connections, while I'm forced (not sure about "forced") to use a connection per server process.

You gave me nice tips on what to look for at the Java code so I can state if this is a fair benchmark. Thank you very much and may the gods bless you!

Replies are listed 'Best First'.
Re^3: Help prevent a ModPerl application from replacement by Java
by Joost (Canon) on Aug 30, 2005 at 11:02 UTC
    The Java test was made with just 5 seconds of "ramp-up" time. Perl was running under the same conditions. Is that fair?
    Depending on your setup, it could take the perl version longer than that to open a connection for every apache sub-process. That would slow things down considerably.

    It's also possible that your apache subprocesses don't handle many requests before they are replaced by fresh ones (which also means opening a new database connection).