JavaScript on the server: benchmarks and example code

Colin Clark colin.clark at utoronto.ca
Sat Jun 6 20:52:18 UTC 2009


Hi everyone,

In follow up to my previous email about our prospects for using Jack  
and JSGI as a web container for running JavaScript on the server, I've  
put together some examples.

Using the Rhino and Servlet-based version of Jack, I was able to put  
together a simple application that runs the JavaScript language  
benchmarks that Antranig wrote awhile back. It took a bit of work to  
get the environment set up for running browser-oriented code on the  
server, but all in all it was a straightforward process.

Here's a link to the client-side versions of Antranig's performance  
tests, which you can run in any browser:
https://source.fluidproject.org/svn/sandbox/js-perftests/

And here's a link to the server-side Jack application that runs the  
same set of benchmarks:
https://source.fluidproject.org/svn/sandbox/jack-test/trunk/

The short answer to the performance question is that Rhino appears to  
land somewhere between the speed of Firefox 2 and 3. This is still  
substantially slower than some of the modern runtimes such as  
Tracemonkey in Firefox 3.5, SquirellFish in Safari 4, and V8 in  
Chrome. But the results do suggest to me that we can viably work in  
Rhino for awhile, moving to one of the faster runtimes as they become  
available on the server.

Rough instructions for getting this perftest application working:

1. Check out jack-test/trunk from the sandbox.
2. Add Narwhal's scripts to your path (e.g. "export PATH=$PATH:<path/ 
to/narwhal>/bin")
3. Inside the narwhal/perftests directory, run "../jack/bin/jackup  
perftest.js"
4. Point your browser at the Jack servlet container running on port 8080

If you tour through the code, you'll notice that I don't take full  
advantage of our Renderer yet. Instead, I rely on John Resig's Envjs  
library to provide a DOM library within Rhino. As a result, Infusion  
is fully convinced it is running within a browser environment. A more  
sensible implementation would use the Renderer entirely, loading the  
page template from a file, calling parseTemplates(), and then  
returning the results of renderTemplates() as a String in the response  
body.

I'll follow up with another email about next steps for the services  
team, since I think our work writing an importer for McCord's XML  
artifact data will be an excellent real-world comparison between  
Rhino, a more modern runtime like V8, and Python.

Colin

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org