On 12/17/2010 8:00 AM, Gregg Wonderly wrote:
...
One of the primary issues with bandwidth through any system is latency.
While multiprocessor/multi-core and distributed computing can provide
huge bandwidth possibilities, the underlying issue is per transaction
latency.
If you look simply, at the JDBC model for example, the act of converting
the JDBC activities to network traffic and back (marshal/unmarshal) is
one of the primary "time consuming operations". When you add onto that
other overhead associated with how each database authenticates and
manages its "network" traffic. I have no exact numbers to demonstrate
this, but it is something which I have very long experience dealing
with, over the years, with my broker (built before JMS existed) and
catching up 100's of thousands of transactions into databases which have
gone down for maintenance.
JDBC only allows one transaction per connection, so you have context
overhead involved there. With each transaction coming across a separate
TNS-Listener process in oracle, you have OS context switching issues
that inject latency.
Overall, the bandwidth can be very large, but the per transaction
latency is probably the biggest reason that SQL databases are not always
the best choice for some types of performance needs.
Thanks. It's very useful to know specific gotchas with a given
implementation strategy.
Patricia
