Tag : login
Scalability-wise, authentication is one of the most critical functions in a web application. Why? For most non-trivial web applications, the majority of their functionality requires prior authentication. The implication here is that the scalability of the system’s authentication provides a hard-ceiling on your website’s scalability. If your users can’t login, they can’t get to your website’s other functionality.
What is an authentication script in the load/performance testing world? Very simply, it is a targeted script that logs in and logs out of your web application. The authentication script is used to simulate a portion of the load the application experiences during normal usage.
Testing a website’s authentication performance correctly can be challenging. What are the key considerations in an authentication script?
To isolate authentication functionality, a login script should touch as few other pages as possible. If any extraneous pages are included, they should be chosen to be the least impactful from a resource perspective. It is common for web applications to redirect to the last page a user was on before they logged in. In this case, the page should be a fairly simple page, with as little on-page business logic or database calls as possible.
On the same token, scripts other than the login script should touch the login functionality as seldomly as possible, and should not be logging in and out with each iteration. Scripts that login and out on each iteration overweight and overstress the authentication components.
Isolating the authentication functionality achieves several things
For many sites, the login script (in pseudocode) is simply
post credentials to /login,
verify landing page is in authenticated state
verify page is in unauthenticated state
An authentication script should verify that the landing page post-login is in an authenticated state–as opposed to displaying an error, or remaining unauthenticated. The easiest way to accomplish this for most sites is to check the rendered HTML for the username if it is displayed. This isn’t always possible, but provides a quick and easy check. Alternately, check for content that is only present when a user is authenticated.
Additionally, after logging out, the post-logout page should be checked to confirm the username is absent.
Databanking and Caching
At the application-level, applications often cache recent users. Because of this, to make an authentication script’s load characteristics realistic, it needs to authenticate with many different users. So when creating a login/logout script, it must be databanked (aka data-driven) with enough records to simulate normal usage and prevent the application from surviving off cached records, which would skew your results with an overly positive performance result.