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 的优秀性能！
本文转自本人博客 [检测到链接无效，已移除] ，测试结果文件请到本人博客下载。 -
看到好贴，岂有不回之理？！
