We have just insturmented the ASP.NET state server service at one of our customers. Are there any interesting information besides the process (threads memory and CPU) to be gathered from that?
I have tried searching both documentation and forum but come up empty. So any information would be welcome.
According to MSDN, StateServer mode.
It is a .NET process running on the same server that runs IIS and ASP.NET
ASP.NET session state supports several different storage options for session data. Each option is identified by a value in the SessionStateMode enumeration. The following list describes the available session state modes:
InProc mode, which stores session state in memory on the Web server. This is the default.
StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
Custom mode, which enables you to specify a custom storage provider.
Off mode, which disables session state.
Thanks for the information! You should configure a .NET agent for the State Server process and see what you get.
It's probably using a standard protocol to communicate from IIS to the State Server, so you may see PurePath data out of the box, but if not, I'd change the sensor configuration so that both .NET WCF and ADO .NET sensors were set to "active and start PurePaths" in the State Server agent group.
This is JUST AN FYI: I havent done any active ASP.NET development in a while - but - I remember hearing that the External State Server Process was not the favorable option due to scalability issues. I remember SQL Server being the preferred option in the ASP.NET Community
To add to Graeme's point: I hope you see some remoting call. If not I assume they use some propriatory protocol. The State Server has been around for a long time - longer than WCF is around. So its possible that the communication is still what it used to be back in the days when they started with that concept
Just to jump on this train as well. There is one class you'd probably want to add sensors for. That would be System.Web.Caching.Cache. This is the underlying .NET object that is doing all of the work inside of the aspnet_state.exe.