MarkUs Blog

MarkUs Developers Blog About Their Project

Why script based load simulation for MarkUs is difficult

with one comment

I am trying to get some data about how MarkUs behaves under load. One aspect would also be to get a better feel for how scalable MarkUs is. I’m aiming to simulate a production environment which is something of the order of a couple of hundred students submitting code (and perhaps implicitly creating a Subversion repositories) at the same time. So far I’ve been trying to create a script which logs on to MarkUs, visits relevant pages and submits code. However, I’ve been hitting a bit of a snag. And here is why.

Problem 1: Cookies

Since MarkUs is a web application and the Web is stateless per se, something needs to be done on top of plain HTTP in order to maintain sessions. The most commonly used session tracking mechanism is to use cookies (an alternative would be URL rewriting). In the MarkUs case it’s one cookie which stores the session id of a particular user. If a browser requests a MarkUs page it usually gets a header Set-Cookie with the cookie info back. If not disabled by the user, the browser sends all cookies for this particular server (or path for that matter) which were previously set with the Set-Cookie header back to the server. This happens under the covers of a Web browser and a user usually does not realize that cookies are sent back and forth along with requests and responses. However, when using a script one has to be careful to store the cookie and send it back on subsequent requests. As it turns out this was a problem for my Ruby based script. I didn’t quite figure out why :(. In any case, curl seems to be doing a better job, so this is what I’m going to try next.

Problem 2: HTTP Redirects

Another thing which makes script based load testing painful is that HTTP redirects can happen. Redirects are nothing other than mini responses sent back to the client telling it the actual location of the source. When using a Web browser, this is almost not noticable, since the browser usually follows redirects (i.e. automatically requests the new location). Again, this is different in a script based walk through a web application. One might get a redirect response when you are not expecting one and if you’re not careful, you’ve hammered a certain page many times only to realize that you have been getting redirect responses. What’s more, MarkUs generates redirects if it thinks that the user is not logged in. Forget to send the cookie you’ve gotten earlier and MarkUs will redirect you to the log-in page instead of giving you the response for a particular page or servicing a HTTP POST request.

Why not turn off authentication and sessions entirely?

Some of you might think that I could just turn off sessions and authentication as a whole, but this won’t work well either. First note that I’d have to change a fair bit of MarkUs code to get it working without any authentication. Second, with authentication turned off, there is no notion of different users anymore. All of a sudden all requests belong to one single user. Hence, we don’t want this for script based load testing of MarkUs either. We want to simulate hundreds of users logging in simultaneously and not one single user over and over again.

Conclusion

For script based load testing I’ll have to make cookies work and deal with redirects. For the time being a curl based solution seems most promising. This won’t yield any request timing data on the client side eventually, though. I could manually time requests in order to get a feel of how long MarkUs takes to serve them under load, but not sure if that’s a high priority. Once I can simulate some load, I’ll use request times in the logs to approximate request/response times. Wouldn’t I have to deal with cookies and redirects, Apache Bench could be viable, but it seems it doesn’t handle cookies and redirects very well. I’ll keep you posted as to how it goes.

As usual, please leave a comment if you have thoughts about this or I’m missing something very obvious and am just not doing it right 😉

Written by Severin

October 23rd, 2011 at 5:47 pm

Posted in Uncategorized

One Response to 'Why script based load simulation for MarkUs is difficult'

Subscribe to comments with RSS or TrackBack to 'Why script based load simulation for MarkUs is difficult'.

  1. I think the problem with the Ruby bases script was that one needs to update the MarkUs cookie on each request. Then send the updated cookie back to the server. I haven’t tested this though.

    Severin

    31 Oct 11 at 12:08 pm

Leave a Reply