On Sun, 10 Dec 2000, Gunther Birznieks wrote:
> >I'm currently using the Tomcat at work, and I have to say that
> >although I really love perl and mod_perl, there are real advantages to
> >using java. Over the past couple of years that I've been mostly
> >lurking on this list there have been a couple common threads:
> >
> >1) Memory Usage: embedding the perl interpreter on every process uses
> >lots of memory. This of course can be tweaked and isn't as bad on
> >good OS's, but it is a common thread.
You can do the twostage server if you are short on memory, speed is
important and usage of active content is relatively low. Setup a mod_proxy
and stripped down apache for port 80 and mod_perl for port 8080 for
example. Proxy certain urls to the 8080 and you are good. Set low number
for the mod_perl items, to avoid thrashing. I'd see where Java is weak,
integration wise like 2 MB per process and not even integrated string
processing.
> >2) Sharing information between the processes. There's lots of
> >different ways to do it, but none really jumps out as an end-all
> >solution.
Java movement has stretched out itself too thin, they did not identify
themselves with a particular niche, and so we did it for them, where they
don't really excell either - web applets, flash is more fit for that sort
of thing. Perl is not very known for doing gui but spreading out knowlege
about perl/tk helps. Which is just as good as AWT(? not sure of the name)
> >With a system like Tomcat running in a jvm outside of apache, you only
> >have one jvm, and you get things like being able to share a cache
> >between all sessions alot easier.
So is with FastCGI, reinventing the wheel man is not a good thing.
Sun people are on this thing to rewrite the world and put a Sun stamp on
it and make everybody use it. Whahoo.
> >I personally find the configuration of mod_perl to be more straight
> >forward than Tomcat, but I do see some advantages to that system (I'm
> >sure there are some speed disadvantages to the tomcat communcation,
> >but haven't done any benchmarks).
Try FastCGI, it is really fast if you can do multiplexing. Besides the
fact, I will write apache C modules if I need speed, not use some unproven
languages to handle maximum loads, with lowest response time.
> >That being said, I wonder how difficult it would be pull the perl
> >intepreter out of mod_perl and run a perl stand-alone multi-threaded
> >daemon which listens for mod_perl api calls... :)
>
> This is very similar to SpeedyCGI + mod_speedy. Although it's more like a
> servlet engine model than actually get access to Apache API. SpeedyCGI is
> not web server specific (except the mod_speedy module).
Good one. However would you really get the advantage of performing
configuration manipulations on the fly? Or dynamic generation of the
configs form templates and lists of values?
>
> >Things I would never even try with java:
> >
> >1) Talking any client/server protocol other than URLs. The perl
> >mail/ftp modules are so easy to use and they work great. I don't even
> >want to think about writing to syslogd from inside java... :)
>
> There have been public domain libraries to write to syslogd in Java for a
> long time. The only problem with Java in this regard is that there is no
> CPAN. But if you search on the net, you can usually find something in Java
> that has the equivalent to a CPAN module that deals with networking as Java
> makes networking quite easy.
Sun was not onto community thing anyways, they're corporation, and giving
up a control something they spend money on, will give chills to the
managing types that are not for the OS thing.
No CPAN is an oversight for the Java people, but really how can they
implement it? Java runs across many platforms and VMs for it are written
by many companies. If one dares to do something like that.
For one they have to figure out how not to breach security of systems
where people will be installing custom java classes. Java like windows2000
was touted for the security and CPAN like thing will bring some bugs and
holes into the frame work I am almost sure.
happy hacking,
pavel
