Tim Kientzle <kientzle@acm.org> writes:
> > I'm finding that ... my CPU spends about 60% of the time in JDBC, and about
> > 40% of the time in the postmaster backend.
> > (Each query takes 2 msec on my machine, RH Linux 6.2, 733 MHz Intel, w/
> > lots of memory.)
>
> This doesn't sound too bad to me, to be honest. I've not tried using
> JDBC with PostgreSQL, but I've done a lot with MySQL (and some with
> Oracle, although not as recently). I'm used to seeing 5-10ms for
> a fairly basic indexed query on a PII/266.
>
I think we can improve the performance of the JDBC driver alot still. I've
been doing some benchmarking and profiling over the last days to find the
hotspots in the driver. I hacked up a faster version of the driver tonight
that does pooling on a per connection basis of all of the "new byte[]"
calls that occurs when the driver is reading the stream from the
backend. The tradeoff is ofcourse speed for memory. It may also break
applications that try to access a ResultSet after it has been closed or a
new query has been issued - but those applications rely on behaviour that
is not part of the JDBC spec. so I think it is OK break them...
This improved the average throughput of my web application from
roughly 6 requests/second to 9 requests/second. The relative speedup of the
driver is ofcourse a larger, since JDBC is not the only bottleneck of my
application. A web request performs on average about 4 database queries.
The remaining largest bottleneck in my JDBC codebase now is related to
byte/char conversions in the Sun JDK implementation. My profiler tells me
that Sun JDK 1.2.2 for some reasons create new instances of the converter
class every time you do an conversion... Maybe I will look into doing
custom converter instead.
Hopefully I will be able to cleanup my hack in 1-2 days and post it to the
list so others may review and test the modifications.
regards,
Gunnar