Re: [WAY OT] Re: PL/java? - Mailing list pgsql-general

Daniel, thank you kindly for your input.

However, mod_perl is absolutely slower than most any j2ee application.
If all you are doing is keeping a session variable to count number of hits
on a web page, then sure, perl is more than sufficient, possibly faster.
But when you start doing anything of importance, enterprise level stuff,
you need something scalable in ways java can go, but perl just doesn't
seem to have _easy_ or sometimes _existant_ ways to implement.

How would you go about synchronizing session data on 10 application servers
running mod_perl _without_ using the database to "mirror" that data in
memory? It's not very difficult to do it in Java. (Ofcourse, any smart
architect would use content switches generally to keep a remote user
associated with the initial app server to reduce the necessity of such
"replication" technologies).

Not sure how you are associating me with windows, but no, all my server
stuff is always *nix. My answer on awt and swing was in reference to
someone else who was basing their opinion of java on awt/swing's
capabilities. Regardless, "applets" using awt/swing can be easily run
under Linux Mozilla or Netscape, or HotJava, etc. So you can't really
say that's enough to assume we're talking about windows.

-Knight

-----Original Message-----
From: Daniel Kalchev [mailto:daniel@digsys.bg]
Sent: Friday, August 31, 2001 11:25 PM
To: Alex Knight
Cc: Alex Pilosov; pgsql-general@postgresql.org
Subject: Re: [WAY OT] Re: [GENERAL] PL/java?


Well,

mod_perl is not exactly slow... and I believe any JAVA program will be
slower
than the respective PERL program (there are newbie books for both languages
:)

But, perhaps you talk WINDOWS? If so, any software on WINDOWS can be slower
than any other software on WINDOWS... just because they happen to link so
some
weird DLL.

Daniel

>>>"Alex Knight" said:
 > Not really.
 >
 > Yes, AWT sucks. Yes, Swing sucks. Java's gui code can be INCREDIBLY lame.
 > But for server-side situations, Java can be incredibly scalable.
 >
 > I wasn't comparing a perl CGI script and a J2EE server, other than saying
 > perl simply doesn't offer what J2EE does. Furthermore, I've seen more
 > newbies
 > write perl cgi scripts in an enterprise environment and break the site
 > the minute traffic picks up.
 >
 > IMHO, scalability is incredibly important, and perl leaves that out
often.
 > Even with Fast-CGI style servers, perl sucks. Perl is great for admin
 > interfaces, or low to medium traffic sites.
 >
 > -----Original Message-----
 > From: Alex Pilosov [mailto:alex@pilosoft.com]
 > Sent: Friday, August 31, 2001 7:35 PM
 > To: Alex Knight
 > Cc: pgsql-general@postgresql.org
 > Subject: [WAY OT] Re: [GENERAL] PL/java?
 >
 >
 > On Fri, 31 Aug 2001, Alex Knight wrote:
 >
 > > It is generally wiser to split the webservers from the appservers;
 > > that will save on memory footprints from each respectively. That alone
 > > can give each machine a specific task to accomplish... generally more
 > > efficiently. But I would assume you know this.
 >
 > And it is wise to split database from middleware, and not try to saddle
 > PostgreSQL with requirements to support Java in-process. _IF_ java stored
 > procedures are implemented, it should be via something like a) oracle's
 > extproc (start a separate process to load the function) b) some of perl
 > java tools (they start a jdk in a separate process and communicate with
it
 > using RMI).
 >
 >
 > Problem with java-pgsql integration is the threads model: Java really
 > really wants threads. Postgres doesn't do threads. So if most simple way
 > is attempted, you will incur overhead of starting up JVM for each backend
 > (a few seconds as opposed to milliseconds) and non-shared 30M of memory
 > per backend (as opposed to currently <3 megs of non-shared memory per
 > backend).
 >
 > > Using something like WebLogic, WebSphere, or Orion would be a wiser
 > > approach. For the company with the low budget, Orion is only something
 > > like $2000, and it has full J2EE support, including EJBs, etc. Try
 > > finding that kind of richness in Tomcat. Also, Orion takes up only
 > > 40-50mb at start, which is really fairly reasonable; ram is cheap
 > > anyways... a server that has to perform complicated algorithms to a
 > > large audience but has hardly any ram shouldn't be on the internet
 > > anyways; unless it can handle it.
 >
 > _ONLY_ 40-50Mb?! Egads, I'm hard pressed to find any other piece of
 > (non-windows, non-java) software that takes 40-50M just to start up!
 >
 > I worked with both CrapLogic and CrapSphere. Weblogic takes 20-60 seconds
 > to start up on P3-800, that, IMHO, is ridiculous.
 >
 > It is not only issue of memory, its easy to throw memory at the problem,
 > its an issue of _incremental use_ of memory. As you scale
 >
 > > I feel that you don't really have enough experience with _java_ to
 > > judge it accurately. Frankly, the JVM is quite small nowadays,
 > > considering the amount of base classes that sit in memory much of the
 > > time. And the JVMs are really much faster these days. Java is still
 > > slow for 2 reasons: 1) Developers who don't optimize their code as
 > > they write it, 2) Bytecode interpretation is and probably never will
 > > be as fast as something like C/C++. But it certainly isn't the JVM
 > > itself slowing it down because of some "extended memory" that it lives
 > > in. Any reasonable server should have absolutely no problems if the
 > > jvm is implemented _properly_ (which many packages do not do), etc. If
 > > you're comparing Java to perl, yes, certainly it's a bit more of a
 > > beast, but perl quite simply can't keep up in speed and feature
 > > richness (when was the last time you secured your perl code in a
 > > redistributable fashion?)
 > _WHY_ the heck do all base classes need to be in memory all the time? Why
 > are they so huge? Libc is _far far_ smaller, and libstdc++ is tiny
 > compared to all the java standard library.
 >
 > You know what the answer to it is: Because they are ALL written in java,
 > as opposed to more sane languages like perl which handcode their
"standard
 > libraries" or the most important pieces of them in C.
 >
 Perl is far faster than java in about any practical application I did.
 > Again, the issue is not speed of JVM versus PP (perl virtual machine), if
 > you did number crunching in perl and java, they would probably be at par.
 > Its an issue of standard libraries. They are _horribly slow_. Perl's
 > hashtables are a very nice piece of optimized C code. Java's hashtables
 > are written in Java. Need I say more? Java's AWT was a dog. Swing is a
dog
 > and a half, because they reimplemented all the things that are commonly
 > done in C in Java.
 >
 > > The only mistake the developers can make is poorly implementing the
 > > jvm, but most certainly not Java itself. I've been working on
 > > architecting and building enterprise level sites and applications for
 > > nearly 8 years now, and I've seen too many people try to implement
 > > perl cgi websites for enterprise sites and watch them choke and crawl
 > > to their knees because of poor system resource handling, lack of
 > > scalability, etc... I most certainly don't consider a single webserver
 > > with an appserver and tiny database to be enterprise level either (not
 > > that I'm inferring you said it was).
 > You cannot compare a perl CGI script and a J2EE server. Its like
comparing
 > a webserver you wrote yourself vs apache! There are application servers
 > (or more closely, code libraries) for perl that match what J2EE provides.
 >
 > --
 > Alex Pilosov            | http://www.acedsl.com/home.html
 > CTO - Acecape, Inc.     | AceDSL:The best ADSL in the world
 > 325 W 38 St. Suite 1005 | (Stealth Marketing Works! :)
 > New York, NY 10018      |
 >
 >
 >
 > ---------------------------(end of broadcast)---------------------------
 > TIP 3: if posting/reading through Usenet, please send an appropriate
 > subscribe-nomail command to majordomo@postgresql.org so that your
 > message can get through to the mailing list cleanly