So I have here with me Joe Walker from ...?
SitePen. I'm the first UK employee.
How long have you been there now?
6 months now.
And what are you doing at SitePen?
Where does DWR actually fit, within the architecture? Where does it fit between the browser and the server?
I think many people will be using commercial testing suites and a lot of those are basically running browsers themselves. You have some script which controls the browser which then does its stuff to the network and to the server. That of course is a very heavy weight solution, simply because you have to have an entire browser or set of browsers around. If you want to simulate a thousand users, you've got to have the memory and the resources to fire up a thousand browsers, which is a very inefficient way of doing things.
So I have for a while wanted a way of simulating a browser without the weight of a browser, which sounds like it ought to be easy. The problem is that browsers are so buggy and nasty that sometimes you end up with your protocol changing in order to work around browser bugs.
But with server site testing, we generally don't care how the client functions, we try to throw requests at the server at the right frequencies and then look to see how the server responds. Why do I care that the browsers all have bugs in them?
Okay, so a concrete example: I'm sort of going to pick on Safari a bit here, but Safari is by no means the buggiest browser. Safari has memory leak on XHR (XMLHttpRequest) which of course AJAX is built on. You can get around that memory leakage by using iframes. In this case you might need to send a slightly different response for an iframe compared with the XHR call. This is just one small example, there are many more, and particularly when you are talking about comet services, the network protocol can change quite a bit to work around browser deficiencies.
There are network protocols like JSONP, which make testing easy, but if your system is doing more advanced work then simply recording the network traffic from a single browser may not be enough.
So you have the very nasty situation, that, in order to do a 100% realistic testing you might need real browser bugs, because the workarounds might affect performance.
So what you are saying is that if you're coming in with Safari and iframes, then DWR is actually going to push that traffic back down on to the server differently then if I come in with a Firefox browser?
Yes, the wire protocol is different depending on what the browsers are. Definitely, yeah.
Right. So, now from a testing point of view or a stress testing point of view, we not only have to worry about what the requests are, we have to actually worry about the format in which they are delivered?
And this gets quickly, non-linear, it's ...
It's disgusting, yeah. Particularly with comet, there's all sorts of ways in which the wire protocol changes depending on the browser you've got. Firefox is very good at streaming. Opera has got streaming which is built in, but in a different way. In IE, streaming is virtually impossible unless you use this bizarre ActiveX control called 'htmlfile', and then it will stream data, just. But all those different options for streaming data from the server to the client involve protocol changes. And to make matters worse, the protocol changes not just on the browser, but the version of the browser as well.
Hmm. So how do you see people working around this? I know some organization will just say "we're supporting IE", and that's pretty much it.
Yeah, but fortunately less and less people are doing that now.
And that might not be an option for many.
I think the right tool doesn't really exist yet. I guess we know the kind of interface that we want. We want to sit down at a browser and we want to click on "record" and record a session. At the end you press stop and the thing has recorded the script for you. Selenium and many other systems can do some of that. This type of script is a user-interface script, and not a network level script.
User interface scripts are OK for unit testing/integration testing and so on, but they're not good for load testing. You want to play it back without having lots of heavyweight browsers. So what you then need is a process which will take a user interface script, and will create a set of network level scripts, one for each browser that you are interested in. Then you can use these network level scripts without having heavyweight browsers for the purpose of load testing.
Right. The Selenium script would be a nice starting point you can use to include randomization of data inputs, the timing information and other such load-testing features.
Well, Selenium remote control will help you with that. It enables you turn a simple Seleneese script into Java (or a whole set of other langauges). This makes it easy to include randomized data from any data source that Java can read from. Timing is as simple as calling sleep, and so on.
Yeah, absolutely. So you take the Selenium script as a starting point and then go from there.
So, on a more general topic about DWR, are people using DWR for functional reasons mostly or are there some performance advantages for using DWR in the middle of your architecture?
There could be. One performance advantage that DWR can give you is batching. If you've got five calls to make to the server, DWR can batch them together and just have one wire connection in order to execute five calls. DWR takes charge of batching them up, making a single network connection, evaluating all five, and then separating out the answers once more on the client.
So you get some sort of bulking up technology taking place?
That sounds like an interesting feature. Thanks you very much for talking to us.
Thank you too.