Re: Java access speed (database or arrays)
Nino wrote:
Is it quicker to constantly query the database for information, or to
query the database once, store the information into an array, and that
array into a session variable to be used through different pieces of
code?
I am using MySQL and JSP. Don't know what other information might be
pertinent as I really don't know how to test this...
Arne Vajh?j wrote:
It is much faster to cache in memory.
The problems are:
* data size - do you have enough memory to use for this purpose
* getting the cached data invalidated if the data is changed in
the database
JSP means Web app which means plan for concurrent access.
Tradeoffs are complicated. You can cluster/farm app servers more easily than
data stores, but data stores can be scaled pretty high and have awesome
built-in caches. One way may be somewhat slower for a given user but allow
better interleaving of concurrent users, so overall throughput improves.
Caching things in application memory may speed up a user but limit the number
of concurrent requests that fit.
Naive expectations of performance often collapse in the face of massive
concurrent access.
Optimizations can occur both horizontally, e.g., throwing more servers at the
web layer, or vertically, e.g., the proposed memory caching scheme or using a
faster JDBC driver, or follow some other pattern, e.g., throwing edge caches
into the mix.
Andre's answer also hints at the difficulties of information latency and
synchronization. How "soon" "after" a transaction should a user see the
result? (In physics, relativity shows that frames of reference in relative
motion can view events as simultaneous or not if the time interval is less
than the "speed of light" latency in any frame of reference. Something similar
pertains to information simultaneity, information latency and cognitive
information processing. Consider Java's "happens-before" thread synchrony as
an example.)
It remains a dark art.
- Lew