Jonathon,
Now that you've explained how you got to the conclusion of caching in
the database is faster than caching in the app server, you comments
make more sense and it is only now possible to answer your question
with any appropriate detail.
The main argument is that programs written in C are faster than
programs written in Java. I'm not an expert in this, but years ago
when this was a big debate and a lot of work in this area was being
done on Java (back when JRockit actually had a market because the Sun
JVMs were pretty slow) I did quite a bit of reading and following the
news. The idea that C is faster than Java may have been true 5-6 years
ago, but it is not true any more. Java has WAY more efficient memory
management with asynchronous and multi-threaded de-allocation combined
with efficient real-time allocation. Most tight loop code in Java is
just as fast as in C because of Just-In-Time (JIT) compilation
features. Just search around the internet... LOTS of work has been
done on this and there are many side-by-side tests.
However, C versus Java is somewhat irrelevant because getting data
locally from memory no matter the language (even a scripting language)
is 1-3 orders of magnitude (10-1000 times) faster than communication
over a network. Even round-trips to a local hard disk is usually
faster (especially for random access to small amounts of data where no
streaming or larger blocks are possible).
So, yeah, all down to basic hardware stuff for the biggest performance
impact.
There are some entity engine performance tests in the WebTools webapp
that compare caching to database performance. If you want to test
database caching versus entity engine caching just setup your database
to turn on caching for a certain table and then from the WebTools main
page click on the "Entity Engine" link under the "Performance Tests"
heading.
BTW, the session management in OFBiz is handled by Tomcat, and it is
in memory on the app server (or depending on configuration it may save
sessions locally to the hard disk for larger session data loads).
-David
On Apr 19, 2008, at 4:25 AM, Jonathon -- Improov wrote:
> The only point of caching in any case is performance. There are bad
> side-effects of caching, so performance must be more important than
> other things (like possibility of stale cache, etc).
I didn't suggest that OFBiz's caching makes things worse. Stale
caches must be handled correctly, or it becomes a bug, no compromise
there. In case you did mean "handled stale caches", then stale
caches will invariably mean less cache performance. Ranking
performance much higher in importance than stale caches isn't gonna
make cache performance any better in the face of stale caches.
But I get what you mean. Performance could be more important than
high RAM prices, if they are high.
> What I'm baffled by, and the only reason I responded, was the idea
> that caching in the database is _faster_ than local caching on the
> app server. Any time you do a database round trip you're talking
> about serialization of data, network communication, and
> deserialization... and all of that in both directions. Even a simple
> lookup where the database has it cached will take a few
> milliseconds.
First, DBCP removes a huge load of that "round trip". DBCP is
implemented correctly in OFBiz, yes?
Second, caching written in C is definitely faster than that written
in Java (OFBiz). That's the usual argument thrown to the ML, yes? I
was addressing that common misconception (calling it what it is).
> This really has nothing to do with OFBiz, it's all in the network
> and hardware that this performance impact comes in. These are
> usually huge factors in designing distributed systems.
Ritz123 didn't ask about a distributed system. Or maybe I should be
expeled from geekdom for not assuming all possibilities.
OFBiz's session management is in the database anyway, so it makes
sense to bundle the database together with OFBiz in the same
machine. Must be a really huge business that requires specialization
of hardware. Unless, of course, we are looking to under-utilize now
in the name of "future projected growth".
> So, I guess the point of my questions is how could remote caching
> ever be faster than local caching? In other words, I was asking
> because I must be misunderstanding something as this doesn't seem to
> make any sense.
That misconception really has nothing to do with network overheads.
Given Java's garbage collection, and given C's sleeker memory
management, accessing a local Java-based cache may not be faster (if
at all) than hitting a local port for data via a C program. No, I
haven't tested this recently. Hopefully my original answer was clear
enough to suggest that I wouldn't try to test it, since tweaking a
RDBMS's cache is not nearly as useful working OFBiz's cache.
> Not sure what you mean by "Oh my goodness. Not again." It's really
> not that sensational, just basic computer stuff, really quite boring
> and plain actually.
Then I'm really baffled why you wouldn't spell out that boring,
basic and plain answer for us all, rather than asking "have you
tested it 110%? are you doubly sure? is that your final answer? have
you called your lifeline? do you need more hints?".
Try to look for the good parts in other people's answers. I'm trying
to offer as much help as I can on OFBiz, without misleading anyone
into thinking OFBiz is all rose and no thorns. If you spot holes,
you could help out by filling in for me?
Jonathon
David E Jones wrote:
The only point of caching in any case is performance. There are bad
side-effects of caching, so performance must be more important than
other things (like possibility of stale cache, etc).
What I'm baffled by, and the only reason I responded, was the idea
that caching in the database is _faster_ than local caching on the
app server. Any time you do a database round trip you're talking
about serialization of data, network communication, and
deserialization... and all of that in both directions. Even a
simple lookup where the database has it cached will take a few
milliseconds.
This really has nothing to do with OFBiz, it's all in the network
and hardware that this performance impact comes in. These are
usually huge factors in designing distributed systems.
So, I guess the point of my questions is how could remote caching
ever be faster than local caching? In other words, I was asking
because I must be misunderstanding something as this doesn't seem
to make any sense.
Not sure what you mean by "Oh my goodness. Not again." It's really
not that sensational, just basic computer stuff, really quite
boring and plain actually.
-David
On Apr 19, 2008, at 2:37 AM, Jonathon -- Improov wrote:
Oh my goodness. Not again. I thought someone else posted his tests
of retrieval speeds regarding this?
Call it what it is, and we'll always be alert to necessities for
change. Side note: No point telling everybody "it's all there, you
just can't find it", when they might have the ability to actually
confirm without doubt that parts of functionalities are not there.
I don't have time to write every reason there is for OFBiz's
caching, please. Of course it's good to be able to specifically
spell out to OFBiz which entities you want cached; RDBMS do not
always know (if at all) which entities should be cached more. The
designer of the software will know the usage pattern the software
is designed for. So how many points do I get for that answer? :)
Sigh.
So would you mind listing all the reasons for OFBiz's caching of
the database entries? :) You designed it, I believe. You would
know. Thanks!
Jonathon
David E Jones wrote:
On Apr 19, 2008, at 2:04 AM, Jonathon -- Improov wrote:
Chris is right that dynamic view entities are exactly like view
entities. Both run through the same Entity Engine. Caching by
OFBiz is also good, though much slower than RDBMS-native caches;
Really? What would be the point of local caching on the app
server then? (hint: it definitely isn't for database independence)
Have you actually done tests on this to see what typical times
look like, even for a database running on the same machine?
-David
