Openerp压力测试
-
OpenERP（以下简称为OE） 是一个开源ERP/CRM系统，使用Python语言开发，数据库采用开源的PostgreSQL，系统以GNU GPL开 源协议发布。在过去人们的印象中，OE一般是用在中小企业居多。除了业务上、功能上等因素外，技术上的因素也是需要考虑，OE能否顶住大流量、高并发的各种操作呢？本文对OE进行了一系列的压力测试，当然测试方法可能比较单一和片面，所得出的测试结果也是仅供各位看官参考。
1. 测试环境
1.1 硬件环境
DELL 1420 笔记本
CPU：Intel(R) Core(TM)2 Duo CPU T5450 @ 1.66GHz
内存：1G
硬盘：160G
1.2 软件环境
操作系统：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
1.3 相关参数设置
OE Server：启动方式为 ./openerp-server.py -c openerp-server.conf ，conf 配置文件是从deb 包解压出来的，没有做任何修改。
安装了一个test帐套，默认安装了测试数据，语言选取为英文。启用了CRM、SALES、WAREHOUSE、INVOCING、ACCOUNTING、PURCHASE 模块。
OE Web：启动方式为 ./openerp-web.py ，默认加载的配置文件为 ./doc/openerp-web.cfg ，修改第二行为 server.environment = "production"，其他保持默认。（默认值为server.environment = "development"时，会加载_TimeoutMonitor 和 Autoreloader，会降低部分性能。）
CherryPY：在cherrypy/_cpserver.py文件中有两个重要参数，分别是46行的socket_queue_size = 5 和 51行thread_pool = 10 ，这里修改为socket_queue_size = 500 和 thread_pool = 1000。（这两个参数如果在保持默认值的情况下，连并发100都跑不了。不明白CherryPY的默认值为什么这么低 ...）
注：oe server 和 oe web client 都直接下载源码运行，未使用deb安装版。
1.4 测试方法
采用ab (ApacheBench) 工具，分别进行10、100、1000并发，总数1000的任务，对OE web client 进行访问，也就是http://127.0.0.1:8080 。分别测试首页和内页（内页访问是需要登录的，因此内页测试结果应该更接近实际使用情况）。
应当指出的是，这里只测试通过web 客户端并发方式，未使用GTK客户端的方式测试。通过GTK客户端方式访问，是直接访问OE Server ，少了OE Web Client 这层的转化，理论上应该比web 客户端方式效率更高。
2. 测试过程
由于篇幅的原因，下面没有贴出完整的测试输出，只贴了关键部分。如需完整的测试结果，请下载本文附件。
2.1 测试首页
关于首页地址，首页地址不能使用http://127.0.0.1:8080，因为访问http://127.0.0.1:8080时，OE Web Client 会返回一个http 303转向，因此只能使用 [检测到链接无效，已移除] 。
2.1.1 10并发测试
$ ab -n 1000 -c 10 'http://127.0.0.1:8080/openerp/login?db=&user='
Document Path: /openerp/login?db=&user=
Document Length: 11383 bytes
Concurrency Level: 10
Time taken for tests: 11.493 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 11638000 bytes
HTML transferred: 11383000 bytes
Requests per second: 87.01 [#/sec] (mean)
Time per request: 114.925 [ms] (mean)
Time per request: 11.493 [ms] (mean, across all concurrent requests)
Transfer rate: 988.92 [Kbytes/sec] received
2.1.2 100并发测试
$ ab -n 1000 -c 100 'http://127.0.0.1:8080/openerp/login?db=&user='
Document Path: /openerp/login?db=&user=
Document Length: 11383 bytes
Concurrency Level: 100
Time taken for tests: 10.237 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 11638000 bytes
HTML transferred: 11383000 bytes
Requests per second: 97.68 [#/sec] (mean)
Time per request: 1023.700 [ms] (mean)
Time per request: 10.237 [ms] (mean, across all concurrent requests)
Transfer rate: 1110.21 [Kbytes/sec] received
2.1.3 1000并发测试
$ ab -n 1000 -c 1000 'http://127.0.0.1:8080/openerp/login?db=&user='
Document Path: /openerp/login?db=&user=
Document Length: 11383 bytes
Concurrency Level: 1000
Time taken for tests: 12.416 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 11638000 bytes
HTML transferred: 11383000 bytes
Requests per second: 80.54 [#/sec] (mean)
Time per request: 12416.356 [ms] (mean)
Time per request: 12.416 [ms] (mean, across all concurrent requests)
Transfer rate: 915.34 [Kbytes/sec] received
从上面的结果来看，性能相当不错啊，呵呵。在并发1000的情况下，平均每个请求耗时12.416毫秒！通过分别察看10并发、100并发、1000并发的测试结果，可以看到处理时间并不一定随着并发数的增长而线性增长。
不过，ab 测试并不代表真实的情况，ab 工具只取了http 的 header 部分，只要是返回200就认为是成功的。而实际的浏览器请求中，还需要处理图片、JS、CSS等文件。另外，首页是不需要登录的，而实际使用当中，大部分都是需要登录的操作，因此下面的测试就通过访问一个菜单来模拟用户登录后的情况。
2.2 测试需要登录的内页
这里使用的URL地址是 [检测到链接无效，已移除] ，正常情况下是需要登录的。ab 工具提供了一个 -C 选项，可以设置cookie。通过设置cookie ，我们就可以模拟登录情况。
使用Firefox 访问http://127.0.0.1:8080并登录后，打开首选项->隐私->显示cookie，找到127.0.0.1，可以看到OE设置的cookie值，这里只要使用session_id就可以了。ab 的示例用法为：
$ ab -n 1000 -c 10 -C session_id=577291be968298c229eb887a618f881018e9b7a8 'http://127.0.0.1:8080/openerp/menu?active=73'
2.2.1 10并发测试
$ ab -n 1000 -c 10 -C session_id=b9df27fa455e06954ea3f08cade4ac911e0f688e 'http://127.0.0.1:8080/openerp/menu?active=73'
Document Path: /openerp/menu?active=73
Document Length: 127271 bytes
Concurrency Level: 10
Time taken for tests: 242.542 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 127527000 bytes
HTML transferred: 127271000 bytes
Requests per second: 4.12 [#/sec] (mean)
Time per request: 2425.418 [ms] (mean)
Time per request: 242.542 [ms] (mean, across all concurrent requests)
Transfer rate: 513.47 [Kbytes/sec] received
2.2.2 100并发测试
$ ab -n 1000 -c 100 -C session_id=b9df27fa455e06954ea3f08cade4ac911e0f688e 'http://127.0.0.1:8080/openerp/menu?active=73'
Document Path: /openerp/menu?active=73
Document Length: 127271 bytes
Concurrency Level: 100
Time taken for tests: 243.160 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 127527000 bytes
HTML transferred: 127271000 bytes
Requests per second: 4.11 [#/sec] (mean)
Time per request: 24315.977 [ms] (mean)
Time per request: 243.160 [ms] (mean, across all concurrent requests)
Transfer rate: 512.17 [Kbytes/sec] received
2.2.3 1000并发测试
$ ab -n 1000 -c 1000 -C session_id=b9df27fa455e06954ea3f08cade4ac911e0f688e 'http://127.0.0.1:8080/openerp/menu?active=73'
Document Path: /openerp/menu?active=73
Document Length: 127271 bytes
Concurrency Level: 1000
Time taken for tests: 243.017 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 127527000 bytes
HTML transferred: 127271000 bytes
Requests per second: 4.11 [#/sec] (mean)
Time per request: 243017.391 [ms] (mean)
Time per request: 243.017 [ms] (mean, across all concurrent requests)
Transfer rate: 512.47 [Kbytes/sec] received
从上面的结果来看，1000并发平均每个请求耗时243.017毫秒！。与首页测试12.416毫秒相比，差不多有19.57倍的差距。不过这也很正常，访问上面的菜单需要加载许多模块。分别观察10并发、100并发、1000并发的测试结果来看，处理时间的差距并不明显。
2.3 NET-RPC or XML-RPC ?
NET-RPC是OE支持的一个接口，察看源代码可以看到其实现机制是比较简单的，主要是通cPickle 模块将对象序列化，然后通过TCP Socket传输，接收后反序列化的一个过程。XML-RPC是工作在Internet上的远程过程调用协议，一个XML-RPC消息就是一个请求体为xml的http-post请求，被调用的方法在服务器端执行并将执行结果以xml格式编码后返回。
从原理上来说NET-RPC的速度要比XML-RPC快，官方也是推荐使用NET-RPC。那么到底快多少呢？请看下面的测试结果。
测试之前，需要修改./doc/openerp-web.cfg 配置文件，把52行修改为 openerp.server.protocol = 'http' 表示使用XML-RPC协议（原默认值是 socket，表示使用NET-RPC协议）。
此处，还需修改一个参数为 openerp.server.port = '8069'（默认值为8070，使用net-rpc协议）
2.3.1 XML-RPC 100 并发测试
$ ab -n 1000 -c 100 -C session_id=349f6eb43a5fb2b9227cd63f56ae666096f7381b 'http://127.0.0.1:8080/openerp/menu?active=73'
Document Path: /openerp/menu?active=73
Document Length: 127271 bytes
Concurrency Level: 100
Time taken for tests: 369.974 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 127527000 bytes
HTML transferred: 127271000 bytes
Requests per second: 2.70 [#/sec] (mean)
Time per request: 36997.414 [ms] (mean)
Time per request: 369.974 [ms] (mean, across all concurrent requests)
Transfer rate: 336.61 [Kbytes/sec] received
平均每请求耗时369.974毫秒，而上面使用NET-RPC100并发是243.160毫秒，是使用NETRPC的1.52倍。
3. 结论
通过以上的测试过程，我个人认为OE完全可以支持1000+的并发需求，满足企业的日常使用以及以后增长需求。尤其是在我这个老爷笔记本的硬件下，相信现在很多PC硬件已经几倍甚至几十倍超越我的笔记本了。
建议一：如果使用OE Web Client，建议调整CherryPY的socket_queue_size 和 thread_pool 参数，以提高CherryPY的并发支持能力，避免Web 副服务器成为应用瓶颈。
建议二：如果不是一定要使用XML-RPC的情况下，尽量使用NET-RPC协议。
本文转自本人博客 [检测到链接无效，已移除] ，以上测试结果文件请到本人博客下载。 -
@jimrich[quote author=jimrich link=topic=2553.msg29169#msg29169 date=1413439781]
我用pylot测试，觉得支持10个并发就不错了。想支持1000个并发，做梦吧？jsp的oracle ERP才差不多支1000个并发.
[/quote]
觉得？ 压力测试是一个专业的活，是需要拿数据说话的， 光觉得是不行的。兄弟也做了测试，不妨把你的测试方法，测试数据与我们分享一下，告诉我们如何得出10个并发的结果的。
我们对测试并不在行，但是也用funcload工具试着做了一个测试。测试中我们对OpenERP V7 针对订单创建，确认，生成发票的典型应用场景做了测试。使用的硬件条件基本与楼主相同内存为4G，与典型的服务器配置差很远，测试结果请见下面的链接：
http://openerp.cn/test/
在我们的测试中，订单创建/确认/生成发票的过程， 25并发响应非常良好，50并发开始变差， 并没有楼主说得那么不济。 -
测试方法:
配置 Intel E8400 3.00G 双核 4.0GRAM Windows XP wingIDE 前端未加 nginx 等, 直接调用.
python 多线程1000, 300, 200, 150 都测试过
1000线程 成功 200多
300 线程 成功 200多
200 线程 成功 180多
150 线程 成功 150. 几次 150线程测试都成功100%, 基本稳定
下面是150线程的测试结果数据
['start: 0.0', 'ready session and cookies: 14.3838699864', 'ready thread: 14.388 9531826', 'done thread: 14.9821065911', 'insert record: 150']
前面 14.384 秒 都在模拟登陆OE, 得到 150 条 Cookie 数据
0.005(14.389-14.384) 秒 启用 线程实例
后面 0.7秒(14.982-14.389) 就是线程开始调用, 并完成150条记录的创建时间..
