Jython + Django not ready for production?

Question

So recently I was playing around with Django on the Jython platform and wanted to see its performance in "production". The site I tested with was just a simple return HttpResponse("Time %.2f" % time.time()) view, so no database involved. I tried the following two combinations (measurements done with ab -c15 -n500 -k <url>, everything in Ubuntu Server 10.10 on VirtualBox):

• J2EE application server (Tomcat/Glassfish), deployed WAR file

  I get results like

  Requests per second:    143.50 [#/sec] (mean)
  [...]
  Percentage of the requests served within a certain time (ms)
    50%     16
    66%     16
    75%     16
    80%     16
    90%     31
    95%     31
    98%    641
    99%   3219
   100%   3219 (longest request)
  

  Obviously, the server hangs for a few seconds once in a while, which is not acceptable. I assume it has something to do with reloading Jython because starting the jython shell takes about 3 seconds, too.

• AJP serving using patched flup package (+ Apache as frontend)

  Note: flup is the package used by manage.py runfcgi, I had to patch it because flup's threading/forking support doesn't seem to work on Jython (-> AJP was the only working method).

  Almost the same results here, but sometimes the last 100 requests don't even get answered at all (but server process still alive).

I'm asking this on SO (instead of serverfault) because it's very Django/Jython-specific. Does anyone have experience with deploying Django sites on Jython? Is there maybe another (faster) way to serve the site? Or is it just too early to use Django on the Java platform?

Answer 1

So as nobody replied, I investigated a bit more and it seems like my problem might have to do with VirtualBox. Using different server OSes (Debian Squeeze, Ubuntu Server), I had similar problems. For example, with simple static file serving, I got this result from the Apache web server (on Debian):

> ab -c50 -n1000 http://ip.of.my.vm/some/static/file.css

Requests per second:    91.95 [#/sec] (mean)    <--- quite impossible for static serving
[...]
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    2  22.1      0     688
Processing:     0  206 991.4     31    9188
Waiting:        0   96 401.2     16    3031
Total:          0  208 991.7     31    9203

Percentage of the requests served within a certain time (ms)
  50%     31
  66%     47
  75%     63
  80%     78
  90%    156
  95%    781
  98%    844
  99%   9141                            <--- !!!!!!
 100%   9203 (longest request)

This led to the conclusion that (I don't have a conclusion, but) I think the Java reloading might not be the problem here, rather the virtualization. I will try it on a real host and leave this question unanswered till then.

---

FOLLOWUP

Now I successfully tested a bare-bones Django site (really just the welcome page) using Jython + AJP over TCP/mod_proxy_ajp on Apache (again with patched flup package). This time on a real host (i7 920, 6 GB RAM). The result proved that my above assumption was correct and that I really should never benchmark on a virtual host again. Here's the result for the welcome page:

Document Path:          /jython-test/
Document Length:        2059 bytes

Concurrency Level:      40
Time taken for tests:   24.688 seconds
Complete requests:      20000
Failed requests:        0
Write errors:           0
Keep-Alive requests:    0
Total transferred:      43640000 bytes
HTML transferred:       41180000 bytes
Requests per second:    810.11 [#/sec] (mean)
Time per request:       49.376 [ms] (mean)
Time per request:       1.234 [ms] (mean, across all concurrent requests)
Transfer rate:          1726.23 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.5      0      20
Processing:     2   49  16.5     44     255
Waiting:        0   48  16.5     44     255
Total:          2   49  16.5     45     256

Percentage of the requests served within a certain time (ms)
  50%     45
  66%     48
  75%     51
  80%     53
  90%     69
  95%     80
  98%     90
  99%     97
 100%    256 (longest request)   # <-- no multiple seconds of waiting anymore

Very promising, I would say. The only downside is that the average request time is > 40 ms whereas the development server has a mean of < 3 ms.