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

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

I think that your problem may be that you need to sync the access to the
static elements, in this escenario only one thread can access a given
resource. of course this is a BIG constrains. Adding more processors solve
nothing and may even make the things worse as more thread can be potentally
be waiting for the resource.

why you need to use static resourcers?

"Mark S." <ma***@yahoo.co mwrote in message
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

[Alberto Poblacion]

"Mark S." <ma***@yahoo.co mwrote in message
news:uv******** ******@TK2MSFTN GP03.phx.gbl...

I've written a high performance web app with C# and it completely relies
on static hash tables (using sync) [...] any suggestions on how I might be
able to increase the number of requests per second?

If you are using System.Collecti ons.Hashtable objects and mostly reading
them, you can make use of the characteristic of the Hashtable of being
thread-safe for multiple readers or only one writer. Instead of using sync,
use a ReaderWrtiterLo ck, which will give you better concurrency.

[Christof Nordiek]

Hi Mark,

since you are tolking about static hashtables, I suppose you are using
shared data that is shared by all requests.
Surely, you have to synchronize the access to this data, but you should try
to minimize the time, during wich each request is locked. All codeparts wich
are locked against the same lock-object will be executed, as if they were on
one thread. So fore this part of your code the dual-core/dual-proc will have
absolutly no advantage.

HTH
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

[Mark S.]

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

Alberto,

If you are using System.Collecti ons.Hashtable objects and mostly
reading them, you can make use of the characteristic of the Hashtable of
being thread-safe for multiple readers or only one writer. Instead of
using sync, use a ReaderWrtiterLo ck, which will give you better
concurrency.

Unfortunately each request writes.

Ignacio,

>why you need to use static resourcers?

Every request makes decisions based on what the other request had written to
the static hashTable and then writes what it decided to do back. This
sequential decision makes is required by the code's business logic. If you
or anyone else has a better way to achieve this logic, I'm open to
suggestions.

THX

[Willy Denoyette [MVP]]

"Mark S." <ma***@yahoo.co mwrote in message 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

Just curious how you are stress testing this.
What's the OS the server (IIS) runs on?
What kind (OS and application) and how many clients (PC's) do you have to access the server?
What's the round-trip time for a single get request?

Willy.

[Mark S.]

Just curious how you are stress testing this.

In the beginning I used Web Application Stress Tool but to be honest I don't
remember the exact numbers, but it was in the ballpark.
http://www.microsoft.com/downloads/d...displaylang=en

The application is live, so the numbers I mentioned previously are real
world numbers.

What's the OS the server (IIS) runs on?

Windows 2003 SP 2 IIS 6.0 ASP.NET 2.0

What kind (OS and application) and how many clients (PC's) do you have to
access the server?

Dedicated web servers running nothing else. Application servers only aspx
pages which returns HTML and Javascript, no images are being served. All
data is stored in varioius flavors of hashTables. A timer process collects
the data and sends it to the database, the incoming requests never read or
write to the db directly. This is makes all the difference.

1.4 million unique visitors a day. 4.5 million get requests an hour during
business hours.

What's the round-trip time for a single get request?

As you know being a web app the time will depend on the network, but to give
you a baseline, removing the most the network latency. Here's how long it
takes from the dev server to the live web farm:

6K file gziped (iis) to 2.3K: 0.041 seconds (half the time there's 0.100
second additional delay)
7byte file: 0.009 seconds
3K file gziped (iis) to 1.3K: 0.028 seconds (half the time there's 0.100
second additional delay)

HTH

[Jon Skeet [C# MVP]]

Alberto Poblacion <ea************ *************** ***@poblacion.o rg>
wrote:

"Mark S." <ma***@yahoo.co mwrote in message
news:uv******** ******@TK2MSFTN GP03.phx.gbl...

I've written a high performance web app with C# and it completely relies
on static hash tables (using sync) [...] any suggestions on how I might be
able to increase the number of requests per second?

If you are using System.Collecti ons.Hashtable objects and mostly reading
them, you can make use of the characteristic of the Hashtable of being
thread-safe for multiple readers or only one writer. Instead of using sync,
use a ReaderWrtiterLo ck, which will give you better concurrency.

ReaderWriterLoc ks have fairly hefty overheads - unless the work you do
within the lock is significant, the overhead could well be more than
the gain due to more concurrency.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Bruce Wood]

On Mar 28, 8:17 am, "Mark S." <[e-mail] wrote:

Every request makes decisions based on what the other request had written to
the static hashTable and then writes what it decided to do back. This
sequential decision makes is required by the code's business logic. If you
or anyone else has a better way to achieve this logic, I'm open to
suggestions.

OK... I'll take a crack at it.

First, though:

1. What are the keys in the hash table? What do they represent?
2. How many keys can there be?
3. How are they structured?
4. How (and when) can new keys be created?

Once I know the answers to these questions, perhaps I can suggest a
better structure.

A preview... what I'm thinking now.

The problem with a hashtable is that the correspondence between a key
and the corresponding hash bucket and its chain of keys is arbitrary.
This means that two threads writing to the same hashtable practically
have to lock the whole structure and therefore run serially.

If, however, you could create a different structure that understands
the structure of your keys, you might be able to selectively lock only
parts of the structure. Viz: one thread writing to the structure under
key A might be able to run in parallel with another thread writing
under key B if the two keys have nothing in common within the data
structure. If you were, for example, to roll your own hash table, you
could attach a different lock object to each hash bucket, and lock the
buckets individually rather than taking out a lock on the entire
table.

Of course, whether this gives you improvements in concurrency entirely
depends upon the nature of your problem. If it is highly likely that
all threads will be working on the same key at the same time then it
doesn't buy you much. If, on the other hand, multiple threads are
likely working on different keys at the same time, and the keys can be
structured so that they are unlikely to land in the same part of the
collection structure, then it's highly likely that threads will run
without any locking contention whatsoever.

As usual, the answer is, "It depends." It depends upon the answers to
those questions, above.

[Willy Denoyette [MVP]]

"Mark S." <ma***@yahoo.co mwrote in message news:Oi******** ******@TK2MSFTN GP06.phx.gbl...

>Just curious how you are stress testing this.

In the beginning I used Web Application Stress Tool but to be honest I don't remember the
exact numbers, but it was in the ballpark.

I see, that means that (IMO) the shared hashtable lockings aren't the real bottleneck, isn't
it?, if they were, you would have topped at approx. the same figures you are seeing now.
I would suggest you to profile your application on a staging server, in order to pin-point
the bottleneck. Another option is to take regular snap-shot dumps of the running application
using adplus.vbs and investigate the dump off-line using Windbg.exe and sos.dll.

Willy.