16 February 2011

OpenSTA and ASP.NET Sessions

Assume there is an ASP.NET application that uses sessions (which application doesn't).

If you record a launch sequence in OpenSTA and test it out, you'd realize that session handling is not working properly.

Here's why it doesn't work and how you can fix this.

The test application, for our use case here, has a page called CreateSession.aspx that, as the name indicates, creates a session. It then redirects to test.aspx. If ASP.NET was setup to track sessions using cookies, the response to the first request (to CreateSession.aspx) would have a set-cookie header and this cookie would be sent to the second request (to test.aspx).

Here is what OpenSTA has recorded for this sequence.





Check out the highlighted lines. Here's what the script does

  • Creates a variable cookie_2_0
  • Creates a constant S_cookie_2_0
  • Saves the cookie returned by request to CreateSession.aspx in cookie_2_0
  • Sends S_cookie_2_0 as the ASP.NET cookie to all other request

That is the problem. It saves the cookie rightly in a variable, put for other requests it passes the constant. When the test runs, the first request would create a session, but the other pages would get the constant value saved in S_cookie_2_0. Obviously, this would never match an existing ASP session and the test fails miserably.

The fix is now fairly obvious - Instead of sending S_cookie_2_0 as the ASP.NET cookie to all other request, send cookie_2_0 where the ASP.NET session cookie was stored.

  • Delete the line that defines the constant S_cookie_2_0 – we don't need it
  • Search and replace S_cookie_2_0 with cookie_2_0

This is how the script looks after the change





Happy Load Testing !

10 February 2011

SqlClient – Connection Delay/Timeouts

Recently we were faced with a problem where connections to SQL Server (using ADO.NET System.Data.SqlClient) from a web server were taking just too long or were timing out.

It turned out that although the SQL Server was listening on all 3 protocols (shared memory, TCP, named pipes), there was a firewall between the web and SQL server and the default TCP port 1433 was not open.

Looks like the SqlClient tries all the protocols - shared memory, TCP, named pipes - in that order till it finds a valid protocol. Since namedpipes was the only valid protocol, the connection was taking long/timing out, since all other protocols had to fail before it attempted to use namedpipes.

Here is a blog post which discusses this behaviour - http://blogs.msdn.com/b/adonet/archive/2010/04/18/sqlclient-default-protocol-order.aspx

On the web server, we created an alias for the server and configured the alias to use the named pipes protocol. We also disabled all the other protocols in the SQL Client Configuration. This seemingly solved the problem.

Here are a few more good reads on the issue: