Re: [WAY OT] Re: PL/java? - Mailing list pgsql-general
From | Alex Knight |
---|---|
Subject | Re: [WAY OT] Re: PL/java? |
Date | |
Msg-id | MAEFKNDLAHNIFMAIEGHJCEKLCDAA.knight@phunc.com Whole thread Raw |
In response to | [WAY OT] Re: PL/java? (Alex Pilosov <alex@pilosoft.com>) |
Responses |
Re: [WAY OT] Re: PL/java?
Re: [WAY OT] Re: PL/java? |
List | pgsql-general |
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 |
pgsql-general by date: