Jeff Kilbride wrote:
>
> No, I didn't synchronize either. That would defeat the purpose of my
> connection pool and *really* slow down performance.
>
Right, that's why I expected crappy performance from the servlet as a
whole, since I synchronized the method. What has me bothered is the 39
requests per second on iPlanet, 16 requests per second talking straight
to Tomcat 3.3 and 4 requests per second talking to Apache 1.3.19 w/
mod_jk.so in ajp13 mode talking to Tomcat 3.3.
I could understand like a 30%->50% performance drop from
iPlanet->Apache, but from 39 RPS to 4 RPS seems a bit absurd.
> If you're synchronizing access to the method that does your insert/update,
> then that's your bottleneck. Do you really have to synchronize it? Can you
> rewrite the SQL to avoid the overhead of synchronizing in Java? Are you
> synchronizing the entire method or just the block of code that does the
> insert/update?
>
Well, let's just cut the whole insert out of the formula and state
that it's an update. It has to be synchronized since a request from a
luser comes in, we take that data get data out of the database, add them
together and update it back into the database. It's not a scientific
kind of thing nor are lives depending on it, but if it's not synchonized
and I push 1000 requests against it about 100 of them actually get
counted, while syncronized they all get counted. And actually in testing
against iPlanet itself the syncronized was just a smidge faster than
non-syncronized. We think it has something to do with Oracle's row
locking on updates.
--
Steve Brunton <[EMAIL PROTECTED]> Phone: 404-827-2756
Chief Engineer Enterprise Systems One CNN Center, Atlanta GA
CNN Internet Technologies ICBM: 84W 23' 45" 33N 45' 29"
<*> Black holes are where God divided by zero. <*>
