Load Runner and session persistance
During resilience work we have identified an issue with the combination
>of BigIP, Https, sendRedirect() and LoadRunner in a multi-server
>BigIP works by adding a cookie of its own to the connection. It uses
>this to ensure that once a given user has been associated with a given
>web server that link becomes concrete, and the same web server will be
>used to service all future requests within the session. In our
>multi-server environment the web server can send the request for
>processing on to one of many (two in our case) WebSphere servers, and
>may choose under some circumstances to change which WebSphere server
>handles the request. This is OK because the WebSphere servers hold
>the session data in a database which is available to all the servers,
>and this works provided the session data is serializable and certain
>rules are followed when an application updates it.
>We observed that when the application used a sendRedirect() call to
>move to the next page the mechanism used by BigIP to ensure that the
>user is firmly attached to the same web server breaks down. Once the
>user is transferred to a different web server the mechanism that
>WebSphere uses to identify the user session also breaks. The
>consequence is that a new Http session is started for the user, which
>means that all state within the application for that user is lost.
>This problem does not seem to happen with a regular browser, so we
>believe that no production user would ever experience it. However it
>does mean that the application cannot be load tested in a multi-server
>environment. It was not peculiar to LoadRunner, as we developed a
>load testing servlet which we could more tightly control and found
>that it exhibited the same behaviour.
>Has anyone come across a problem with Loadrunner or BigIP losing
>session affinity in this way?
Re: Load Runner and session persistance
Hey carry, if the session cookie is recorded in your script try commenting it out and re-running the tests.