Re: ASP requests and locking
- From: "Patrice" <http://www.chez.com/scribe/>
- Date: Mon, 25 Aug 2008 16:21:33 +0200
I addition to Anhony's reponse try :
http://msdn.microsoft.com/en-us/library/ms998549.aspx (Improving ASP.NET
performances).
You could pick here and there some usefull advices (in particular check
maxWorkThreads if you want a higher peak value as I wonder if this by chance
or not that you are at 2*maxWorkerThreads (the defautl value is 20), how
much CPU do you have ?)
--
Patrice
"polastine" <noone@xxxxxxxxxxx> a écrit dans le message de groupe de
discussion : ORQmwkpBJHA.2056@xxxxxxxxxxxxxxxxxxxxxxx
Hi all -
I'm relatively new to ASP.NET, coming over from the PHP dark side =) So
far I'm enjoying working with all this very much, especially the
templating system, which is light years beyond anything available with PHP
or Perl.
Skip the next few paragraphs if you're not interested in the back story =)
I'm currently writing a web app that is designed to handle a very heavy
traffic load - about 3 million requests per day, possibly more. That's
about 85 requests per second, give or take.
The app is designed to scale out (cluster) on Server 2008. My
characterization tests seem to indicate that I can handle about 40 reqs
per second on the servers we use, so I'm going to need two or three boxes
for this (obviously not 40 reqs per second every hour of every day, that's
just the potential peak load profile).
The requests are stateless, sessions are not turned on and what little
information I need about the user is stored in a cookie, so there are no
server affinity problems. The database is relatively simple, heavily
denormalized and performance is excellent. We also have a fairly
comprehensive caching system for repeated coherent reads that works a bit
like memcached. All this is working fine right now.
The new wrinkle is as follows. There's a need to have a set of
configuration values maintained in each of the webheads. Basically this is
just a large associative array, in the form Dictionary<string, string> or
whatever. The data this thing contains comes from the database. I have the
caching and everything else figured out across the cluster, so that's not
the problem.
But I'm finding the ASP.NET request model and how it uses threads a bit
confusing so I'm wondering if someone can go through the questions below
and answer them:
- ASP.NET uses one thread per HTTP request, correct?
- When using the lock(x) C# idiom, that lock is app domain-wide. So if I'm
locking to get at the value of a hashtable in the ASP cache, I'm locking
all other requests for this particular app pool until the lock block
exits. Correct?
- To follow the above, I assume I do have to lock anything that might be
accessed at the same time from two or more concurrent requests?
- When accessing properties of a class that contains only static property
accessors, do I need to lock? Assume the class is not accessing anything
that is shared internally, just other static variables.
- Assume the class is accessing a hashtable instance declared as a private
static variable, but still from a static method. Is the lock necessary?
i.e.:
public static class Foo {
private static Hashtable _ht;
...
...
public static int SomeProperty {
get {
// Would not locking here cause a contention problem?
return (int) _ht["SomeProperty"];
}
}
}
It's probably clear by now that I'm trying to figure out how to best store
and access these key/value pairs, from a performance perspective. It's
also probably clear that I can't afford a lock at all. I also looked at
HttpRequest.Items, however that does not help me because I'd have to
create (or clone) an instance of the config class for every request, or
keep a pool or something complicated like that.
A final question about locking and the ASP cache. If I have a cache item
which is a large string (maybe some prebuilt markup for a page that rarely
changes), and I access that string from an HTTP request to push it out
into the response stream, is the process of pulling that string from the
cache a locking situation as well? I.e., does the ASP cache have to lock a
primitive type in order to return it? And will this lock affect
concurrency at all in heavy load situations?
I realize it's a lot of questions, but even just answering one will help
me a lot and maybe set me off on the right path. I'm not having a lot of
luck with Google on this. Or if someone has solved this problem before and
is willing to share, that would be even better =)
Thanks a lot in advance!
.
- References:
- ASP requests and locking
- From: polastine
- ASP requests and locking
- Prev by Date: Re: x.509 Certificates
- Next by Date: Re: Need help with GUI
- Previous by thread: ASP requests and locking
- Next by thread: Re: ASP requests and locking
- Index(es):
Relevant Pages
|
