Openerp压力测试:OpenERP Web Client 无缓存1000并发测试OpenERP Server 性能
-
看到本文标题,你的第一反应会不会是:”标题党?!拖出去面壁。。。“。 好吧,我承认标题是有点那个啥(又长又X ?),嗯,你懂得。但是,但是,绝对不是标题党,耐心看完全文,你心中自会有答案。
你可能有会说,”你丫的OE压力测试第一篇(Openerp压力测试:Openerp到底能支撑多大的用户数?)中,不都是通过OE Web Client测试的么?怎么又测啊?“。嗯,第一篇测试中呢,其实很大部分是由于OE Web Client 的缓存机制,未能测试到OE Server 的真正性能。本文是通过调整OE Web Client 的参数,让OE Web Client 不使用缓存,直接连接到OE Server,从而达到测试OE Server 的真正性能。
你可能又有会问,”你丫的OE压力测试第二篇(Openerp压力测试:多线程直连OE Server NET-RPC/XML-RPC端口测试)中,不是直接连接到OE Server测试的么?怎么又测啊?“。这个问题简直让我内流满面啊,触痛了我内心深处最柔软的地方啊。。。
在我的第二篇测试中,我写了一个测试工具,心中一阵小得意呀。当我把并发数调到1000时,频繁出现的错误thread.error: can't start new thread。放狗(google)搜索发现,这个原来是python的硬伤(用关键词 python thread number limit 或者 python线程总数限制),另外由于cPython 的实现,还存在GIL的问题,让python 在多线程中无法利用现代的多核CPU。想当年,我先后搞过VB、C#、JAVA、PHP、PYTHON(多数是学而不精),终于发现PYTHON符合我的梦中情人标准,除非客户指定,其他一概非PYTHON不用。而现在居然掉链子,痛啊。而ab (ApacheBench)呢,则是正儿八经的C程序代码,不存在上面的问题。而我的C语言,早就还给老师了,悔啊。
本次测试的框架依然是 ab -> OpenERP Web Client -> OpenERP Server,本次测试OE Web Client 和 OE Server 采用Net-rpc 方式连接,不再测试Xml-rpc连接方式。
软硬件环境
DELL 1420 笔记本
CPU:Intel(R) Core(TM)2 Duo CPU T5450 @ 1.66GHz
内存:1G
硬盘:160G
操作系统:Debian Linux 2.6.39-2-686-pae #1 SMP Tue Jul 5 03:48:49 UTC 2011 i686 GNU/Linux
OpenERP Server版本:openerp-server-6.0.2
OpenERP web client:openerp-web-6.0.2
CherryPY 版本:3.1.2
相关参数设置
Openerp Server:编辑 netrpc_server.py 修改 self.socket.listen(1024),编辑openerp-server.conf 添加db_maxconn = 128。详细的修改方式和说明,请参见拙文Openerp压力测试:多线程直连OE Server NET-RPC/XML-RPC端口测试。
CherryPY:编辑_cpserver.py 修改 socket_queue_size = 500 和 thread_pool = 1024。详细的修改方式和说明,请参见拙文Openerp压力测试:Openerp到底能支撑多大的用户数?。
Opery Web Client:现在是见证奇迹的时候了。。。吼吼吼,关键部分来了。打开openerp-web.cfg,确认 server.environment = "development"(如果你是源码下载,这个就是默认值,无须修改)。当 server.environment = "development" 的时候,Opery Web Client 就不会启用缓存鸟。有以下代码为证(openerp-web-6.0.2/addons/openerp/utils/cache.py 第40行):<br />def memoize(limit=100, force=False):<br /><br /> def memoize_wrapper(func):<br /><br /> # Don't use cache for development environment<br /> if not force and cherrypy.config.get('server.environment') == 'development':<br /> return func<br />#---------------------省略无数代码----------------------------<br />
注:本文是出于测试的目的,而改为server.environment = "development"。如果你是正式部署OE,建议你还是修改为server.environment = "production"。
测试过程
详细的测试方法和说明,请参见拙文Openerp压力测试:Openerp到底能支撑多大的用户数?,此处不再重复。本次只贴出测试1000并发的测试结果,100并发或更小请各位自行测试。
1、1000并发测试首页(点击下载测试结果文件)<br />$ ab -n 1000 -c 1000 'http://127.0.0.1:8080/openerp/login?db=&user='<br /><br />Document Path: /openerp/login?db=&user=<br />Document Length: 11383 bytes<br /><br />Concurrency Level: 1000<br />Time taken for tests: 10.975 seconds<br />Complete requests: 1000<br />Failed requests: 1<br /> (Connect: 0, Receive: 0, Length: 1, Exceptions: 0)<br />Write errors: 0<br />Non-2xx responses: 1<br />Total transferred: 11641615 bytes<br />HTML transferred: 11386611 bytes<br />Requests per second: 91.11 [#/sec] (mean)<br />Time per request: 10975.458 [ms] (mean)<br />Time per request: 10.975 [ms] (mean, across all concurrent requests)<br />Transfer rate: 1035.84 [Kbytes/sec] received<br />
2、1000并发测试销售单页面(需登陆)(点击下载测试结果文件)<br />$ ab -n 1000 -c 1000 -C session_id=7745241afabf7182009a6e2d9d82ba1451f7fc6e 'http://127.0.0.1:8080/openerp/form/view?model=sale.order&id=1'<br /><br />Document Path: /openerp/form/view?model=sale.order&id=1<br />Document Length: 96183 bytes<br /><br />Concurrency Level: 1000<br />Time taken for tests: 338.386 seconds<br />Complete requests: 1000<br />Failed requests: 0<br />Write errors: 0<br />Total transferred: 96438000 bytes<br />HTML transferred: 96183000 bytes<br />Requests per second: 2.96 [#/sec] (mean)<br />Time per request: 338386.001 [ms] (mean)<br />Time per request: 338.386 [ms] (mean, across all concurrent requests)<br />Transfer rate: 278.31 [Kbytes/sec] received<br /><br />
此处使用的URL需要说明下,如果你直接从浏览器的地址栏复制url 地址,类似/openerp/menu?active=73 这样的地址,通过 ab 测试是不准确的。
浏览器访问是其实是分2步的,第一步是下载一些html 和 javascript,第二步浏览器会执行javascript ajax xhr 请求,第二步才是真正获取订单信息。你可以发现,在点击页面时经常会出现 “loading...”,这个时候就是浏览器在进行ajax xhr 。 而ab 访问的话只会读取http header 只要200就OK了,而不会去下载处理javascript。
要想读取执行真正的订单信息,要使用/openerp/form/view?model=sale.order&id=1这样的URL才行。这个地址我是通过Firefox 的Firebug 插件找出来的,大家也可以试试看。
OE Web Client 是通过Net-rpc 直接连接OE Server?没有启用缓存?
答案是YES!OE Web Client 没有启用缓存,每个请求都通过Net-rpc 连接到OE Server来获取结果。我可以添加一行代码来证明这点。打开openerp-server-6.0.2/bin/service/netrpc_server.py,在第69行后添加一句 print msg ,如下面的代码:<br />#---------------------省略无数代码----------------------------#---------------------省略无数代码----------------------------<br />class TinySocketClientThread(threading.Thread, netsvc.OpenERPDispatcher):<br />#---------------------省略无数代码----------------------------<br /> def run(self):<br />#---------------------省略无数代码----------------------------<br /> while self.running:<br /> try:<br /> msg = ts.myreceive()<br /> #此处添加下面的一行 line 70<br /> print msg<br /> result = self.dispatch(msg[0], msg[1], msg[2:])<br /> ts.mysend(result)<br /> except socket.timeout:<br /> #terminate this channel because other endpoint is gone<br /> break<br />#---------------------省略无数代码----------------------------<br />
修改代码后重启OE Server ,然后再跑测试2,如果你和我一样也是终端启动OE Server的话,那么你的终端窗口将会哗啦啦的输出一大堆代码,这就是print msg 的作用。这句代码证明OE Web Client 对每个请求都会通过NET-RPC发送接受数据。
结论
通过上面的测试数据,可以证明OE Web Server 架构的优秀性,而通过对比之前测试数据,OE Web Client 的缓存开启,也是可以极大提高性能。引用QQ群里一位资深专家shelly说的话,“其实并发100已经相当牛X了”,而在日常情况下,100并发已经足以支撑上万名员工同时使用了。
我个人认为 OE Server 在进行适当的参数优化后,支持1000并发用户,完全没有问题。当然本次测试不算完整,上面的测试都是读取数据测试,没有进行写数据的测试。还有就是以上测试都是限定在一个数据库里,或者叫做一个帐套,没有进行多数据库的读写测试。
以上测试数据仅供各位参考,我只保证本人测试数据的真实性。我希望大家有条件的话,自己动手,亲自体验OE 的优秀性能!
本文转自本人博客 [检测到链接无效,已移除] ,测试结果文件请到本人博客下载。 -
看到好贴,岂有不回之理?!