Prev: Confirm messagebox
Next: Javascript to retrieve Gridview cell text
From: bruce barker on 18 Dec 2009 22:32
one issue with using state server rather than sqlserver state, is memory
usage. if there is too much, the stateserver can only throw errors. if
it gets a fatal error, it a recycle and all session data is lost.

you should be using 64bit also.

you should check the size of you session data, there is now real method,
but you can serialize to a binary buffer, and check the buffer size to
get an idea. if the data is too large you may be getting network errors,
which i suspect is the real problem. have your network people do traces
at the busy time and look for network timeouts and lost connection.

-- bruce (sqlwork.com)


dm1608 wrote:
>
> When you say concurrent connections -- what is the best way to measure
> this?
>
> My state server never appears to be overloaded and CPU is frequently
> below 40% -- most of the activity is SQL Server running on the same
> box. The ASP.NET State Server service doesn't appear to be using much
> CPU but is using approx 1.5GB of memory during peak usage.
>
> I've already scaled out by adding more servers and that doesn't appear
> to provide any relief in the errors that I'm seeing.
>
> I have no idea how large the sessions are for the various applications
> and I have no access or direct access to the developers of the
> application. I'm just an end-user pointing out all their flaws.
>
> There applications work great for small shops but we're using it in a
> datacenter environment where there is a lot more utilization than what a
> typical end-user would experience. I'm not the only datacenter using
> the product however. There is nothing special about my environment
> either -- just Windows 2003, NLB, and ASP.NET 2.0 running under ESX 3.5
> over a SAN back-end.
>
>
>
> "Tom Dacon" <tdacon(a)community.nospam> wrote in message
> news:uYQm4iBgKHA.2160(a)TK2MSFTNGP02.phx.gbl...
>>
>> "dm1608" <dm3281(a)nospam.com> wrote in message
>> news:8A154D84-9651-44C1-AD85-454B74FF8CEE(a)microsoft.com...
>>>
>>> If any one has any other ideas I could try or better ways to
>>> troubleshoot, I'd appreciate it.
>>>
>>
>> You don't say how many concurrent sessions you're seeing when this
>> happens or how much state information is being held in session state
>> for each of the sessions, so it's hard to say whether you're just
>> maxing out the capacity of the staging server. A little
>> back-of-the-envelope work on that might help you to see if that's the
>> issue. If it so, then of course you're going to have to scale for the
>> peak periods, either scale up or scale out. No surprises there.
>>
>> At my company, we've begun using a third-party solution for session
>> store, called NCache from Alachisoft (www.alachisoft.com). It's
>> primarily designed for web site caching, but also works well as a
>> session store server across load-balanced application servers. It's
>> easy to scale up in a variety of ways, and might be worth considering.
>> You can download and try out a full-function evaluation at no cost. I
>> have no relationship with the company other than as a user of their
>> software. We're satisfied with how it's working for us but I doubt if
>> we're stressing it particularly heavily.
>>
>> Tom Dacon
>> Dacon Software Consulting
>>
>>
>>
>>
>>
 | 
Pages: 1
Prev: Confirm messagebox
Next: Javascript to retrieve Gridview cell text