What Impact Do Static HashTables and Classes have on the CPU?

[Mark S.]

Hello,

I've written a high performance web app with C# and it completely relies on
static hash tables (using sync) and classes. Under real world stress this
app is handling 5 get requests per CPU per second.

I've gone from a single-core/single-proc, to a dual-core/single-proc to a
dual-core/dual-proc and as I suspected the number of requests per second per
CPU does not increase it remains at 5 per CPU.

My reading of IIS threading suggests that 10-12 per requests per second can
be expected from a non-static class based app. If this assumption is
correct, do you have any suggestions on how I might be able to increase the
number of requests per second?

TIA

[Chris Mullins [MVP]]

"Mark S." <ma***@yahoo.co mwrote in message

I've written a high performance web app with C# and it completely relies
on static hash tables (using sync) and classes. Under real world stress
this app is handling 5 get requests per CPU per second.

If you're only getting 5 requests per second, then I suspect you're doing
alot more than reading & writing values to a hashtable.

If that is in fact all you're doing, and you're only getting 5 requests per
second, you need to re-evaluate your algorithm from the ground up, as you
should be getting a number that requires scientific notation to properly
describe.

--
Chris Mullins, MCSD.NET, MCPD:Enterprise , Microsoft C# MVP
http://www.coversant.com/blogs/cmullins

[Mark S.]

Chris,

You're right, but failed to accurately describe my numbers, below I've
reposted the carination. It clarification runs really fast 400 get requests
a second takes 35% CPU.

Allow me to clarification my numbers just a bit.

Using the performance monitor:
(Number of get request per second to asp.net app 2.0) / (CPU %) = N request
per second per 1% CPU.

Single single-core: 8 per
Single dual-core: 6 per
Dual dual-core: 5 per

[Mark S.]

Bruce,

I think you're on to something good here. Let's see what we can come up
with.

1. What are the keys in the hash table? What do they represent?
3. How are they structured?

The keys are GUID and they represent a collection data. A background process
grabs xml from the database and massages it into a struct of arrays.

So the keys are GUID and the values are a struct.

public static Hashtable myHash = Hashtable.Synch ronized(new Hashtable());

public struct myStruct
{
public string html;
}

public static String myLogic(String targetID) {
if (myHash.Contain s(targetID))
{
lock (myHash.SyncRoo t)
{
struct myStruct = (struct)myHash[targetID];
// read data, make decisions based on data, update struct with
results
// struct of arrays greatly simplifed for sake of this
conversation
return myStruct.html;
}
}
}

2. How many keys can there be?

Currently 208, but that will grow to 500 in a couple months and in six
months up to 1000.

4. How (and when) can new keys be created?

Whenever data entry admins change data in the database the hashTable is
updated. This happens a couple hundred times a day. A background process
reads the live hash table, corrilates it's data with the incoming data,
contructs a new seperate hashTable, and once complete, locks the live
hashTable and does a quick swap.

[Christof Nordiek]

Hi Mark,

would it be a problem, if between the reads and the writes of one request
there are writes of other request?
If so, you should not lock on the Hashtable, while processing the data, but
only the writes and the reads.
Otherwise, you should try to limit the data locked, f.e. only lock the key
while processing. Not easy to do, if the key is of a value type. So, an
alternative would be, to use a class as data and lock on that instance.

If serializing only the reading and writing of the data gives you this
problem, then I suppose, you have to redesign your datastructure.

Christof

"Mark S." <ma***@yahoo.co mschrieb im Newsbeitrag
news:uv******** ******@TK2MSFTN GP03.phx.gbl...

Hello,

I've written a high performance web app with C# and it completely relies
on static hash tables (using sync) and classes. Under real world stress
this app is handling 5 get requests per CPU per second.

I've gone from a single-core/single-proc, to a dual-core/single-proc to a
dual-core/dual-proc and as I suspected the number of requests per second
per CPU does not increase it remains at 5 per CPU.

My reading of IIS threading suggests that 10-12 per requests per second
can be expected from a non-static class based app. If this assumption is
correct, do you have any suggestions on how I might be able to increase
the number of requests per second?

TIA

[Bruce Wood]

On Mar 28, 11:48 pm, "Christof Nordiek" <[e-mail] wrote:

Hi Mark,

would it be a problem, if between the reads and the writes of one request
there are writes of other request?
If so, you should not lock on the Hashtable, while processing the data, but
only the writes and the reads.
Otherwise, you should try to limit the data locked, f.e. only lock the key
while processing. Not easy to do, if the key is of a value type. So, an
alternative would be, to use a class as data and lock on that instance.

OK... that beats my idea hands down.

Christof is right: you have two locking scenarios here:

1. Adding a new key to the hash table: need to lock the whole table.

2. Manipulating the data structure that is under one key: make it a
class and lock the instance in the hash table.

The very fact that you want to manipulate the data that's already in
the hash table, rather than just writing it once and possibly deleting
it later, says that you want these to be classes, not structs. Plus,
by making them classes, you get the added benefit that you can lock on
them.

So now you can have one thread updating one instance and another
thread updating another instance and they won't collide.

The only time you need to lock the whole thing is when you add a new
key and when you're fetching instances to update. If even this
contention is too much for you, then you can move to the solution I
proposed: roll your own hash table structure, and allow for locking on
individual hash buckets. If you do this, then the pseudo-code would
be: calculate hash value for GUID, calculate bucket index from hash
value, lock bucket, fetch data instance, lock data instance, unlock
bucket, update data instance, unlock data instance. This improves
concurrency because a thread that is manipulating / searching the hash
chain at bucket #15 isn't in contention for a lock with another thread
that is manipulating / searching the hash chain at bucket #3, and even
if threads are updating class instances in the same chain, they need
to lock the bucket only long enough to find the item they want to
update.

If you allow for deletions from the hash table, then the thread doing
the deletion has to lock both the table (or the bucket) _and_ the item
to be deleted, to ensure that nobody else is updating the item while
it's being deleted.