Odoo中文社区可以通过以下三个域名访问:shine-it.net , odoocn.org,odoo.net.cn

原论坛用户的基本信息和发帖这里都予以保留,请注意:原论坛用户无需重新注册新用户,但是您的密码需要重置

开发人员可以登录gitter讨论组: http://gitter.im/odoo-china/Talk, 需要github账号

如果您登录系统碰到问题,请在微信公众号留言:

异步非阻塞 async_netrpc_server for openerp 简介及简单测试



  •         async_netrpc_server 是使用tornado 的ioloop 实现的异步非阻塞的net-rpc socket server for openerp。此模块是由本人开发并维护,现已托管在google code 上(http://code.google.com/p/openerp-asynchronous-non-blocking-net-rpc-server/),在google code 上,我写了简单的安装方法,有兴趣的朋友可以下载并测试。此模块为开源项目,欢迎大家参与。

            为什么要开发这个模块? 因为Openerp 官方的net-rpc server 是采取select 轮询的的socket 线程池模式,在一般情况下是没有任何问题的,但是如果在高并发的密集请求下,这种模式就会显得比较落后了。而tornado 是由facebook 开发的高性能框架,其核心是使用linux 的epoll (mac / bsd 下用 kqueue)实现异步非阻塞的socket模型。当然,windows下还是使用select 轮询,但并不是说windows 就一点都没用,线程池模式需要频繁创建和销毁对象,这对系统资源来说是一个很大的开销,而异步非阻塞的模型避免了这个缺点。所以,我在看了OE的代码之后,就萌生了这个想法,并因此有了这个模块。

            那么,这个模块到底怎么样?是骡子是马,拉出来溜溜。。。我做了简单的测试,请看下面。

    软硬件环境

            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.3
            OpenERP web client:openerp-web-6.0.3
            CherryPY 版本:3.1.2

    相关参数设置

            Openerp Server:

            1、编辑 netrpc_server.py  修改 self.socket.listen(1024)。这个是官方的net-rpc server 的socket 等待队列,默认值是5,10个并发就挂了,所以必须修改。
            2、编辑openerp-server.conf 添加db_maxconn = 128。这个是数据库连接池,默认值是64。
            3、编辑openerp-server.conf,设置 xmlrpc = False 和 xmlrpcs = False,不启动http xmlrpc 服务 和 https xmlrpc服务。
            4、测试官方的net-rpc server 时,编辑 openerp-server.conf 中 netrpc = True  ,async_netrpc = False ,只启动官方的net-rpc server 。
            5、测试async_netrpc_server 时,编辑 openerp-server.conf 中 netrpc = False  ,async_netrpc = True ,只启动async_netrpc_serve。

            Opery Web Client:

            1、打开openerp-web.cfg,确认 server.environment = "development"(如果你是源码下载,这个就是默认值,无须修改)。
            2、测试官方的net-rpc server 时,编辑openerp-web.cfg 中 openerp.server.port = '8070' 。
            3、测试async_netrpc_server 时,编辑openerp-web.cfg 中 openerp.server.port = '8008' 。

            CherryPY:编辑_cpserver.py 修改 socket_queue_size = 500 和 thread_pool = 1024。详细的修改方式和说明,请参见拙文Openerp压力测试:Openerp到底能支撑多大的用户数?。
    测试过程

            一、使用本人编写oetest.py 测试 10000总任务100并发测试(程序请到拙文Openerp压力测试:多线程直连OE Server NET-RPC/XML-RPC端口测试下载)

            测试官方的net-rpc server 时,修改oetest.py 参数 PORT = '8070' 。测试async_netrpc_server 时,修改oetest.py 参数 PORT = '8008' 。

            1、 官方的net-rpc server 测试结果

    [code]
    $ ./oetest.py

    Start at 2011-08-25 20:58:17.636473
    End  at 2011-08-25 20:59:35.510676

    Total Time: 0:01:20.874203
    [/code]
    2、 async_netrpc_server 测试结果
    [code]
    $ ./oetest.py

    Start at 2011-08-25 20:53:15.829595
    End  at 2011-08-25 20:54:18.310178

    Total Time: 0:01:02.480583
    [/code]

            从上面的结果来看,官方的net-rpc server处理时间是 80.87秒,async_netrpc_server 的处理时间是 62.48。(80.87−62.48)÷62.48 = %29.43 也就是说 async_netrpc_server 大概比官方的net-rpc server快 29%左右。那么,实际情况是否有如此大的差距呢?下面我们用ab (ApacheBench)来模拟下实际情况。

            二、通过ab 测试/openerp/form/view?model=sale.order&id=1 地址,1000总任务1000并发。

            本次测试的框架是 ab -> OpenERP Web Client -> OpenERP Server

            1、 官方的net-rpc server 测试结果(点击下载测试文件)

    [code]
    $ ab -n 1000 -c 1000 -C session_id=16273c836063c55a73ff154f048884b450b76bed 'http://127.0.0.1:8080/openerp/form/view?model=sale.order&id=1'

    Server Software:        CherryPy/3.1.2
    Server Hostname:        127.0.0.1
    Server Port:            8080

    Document Path:          /openerp/form/view?model=sale.order&id=1
    Document Length:        92818 bytes

    Concurrency Level:      1000
    Time taken for tests:  372.131 seconds
    Complete requests:      1000
    Failed requests:        0
    Write errors:          0
    Total transferred:      93073000 bytes
    HTML transferred:      92818000 bytes
    Requests per second:    2.69 [#/sec] (mean)
    Time per request:      372131.152 [ms] (mean)
    Time per request:      372.131 [ms] (mean, across all concurrent requests)
    Transfer rate:          244.25 [Kbytes/sec] received
    [/code]
    内存占用情况:

    测试前:23.3M。测试使用firefox 登录并访问地址 /openerp/form/view?model=sale.order&id=1 ,然后察看进程内存占用情况。
    [img]http://www.360yun.info/sites/default/files/netrpc_start.png[/img]
    测试后:27.3M。测试完成1000任务后,察看进程内存占用情况。
    [img]http://www.360yun.info/sites/default/files/oe_net_rpc.png[/img]
    测试过程中,观察内存上升情况,发现是随着测试任务完成情况而线性增长的。

          2、 async_netrpc_server 测试结果(点击下载测试文件)

    [code]
    $ ab -n 1000 -c 1000 -C session_id=9d82bf71745241afba1451f7fc8206e7a09a6e2d 'http://127.0.0.1:8080/openerp/form/view?model=sale.order&id=1'

    Server Software:        CherryPy/3.1.2
    Server Hostname:        127.0.0.1
    Server Port:            8080

    Document Path:          /openerp/form/view?model=sale.order&id=1
    Document Length:        92818 bytes

    Concurrency Level:      1000
    Time taken for tests:  365.387 seconds
    Complete requests:      1000
    Failed requests:        0
    Write errors:          0
    Total transferred:      93073000 bytes
    HTML transferred:      92818000 bytes
    Requests per second:    2.69 [#/sec] (mean)
    Time per request:      371386.709 [ms] (mean)
    Time per request:      371.387 [ms] (mean, across all concurrent requests)
    Transfer rate:          244.74 [Kbytes/sec] received

    [/code]


    内存占用情况:

    测试前:23.3M。测试使用firefox 登录并访问地址 /openerp/form/view?model=sale.order&id=1 ,然后察看进程内存占用情况。
    [img]http://www.360yun.info/sites/default/files/async_start.png[/img]

    测试后:23.8M。测试完成1000任务后,察看进程内存占用情况。
    [img]http://www.360yun.info/sites/default/files/async_net_rpc.png[/img]

    测试过程中观察,完成100任务后内存上升到23.8之后就一直停留在23.8,没有再增长。

    从以上的对比情况来看,处理时间基本上没有多大的差距,(372.131−365.387)÷365.387 =  %1.845 。但是从内存占用情况来看,async_netrpc_server 仅增长了0.5M,而官方的net-rpc server 则增长了4M ,显示出 8 倍的差距。


    结论

            通过以上的测试,async_netrpc_server 对比 官方的 net-rpc 模块,显示出一些性能的优势。

            1、第一种测试中的29%差距,应该仅是表明async_netrpc_server 异步非阻塞框架的优秀性能。而oe实际应用情况则比较复杂,涉及缓存、数据库读取等。所以,在第二种测试中,差距不到2%,也是正常情况。

            2、第二种测试中,内存占用情况有8倍的差距,这个表明线程池模型在面对高并发时很有可能成为系统瓶颈。官方的net-rpc server 使用的线程池模型频繁创建销毁对象,带来较大的性能开销,虽说python有垃圾回收机制,但问题是你不知道它什么时候回收。如果线程池销毁的对象一直没有被回收的话,那将是一场灾难。


    以上的测试,仅仅是本人在有限条件下进行的,并且受限于与本人知识水平,测试结果仅供各位参考。非常欢迎大家试用并测试async_netrpc_server模块。也欢迎大家和我讨论,我的联系方式在页面最下方。谢谢!

    本文转自本人博客 [url=http://www.360yun.info/blog/930063019.html]http://www.360yun.info/blog/930063019.html[/url],测试文件和程序请到本人博客下载。谢谢!



  •         async_netrpc_server 是使用tornado 的ioloop 实现的异步非阻塞的net-rpc socket server for openerp。此模块是由本人开发并维护,现已托管在google code 上(http://code.google.com/p/openerp-asynchronous-non-blocking-net-rpc-server/),在google code 上,我写了简单的安装方法,有兴趣的朋友可以下载并测试。此模块为开源项目,欢迎大家参与。

            为什么要开发这个模块? 因为Openerp 官方的net-rpc server 是采取select 轮询的的socket 线程池模式,在一般情况下是没有任何问题的,但是如果在高并发的密集请求下,这种模式就会显得比较落后了。而tornado 是由facebook 开发的高性能框架,其核心是使用linux 的epoll (mac / bsd 下用 kqueue)实现异步非阻塞的socket模型。当然,windows下还是使用select 轮询,但并不是说windows 就一点都没用,线程池模式需要频繁创建和销毁对象,这对系统资源来说是一个很大的开销,而异步非阻塞的模型避免了这个缺点。所以,我在看了OE的代码之后,就萌生了这个想法,并因此有了这个模块。

            那么,这个模块到底怎么样?是骡子是马,拉出来溜溜。。。我做了简单的测试,请看下面。

    软硬件环境

            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.3
            OpenERP web client:openerp-web-6.0.3
            CherryPY 版本:3.1.2

    相关参数设置

            Openerp Server:

            1、编辑 netrpc_server.py  修改 self.socket.listen(1024)。这个是官方的net-rpc server 的socket 等待队列,默认值是5,10个并发就挂了,所以必须修改。
            2、编辑openerp-server.conf 添加db_maxconn = 128。这个是数据库连接池,默认值是64。
            3、编辑openerp-server.conf,设置 xmlrpc = False 和 xmlrpcs = False,不启动http xmlrpc 服务 和 https xmlrpc服务。
            4、测试官方的net-rpc server 时,编辑 openerp-server.conf 中 netrpc = True  ,async_netrpc = False ,只启动官方的net-rpc server 。
            5、测试async_netrpc_server 时,编辑 openerp-server.conf 中 netrpc = False  ,async_netrpc = True ,只启动async_netrpc_serve。

            Opery Web Client:

            1、打开openerp-web.cfg,确认 server.environment = "development"(如果你是源码下载,这个就是默认值,无须修改)。
            2、测试官方的net-rpc server 时,编辑openerp-web.cfg 中 openerp.server.port = '8070' 。
            3、测试async_netrpc_server 时,编辑openerp-web.cfg 中 openerp.server.port = '8008' 。

            CherryPY:编辑_cpserver.py 修改 socket_queue_size = 500 和 thread_pool = 1024。详细的修改方式和说明,请参见拙文Openerp压力测试:Openerp到底能支撑多大的用户数?。
    测试过程

            一、使用本人编写oetest.py 测试 10000总任务100并发测试(程序请到拙文Openerp压力测试:多线程直连OE Server NET-RPC/XML-RPC端口测试下载)

            测试官方的net-rpc server 时,修改oetest.py 参数 PORT = '8070' 。测试async_netrpc_server 时,修改oetest.py 参数 PORT = '8008' 。

            1、 官方的net-rpc server 测试结果

    [code]
    $ ./oetest.py

    Start at 2011-08-25 20:58:17.636473
    End  at 2011-08-25 20:59:35.510676

    Total Time: 0:01:20.874203
    [/code]
    2、 async_netrpc_server 测试结果
    [code]
    $ ./oetest.py

    Start at 2011-08-25 20:53:15.829595
    End  at 2011-08-25 20:54:18.310178

    Total Time: 0:01:02.480583
    [/code]

            从上面的结果来看,官方的net-rpc server处理时间是 80.87秒,async_netrpc_server 的处理时间是 62.48。(80.87−62.48)÷62.48 = %29.43 也就是说 async_netrpc_server 大概比官方的net-rpc server快 29%左右。那么,实际情况是否有如此大的差距呢?下面我们用ab (ApacheBench)来模拟下实际情况。

            二、通过ab 测试/openerp/form/view?model=sale.order&id=1 地址,1000总任务1000并发。

            本次测试的框架是 ab -> OpenERP Web Client -> OpenERP Server

            1、 官方的net-rpc server 测试结果(点击下载测试文件)

    [code]
    $ ab -n 1000 -c 1000 -C session_id=16273c836063c55a73ff154f048884b450b76bed 'http://127.0.0.1:8080/openerp/form/view?model=sale.order&id=1'

    Server Software:        CherryPy/3.1.2
    Server Hostname:        127.0.0.1
    Server Port:            8080

    Document Path:          /openerp/form/view?model=sale.order&id=1
    Document Length:        92818 bytes

    Concurrency Level:      1000
    Time taken for tests:  372.131 seconds
    Complete requests:      1000
    Failed requests:        0
    Write errors:          0
    Total transferred:      93073000 bytes
    HTML transferred:      92818000 bytes
    Requests per second:    2.69 [#/sec] (mean)
    Time per request:      372131.152 [ms] (mean)
    Time per request:      372.131 [ms] (mean, across all concurrent requests)
    Transfer rate:          244.25 [Kbytes/sec] received
    [/code]
    内存占用情况:

    测试前:23.3M。测试使用firefox 登录并访问地址 /openerp/form/view?model=sale.order&id=1 ,然后察看进程内存占用情况。
    [img]http://www.360yun.info/sites/default/files/netrpc_start.png[/img]
    测试后:27.3M。测试完成1000任务后,察看进程内存占用情况。
    [img]http://www.360yun.info/sites/default/files/oe_net_rpc.png[/img]
    测试过程中,观察内存上升情况,发现是随着测试任务完成情况而线性增长的。

          2、 async_netrpc_server 测试结果(点击下载测试文件)

    [code]
    $ ab -n 1000 -c 1000 -C session_id=9d82bf71745241afba1451f7fc8206e7a09a6e2d 'http://127.0.0.1:8080/openerp/form/view?model=sale.order&id=1'

    Server Software:        CherryPy/3.1.2
    Server Hostname:        127.0.0.1
    Server Port:            8080

    Document Path:          /openerp/form/view?model=sale.order&id=1
    Document Length:        92818 bytes

    Concurrency Level:      1000
    Time taken for tests:  365.387 seconds
    Complete requests:      1000
    Failed requests:        0
    Write errors:          0
    Total transferred:      93073000 bytes
    HTML transferred:      92818000 bytes
    Requests per second:    2.69 [#/sec] (mean)
    Time per request:      371386.709 [ms] (mean)
    Time per request:      371.387 [ms] (mean, across all concurrent requests)
    Transfer rate:          244.74 [Kbytes/sec] received

    [/code]


    内存占用情况:

    测试前:23.3M。测试使用firefox 登录并访问地址 /openerp/form/view?model=sale.order&id=1 ,然后察看进程内存占用情况。
    [img]http://www.360yun.info/sites/default/files/async_start.png[/img]

    测试后:23.8M。测试完成1000任务后,察看进程内存占用情况。
    [img]http://www.360yun.info/sites/default/files/async_net_rpc.png[/img]

    测试过程中观察,完成100任务后内存上升到23.8之后就一直停留在23.8,没有再增长。

    从以上的对比情况来看,处理时间基本上没有多大的差距,(372.131−365.387)÷365.387 =  %1.845 。但是从内存占用情况来看,async_netrpc_server 仅增长了0.5M,而官方的net-rpc server 则增长了4M ,显示出 8 倍的差距。


    结论

            通过以上的测试,async_netrpc_server 对比 官方的 net-rpc 模块,显示出一些性能的优势。

            1、第一种测试中的29%差距,应该仅是表明async_netrpc_server 异步非阻塞框架的优秀性能。而oe实际应用情况则比较复杂,涉及缓存、数据库读取等。所以,在第二种测试中,差距不到2%,也是正常情况。

            2、第二种测试中,内存占用情况有8倍的差距,这个表明线程池模型在面对高并发时很有可能成为系统瓶颈。官方的net-rpc server 使用的线程池模型频繁创建销毁对象,带来较大的性能开销,虽说python有垃圾回收机制,但问题是你不知道它什么时候回收。如果线程池销毁的对象一直没有被回收的话,那将是一场灾难。


    以上的测试,仅仅是本人在有限条件下进行的,并且受限于与本人知识水平,测试结果仅供各位参考。非常欢迎大家试用并测试async_netrpc_server模块。也欢迎大家和我讨论,我的联系方式在页面最下方。谢谢!

    本文转自本人博客 [url=http://www.360yun.info/blog/930063019.html]http://www.360yun.info/blog/930063019.html[/url],测试文件和程序请到本人博客下载。谢谢!



  • 建议 把实现方法提交到OE官方... 射射....


  • 管理员

    兄弟技术精湛,才思敏捷,论述有理有据,行文流畅,图文并茂。
    读你的文章非常受启发,本人甚是佩服。希望能看到更多此类文章。


  • 管理员

    支持提到官方那里,LZ厉害,佩服佩服。



  • 谢谢shelly,谢谢Joshua

    关于提交到官方,个人感觉不是很靠谱啊。一是不知道怎么提交,还请各位指点。二是修改的有点大,而且还引入了tornado 这个第三方类库,关于神码license 的东西,够OE官方搞一阵子了。提交上去估计也是如沉入大海,无影无踪鸟。。。

    PS:校长啊,读你的每个字都是胆战心惊啊,有点大难临头的感觉,莫非你要开除我啊。。。。你肿么要这样对我?我到底做错鸟神马?你不要赶我出去啊。。。啊啊啊  8)



  • 这个强



  • 高手出现了


登录后回复
 

与 Odoo 中文社区 的连接断开,我们正在尝试重连,请耐心等待