最近我在Jython平台上玩Django,并希望在“生产”中看到它的表现。我测试的网站只是一个简单的return HttpResponse("Time %.2f" % time.time())
视图,因此不涉及数据库。
我尝试了以下两种组合(使用ab -c15 -n500 -k <url>
进行的测量,VirtualBox上的Ubuntu Server 10.10中的所有内容):
J2EE应用服务器(Tomcat / Glassfish),已部署的WAR文件
我得到的结果如
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)
显然,服务器偶尔会挂起几秒钟,这是不可接受的。我认为它与重新加载Jython有关,因为启动jython
shell大约需要3秒。
AJP使用修补的flup包服务(+ Apache作为前端)
注意:flup是manage.py runfcgi
使用的包,我不得不修补它因为flup的线程/分叉支持似乎不适用于Jython( - &gt; AJP是唯一的工作方法)。
这里的结果几乎相同,但有时最后100个请求根本没有得到解答(但服务器进程仍然存在)。
我在SO上问这个(而不是serverfault),因为它特别是Django / Jython。 有没有人有在Jython上部署Django网站的经验?是否可能有另一种(更快)的方式来服务该网站?或者在Java平台上使用Django还为时尚早?
答案 0 :(得分:17)
所以当没有人回复时,我调查了一下,似乎我的问题可能与VirtualBox有关。使用不同的服务器操作系统(Debian Squeeze,Ubuntu Server),我遇到了类似的问题。例如,通过简单的静态文件服务,我从Apache Web服务器(在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)
这导致了结论(我没有得出结论,但是)我认为Java重新加载可能不是问题,而是虚拟化。我将在一个真实的主机上试一试,直到那时才回答这个问题。
现在我在Apache上使用Jython + AJP over TCP / mod_proxy_ajp成功测试了一个简单的Django站点(实际上只是欢迎页面)(再次使用修补的flup包)。这次是在真正的主机上(i7 920,6 GB RAM)。结果证明我的上述假设是正确的,并且我真的不应该再次在虚拟主机上进行基准测试。这是欢迎页面的结果:
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
我很有希望。唯一的缺点是平均请求时间> 1。 40毫秒,而开发服务器的平均值为&lt; 3毫秒。