|
|
|
|
Our columnist, Kirk Pepperdine, interviews Joe Walker of SitePen, a leading suport organisation for open source projects and web applications. Joe covers the advantages of DWR for your Java to Javascript apps, and considers the issues involved in load testing these types of apps.Published April 2008, Author Kirk Pepperdine
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?
Mostly I'm developing DWR. DWR is a library to help you connect JavaScript in a browser with Java on the server. It's been around for a while, and is probably one of the longest serving Java AJAX libraries, so it's got lots of users. I joined SitePen because DWR has lots of potential that I can't fulfill myself. So SitePen are offering professional support and development services around DWR.
SitePen was formed by some of the founders of the Dojo project, so they now offer support for both DWR and Dojo. Dojo is one of the most popular JavaScript widget frameworks.
Where does DWR actually fit, within the architecture? Where does it fit between the browser and the server?
Oh, it's both. You give DWR a Java class and it gives you some JavaScript stubs. And when you call the JavaScript stubs, DWR calls Java in the same way. So, part of DWR is on the server and part on the client.
My guess is that for most of the people who are reading this interview, JavaScript is very much a new world for them. Our focus has been on server side Java, whereas JavaScript is really like a client side technology. But more and more what's happening, and this is especially true if you're getting into trying to stress test or load test a Web2.0 fronted application, is that dealing with JavaScript and the other "things" that are coming from the server is really starting to make life difficult. We don't yet have really good support for this technology in our load testing tools. How are you managing to, or better yet, how do you see your customers managing load testing at the moment?
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?
Yeah.
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.
Exactly.
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?
Yeah, absolutely. We're kind of hoping that in DWR3 to have that be a totally transparent operation that works with the threading model in JavaScript to automatically batch calls.
That sounds like an interesting feature. Thanks you very much for talking to us.
Thank you too.
