From: | "Alex Knight" <knight(at)phunc(dot)com> |
---|---|
To: | "Shaun Thomas" <sthomas(at)townnews(dot)com>, "Alex Knight" <knight(at)righteous(dot)net> |
Cc: | "Gowey, Geoffrey" <ggowey(at)rxhope(dot)com>, "'Dr(dot) Evil'" <drevil(at)sidereal(dot)kz>, <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: PL/java? |
Date: | 2001-09-01 01:42:02 |
Message-ID: | MAEFKNDLAHNIFMAIEGHJCEKJCDAA.knight@phunc.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)townnews(dot)com]
Sent: Friday, August 31, 2001 9:28 AM
To: Alex Knight
Cc: Gowey, Geoffrey; 'Dr. Evil'; pgsql-general(at)postgresql(dot)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(at)townnews(dot)com AIM : trifthen |
| Web : hamster.lee.net |
| |
| "Most of our lives are about proving something, either to |
| ourselves or to someone else." |
| -- Anonymous |
+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
From | Date | Subject | |
---|---|---|---|
Next Message | Alex Knight | 2001-09-01 01:46:55 | Re: PL/java? |
Previous Message | Thomas Lockhart | 2001-09-01 01:21:49 | Re: PL/java? |