Tuesday, June 24, 2008
Troubleshooting SPSite/SPWeb leaks and the Importance of Loadtesting
Stefan has a good article on troubleshooting leaks in your WSS and MOSS applications. One of the very nice features is that whenever a certain threshold is crossed, an entry will be written in the ULS logs:
"Potentially excessive number of SPRequest objects (<NUMBER>) currently unreleased on thread <NUMBER>"
This is a very convenient way for a Sharepoint Administrator to keep track of sites with an excessive amount of memory consumption through SPRequest objects.
He also talks about issues surrounding the potential number of site objects generated with a site navigation control:
"That means if you have a navigation control configured to enumerate 3 levels of sites and on each level you have 20 sites that you will end up with more than 400 SPRequest objects. So you need to be very careful with how to configure your navigation controls and also how many sites to create on each level!"
Now consider that each site object will use approximately 2-4 MB of memory on the server. Combine this with the scenario above and you will end up with a huge amount of allocated IIS memory. I don't know if this is per individual user session or not, but either way, this is not something you will want to have on your environment without some consideration beforehand.
There are roughly two ways to gauge what your application will do:
Based on the site architecture, software architecture, usage forecasts, amount of change permitted on the webpart architecture and so on, you can get an estimate on how your solution will behave. How many objects will there be any given time? What is the variance?
But -sadly- hardly anyone does this, let alone completely.
So, what's the second option?
This should come as no surprise. (If it does, shame on you!) Yes you can do unit testing. Yes you can do TDD. Yes you can test against coding guidelines. And yes you all will do functional testing. That's all good.
But only, and only if you test your whole A-Z architecture against real life usage and benchmark it, stress it, stress it hard, you will be able to get information how everything will hold up. How is that pesky CrossList webpart doing? And what about that navigation control? If it looks like it is generating a whole lot of memory pressure, you might want to consider other options and go back to the drawing board.
Loadtesting also includes talking to the client to get the testing requirements. What will be their expected usage patterns? Okay, you want the application to react fast? What do you mean by fast? Can you put that in numbers? Let's talk about your Application SLA. What can you tell me about it? How can we translate this into something meaningful for the project?
I can not stress this enough: if you do not incorporate loadtesting as a core requirement in the process, you will be introducing One. Huge. Unmanaged. Risk. Factor. Period.
I have seen too many deployments go down in flames because of this. You might have created a stunning application which leaves the customer absolutely breathless with tears in their eyes, but if he finds out that it will only scale to 6 concurrent users with no more that 5 pages per second before another Web Frontend (WFE) is needed, which, by the way, is definitely NOT the solution to your problem, you will have a serious problem. And this will not be easy to solve if you have come this far in the project.
This is what Microsoft has to say about it: "Load testing should be part and parcel of every Web development effort, and it should be performed early in the process. However, if you think you can load test using your development environment, you're going to have some surprises when you go live..."
So, to sum it all up: "if you do not loadtest, you fail".
Stefan Goßner : Troubleshooting SPSite/SPWeb leaks in WSS v3 and MOSS 2007
MSDN: Real-World Load Testing Tips to Avoid Bottlenecks When Your Web App Goes Live
Modeling the Real World for Load Testing Web Sites
Links to this post:
Subscribe to Posts [Atom]