Re: PL/java? - Mailing list pgsql-general
From | Alex Knight |
---|---|
Subject | Re: PL/java? |
Date | |
Msg-id | MAEFKNDLAHNIFMAIEGHJCEKJCDAA.knight@phunc.com Whole thread Raw |
In response to | Re: PL/java? (Shaun Thomas <sthomas@townnews.com>) |
Responses |
[WAY OT] Re: PL/java?
Re: PL/java? |
List | pgsql-general |
I'm very sorry that you've had bad experiences with Java. Apparently they seem tainted. Part of your problem is that you were using inexpensive java application servers (tomcat) that, IMHO, need plenty of optimization and fine tuning before they can be used to successfully deploy an enterprise application. Apps like tomcat are _great_ for development, but anything more than that, and you will most definately run into situations like you described. Ofcourse, there are probably those that slip through the cracks, and still have a successful deployment of these lower-end app servers and still survive with hundreds of thousands of hits per day. 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. 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. 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?) Oracle 8 and Oracle 8i are really two different dbs. I've personally seen much improvement with 8i, and in comparisons between legacy oracle8 dbs versus oracle8i containing the same live database structure and data (10 million+ rows) we've seen IMPROVEMENT in our query timings. It isn't java affecting 8i in a negative way unless ofcourse you are actually embedding java code, in which case, could easily be your code affecting the db if not watched carefully. The only time garbage collection has been a problem, is when software companies start tampering with the jvm or create their own pseudo garbage collection, like IBM does with WebSphere (*cough*). WebSphere can be truely dangerous. Adding java support in postgresql does not mean that it will affect users in any way that, by default, will not even compile in support for it. How will that affect users who feel no need for it? Furthermore, I strongly disagree that adding Java support will make it "larger, slower, memory leaking, more crash-prone". Like any products, languages, or even situation, there are well written devices, and poorly written devices. Your bad experiences with Tomcat have surely stained you against java. If you have the time, I suggest you go download a free copy of Orion (orionserver.com) and see how incredible true enterprise J2EE can be. 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). -Knight -----Original Message----- From: Shaun Thomas [mailto:sthomas@townnews.com] Sent: Friday, August 31, 2001 9:28 AM To: Alex Knight Cc: Gowey, Geoffrey; 'Dr. Evil'; pgsql-general@postgresql.org Subject: Re: [GENERAL] PL/java? On Sun, 26 Aug 2001, Alex Knight wrote: > I keep hearing all this talk about Java being slow, and how compiled Java is > nearly as slow as interpreted languages... If Java was _that_ slow, do you > think it would be powering a majority of the Enterprise level sites out there? Have you ever actually used Java on an enterprise-level application? Ever see the Tomcat webserver? It uses 100MB of memory, drives the load on our server up to 8, and doesn't serve nearly as fast apache. Do you really want that in your database? It isn't slow just because of the interpretation, or the byte-code, or the structure, or even the overhead. It's slow because every application must have a hulking JVM sitting in memory, bringing even fast machines to their knees in short order. Not even perl, with everything it does, is that big, nor does it affect a machine so adversely. Ever wonder why most JVM's stay in memory after they start? Compare the speed of Oracle 8 with 8i if you don't believe me. The stability is also much worse. Ever see a JVM on any platform that didn't crash if you looked at it cockeyed? Ever really trust the garbage collection? I don't. I've found a memory leak in IBM developed java libraries. Gotta restart that app every once in a while to reclaim system resources it gobbled up and never gave back. Merits of the language notwithstanding, I'd rather not have a buggy, still under development (depreciating everything under the sun with every new iteration) JVM parasite in my DB. So... you want a larger, slower, memory leaking, more crash-prone DB just to have java support? Personally, I hope the Postgres developers don't make the same mistake as the Oracle developers. Yuck. -- +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | Shaun M. Thomas INN Database Programmer | | Phone: (309) 743-0812 Fax : (309) 743-0830 | | Email: sthomas@townnews.com AIM : trifthen | | Web : hamster.lee.net | | | | "Most of our lives are about proving something, either to | | ourselves or to someone else." | | -- Anonymous | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
pgsql-general by date: