> 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
