Re: [WAY OT] Re: PL/java? - Mailing list pgsql-general
From | Daniel Kalchev |
---|---|
Subject | Re: [WAY OT] Re: PL/java? |
Date | |
Msg-id | 200109010625.JAA10301@dcave.digsys.bg Whole thread Raw |
In response to | Re: [WAY OT] Re: PL/java? ("Alex Knight" <knight@phunc.com>) |
Responses |
Re: [WAY OT] Re: PL/java?
|
List | pgsql-general |
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
pgsql-general by date: