Craig,
Wow, good response. Let me lay out the design criteria.
1.) The initial loading of the data to decode against is cycle
expensive. The solution needs to be, at minimum per process cached, or at
best, per machine cached.
2.) The ability to control the loading/refresh of the data external to
the calling process is a consideration. But due to time constraints this
consideration might have to take a back burner.
3.) The solution must be able to handle ~100 lookups a second per
machine. This pretty much rules out remoting due to performance penalties
imposed by marshalling/protocol traversal.
Now let's see if I can answer the rest of your questions in-line.
Thank you for all of your valuable insights.
John P. Sheppard
-----Original Message-----
From: Craig Andera [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 15, 2002 4:47 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Design Questions
> That what I was thinking as well (except I would set the minimum
to 1,
> not the maximum, right?). With a COM+ object pooling solution,
you
> aren't tying yourself to ASP.NET. Sure - each pooled object is
going to
> have its own copy of the data, but memory is cheap, and you can
control
> how the cache is refreshed. I think this option is worth
investigation.
>
+1 on the min=1 rather than max=1. You'd want to maintain the state
in a
static or something, and make sure everyone could get their own
instance
with a reference to the state, rather than having only one instance
in
the pool.
The one thing to watch out for here is that you're going to be going
through a proxy to get to the COM+ object unless you're way careful
-
which will have potentially significant performance impacts. See
"raw
configured objects" in "Transactional COM+" by Ewald.
The problem I see with your design right now is that you've said you
don't want to go to the database every time because you don't think
it
will perform well. I agree, but you also seem to imply that you
think
you can do as well with a remoting solution, which is not entirely
clear
to me. Are these out-of-process trips somehow less expensive than
database roundtrips?
I did not mean to insinuate that I was pursuing this avenue. I meant that a
remoting solution was not viable due to the cycle penalties incurred by
marshalling/protocal traversal. The only thing I can think of that you
might have misconstrued is my question about registering a server object in
the ROT table from a service and connecting to that.
It seems like you have a fundamental "bits versus cycles" tradeoff
to
make here: do you want to pay the price of going out-of-proc wrt
your
client to save the extra memory? I haven't heard enough from you to
decide which way you should go. Here's one question to think about:
Does the increased performance of a per-process cache outweigh the
increased memory pressure?
Yes it does. I need to be able to do the lookup conversions in as short a
period of time as possible. Due to the multiplicity of the lookup, the more
time I can shave off on one lookup, the better my app will perform. A per
process or per machine/process two stage cache might be best. Right now it
will probably be a per process cache. I am using a singleton pattern within
my app so that the first time a call is made to the decode component for
that process it gets loaded, after that it pulls from the cache. I did some
intial timing with this using the SPM as the back end store for the cache.
A chunk of five calls, after initial loading was taking between
5.0707561994611046934736119 and 0.1321396993193268976923045 milliseconds per
call chunk with the average over a 1000 iterations being
0.168260129512188083878061238 milliseconds. This seems like it is within
tolerance, but I want to try caching just the raw datasets and not go
through the SPM and see if this decreases that time, because I realize that
there is some marshalling taking place. That means the lookups should take
approx. 67.3040518048752335512244952 milliseconds (2000 decodes) on average.
That less than a tenth of a second. Not bad. I want to tinker to see if I
can lower this even farther.
How about this? Will a hybrid approach (say having a service that
caches
the data on a per-machine basis, but hands out the data [or chunks
of
the data] to in-process secondary caches) work? I like this approach
because you could use remoting both to populate the in-proc caches
and
to signal the master cache to invalidate all of the secondary
caches.
Subcaching just chunks of data would be especially effective if your
data access exhibits a lot of spatial or temporal locality
(accessing
the data linearly, e.g.)
Each call only looks up a small, unpredictably placed piece of information.
I couldn't describe it as a linear data access. The record could reside
anywhere in the cache. I have them grouped into tables, but that inside of
each table they could be anywhere (i.e. non sorted). I could even increase
the speed of this lookup by placing them in arrays and sorting and doing a
binary search.
Of course, if you can get away with it, and if cache population
latency
isn't an issue, I'd just buy a crapload of memory and cache it all
in
every process. :)
This is what will probably happen for release one. I am looking at a shared
memory solution for v2 already. :) (I must always tinker.)
You can read messages from the Advanced DOTNET archive, unsubscribe from
Advanced DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com..
You can read messages from the Advanced DOTNET archive, unsubscribe from Advanced
DOTNET, or
subscribe to other DevelopMentor lists at http://discuss.develop.com.
