This is what I like most about newsgroups. Yesterday, I fired a half-baked, unclear
question about the performace of SP's in servlets. Not only my question became more
solid and specific, but it also started a chain of mails. And the end result is
that my knowledge was enhanced by developers who are well experienced in their
respective fields and who gave invaulable information (which I am sure I won't find
in any book), which comes out of experience only.
I want to specially thank Jon, Joe Sam Shirah, Craig McClanahan. (and everybody
else whose name I might have missed to mention, by chance)
Thanks
Gaurav
Joe Sam Shirah wrote:
>
> > Hi Jon,
> >
> > I would take your experience over many others, but it seems to me
> > that Craig, as usual, is right on on this topic. Does it make sense to
> > you for client code to be 4+ times faster than server code? ( I'm sure
> > you used marketer's exageration for the order of magnitude, which
> > would be 10x, but you didn't include the all purpose get-me-out-of-this
> > asterisk. 8-) ) This is not a common experience. Sounds like there
> > might have been some locks, or else the "perfectly good code" was in
> > some bad sequence or hit tables in the wrong order. Even if this
> > happens to be the case in Oracle, that's Oracle's problem and isn't
> > generally true. Also, don't forget data integrity issues that can be
> > ensured in one place by SPs, where otherwise they have to be
> > enforced on a per program basis**. ( ** = yes I know about triggers,
> > but from the perspective we are talking about, there is no difference
> > between triggers and SPs, other than scope of ops, generally. )
> >
> > I am less of a stored procedure fan than I used to be, but that's due
> > to portability issues. I certainly don't want everyone out there deciding
> > to move from stored procedures to straight JDBC to achieve an order
> > of magnitude* speed increase without LOTS more evidence.
> >
> > Joe Sam Shirah
> > Autumn Software
> >
>
> I appreciate your vote of confidence, but there's a warning here ... do not
> believe *ANY* benchmark that is not based on your own application, or something
> provably close to it. Benchmarks of all sorts, but most especially trivial
> test cases, are going to be misleading. The worst thing to do, IMHO, is to
> make generalized judgements such as "technology A is better than technology B"
> based on simple, out-of-context, examples like this.
>
> Both Jon's experience and mine were real, and therefore valid. That's why
> there is often more than one way to solve a problem. There's also more than
> one problem to solve. Performance is important in many (probably most) apps,
> but time to market, ease of maintenance, and/or portability can also be in many
> circumstances. Any of these may be valid reasons to choose a soluition that,
> on the surface, may appear slower.
>
> It is our responsibility as software designers to choose the solution that best
> balances *ALL* of the requirements. Trust me ... in the almost 30 years since
> I wrote my first BASIC program, this is the most important lesson I've ever
> learned about software design.
>
> Craig McClanahan
>
> >
> > -----Original Message-----
> > From: jon * <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> > Date: Monday, June 14, 1999 8:56 PM
> > Subject: Re: stored procedure in servlet!
> >
> > >> My experience with stored procedures is that they help quite a bit
> > >(performance
> > >> wise) if you do lots of database interactions inside the stored procedure
> > >(such as
> > >> updating a number of related tables).
> > >
> > >Maybe it was just our (clear ink's) PL/SQL guru that was working for us,
> > but
> > >our experience was just the opposite. We had a rather large stored
> > procedure
> > >that worked against a number of tables (this was a highly normalized
> > >database) and we re-wrote the same code as a java method and the java code
> > >was an order of a magnitude faster. (ie: it went from like 60+ seconds to
> > >like 15 seconds to do exactly the same thing). I do trust that our guru's
> > >code was good (I looked at it myself) but you never know. ;-)
> > >
> > >On top of it, we had heard similar things from people within oracle about
> > >the performance of pl/sql not being that great, especially under high
> > >concurrency loads.
> > >
> > >-jon
> >
> > ___________________________________________________________________________
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> > of the message "signoff SERVLET-INTEREST".
> >
> > Archives: http://archives.java.sun.com/archives/servlet-interest.html
> > Resources: http://java.sun.com/products/servlet/external-resources.html
> > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
>
> ___________________________________________________________________________
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
