I thought you all might find this to be of interest. Bret
---------- Forwarded message ---------- From: Andrew Geweke <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Date: Fri, 22 Jun 2007 10:15:25 -0700 Subject: Re: [jruby-user] Eclipse, JIRB, and long-run production development. On Jun 22, 2007, at 6:56 AM, [EMAIL PROTECTED] wrote:
I guess he felt the java folks were in an envious position because of the tools available to them for diagnosing the non-functional problems that arise when scaling the app. Perhaps there are plenty of tools and best practices out there for diagnosing/resolving these problems with jruby that we're not aware of?? Would you have any suggestions?
I know this isn't exactly what you're asking, but I believe the exact same things that make Ruby/JRuby a superb language for developing software can also make it superb for testing that same software, whether it's functional tests, performance tests, scalability tests, or whatever. No language wars, *please*, but here's an interesting concrete example: we have here an enormous legacy web app written in Java with a very complex HTML UI that lets users conduct sophisticated transactions. We need to test its scalability for an upcoming deployment to tens or hundreds of thousands of users. Any load-testing tool we have is going to have to 'learn' about how to manipulate the HTML UI in many complex ways. (You can't just run prerecorded scripts against it, because there are literally tens of thousands of different possible user behaviors.) We considered using JMeter, but this would've involved an enormous amount of time writing JMeter scripts, maintaining them over time, and probably wouldn't have been flexible enough anyway. (One of the limitations of JMeter is that 1 session = 1 thread; if you have 50 users pounding your server, it's fine. But if you need to simulate 100,000 users over a week, you lose -- I'm pretty sure you can't create 100,000 threads on any mainstream OS these days. :-) Using JRuby, we solved the problem in a novel way, by leveraging our existing WATIR codebase that was used for functional tests. We grafted a new backend onto WATIR (easier than it sounds, actually) that talks not to IE but to the Apache Commons HTTPClient (Java) and uses the NekoHTML parser (Java) to generate an XML DOM tree (Java). We have a Ruby layer that emulates enough of the IE DOM on top of that to allow WATIR to work just fine. Couple that with a nice scheduler and thread pool, and you suddenly really can instantiate very large numbers of clients (an Apache Commons HTTPClient object instance is *much* more lightweight than an IE process) that each run plain-vanilla WATIR client code to do some very serious scalability testing. In this case, JRuby made it all possible -- leveraging existing mature Java libraries (Apache Commons HTTPClient and NekoHTML) and a powerful, growing Ruby tool (WATIR) together to get the results we wanted a *lot* faster than any equivalent solution (and especially in the future, as using some other tool would've given us two duplicate very large codebases of testing code that each had to be updated for every single UI change). Anyway, in this case, the ability of Ruby to so quickly build and adapt the tools we needed vastly outweighed any benefit of existing tools already being built... --------------------------------------------------------------------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email
_______________________________________________ Wtr-general mailing list Wtr-general@rubyforge.org http://rubyforge.org/mailman/listinfo/wtr-general
