Sharepoint, IIS, .net, and multithreading

Question

I am aware that IIS is configure for multithreading as standard. I am having performance issues with my web servers hosting Sharepoint 2007.

So my question is;

Does Sharepoint 2007 use multithreading as standard out of the box solution, or is it only customisations using .net?

And does anyone know how I could limit users creating multiple thread/connections at a server admin level (iis) or would this have an adverse impact on applications or site in Sharepoint?

Thanks

Answer 1

SharePoint performance problems is a complex topic. You need to troubleshoot to locate where you have performance problems. Is it the web farm? The database back-end? Do you have a web part that causes problems? Performance monitor is a good place to start.

And to answer your question about if SharePoint uses multithreading? Yes, it does in the sense that it is build on top of IIS and ASP.NET. It is not crippled in any way.

Answer 2

I really don't think threading is causing perf problems you experience.

Answer 3

To answer the "easy" question in your post, SharePoint sites are served up via ASP.NET. That said, you have extensive control over ASP.NET's threading model/management via the processModel element that is located within the machine.config on each of your SharePoint web front ends (WFEs). You can set minimum and maximum thread counts for both the worker process and I/O operations, and there are also a number of additional setting/tuning options available. For more information, see Microsoft's site at http://msdn.microsoft.com/en-us/library/7w2sway1.aspx.

With that said, I can't agree with Martin more: performance troubleshooting in SharePoint is seldom a "find the magic bullet" scenario. If you've addressed the bigger "generally known" WFE IIS/ASP.NET items (summarized pretty well in Joel Oleson's blog: http://blogs.msdn.com/joelo/archive/2007/10/29/sharepoint-app-pool-settings.aspx), then you should generally be in decent shape under common usage scenarios. After that, the deeper digging begins.

I spent the better part of six months with a Microsoft cross-functional escalation team troubleshooting performance issues for a client, and we ended up touching nearly everything: IIS/ASP.NET performance, efficiency of custom code, caching, memory utilization, database performance, web services performance, object disposal ... the list goes on and on. Each step of the way, we were capturing memory dumps, taking quantitative performance measurements, watching performance counters, etc. We found multiple areas that we ended up tuning, but those areas were only found through systematic analysis and quantitative measurement.

To be completely honest, I don't recommend making changes to any of the configuration settings (such as the processModel settings) without having a working hypothesis and a performance tuning plan that includes good measurement and comparison. Performance tuning generally isn't the sort of thing you can "eyeball."

On the flipside, though, changing a setting or two here and there may allow you to poke at the problem a bit if you have strong suspicions -- provided you return to your baseline afterwards and do so in a way that doesn't impact your users/customers ... though again, without a way to quantitatively measure pre- and post- change performance, you may not pick up any noticeable difference.

Good luck!