标签：python 多核心 odoo multiprocess gevent threading
对于很多企业来说，随着时间的推移，用户量或者企业建点扩张，使用erp就会出现应用访问越来越慢的情况，其实这种情况不但限于erp，只要是有数据量增长的互联网业务必然会遇到的，因为一开始的是就没有做好大数据量的访问情况。
odoo erp是python开发的，python相对c、c++、java等在性能方面确实是低了很多，归根到底就是本来python就是c跟c++开发出来的语言，另外python让人诟病的全局解释器锁(GIL,Global Interpreter Lock)，想要更加了解GIL的话可以访问http://cenalulu.github.io/python/gil-in-python/?utm_source=tuicool&utm_medium=referral
有一段时间在公司，openerp已经开发好了，并且让个别企业在使用了，当然这个过程有某些企业已经反映运行慢了，这期间也做了很多测试，发现确实openerp在运行过程中发挥不了多核心的情况，基本上都是cpu一个核心100%的情况就卡死了，但是还有起码好多个核心的资源没有用到啊？难道就这样废了吗？后面也尝试用nginx做转发，还是发现一个核心100%的情况。
后面自己也尝试用java写了个多线程网络通信的程序，用了循环不断拉去服务端的线程，再去观察一下cpu的情况，惊喜发现cpu真心可以多核利用到了啊，难道说后面要用java开发新的业务程序吗？
尽管只是java比python在性能上面确实要快，但是还是抱着了解的心态开始了python的多进程、多线程的测试：
python多进程(用了一个死循环来测试)：
#!/bin/python
from multiprocessing import Process
def MulProcess():
while 1:
pass
if __name__ == ‘__main__‘:
t1 = Process(target=MulProcess)
t2 = Process(target=MulProcess)
t3 = Process(target=MulProcess)
t4 = Process(target=MulProcess)
t1.start()
t2.start()
t3.start()
t4.start()
t1.join()
t2.join()
t3.join()
t4.join()
代码建立了4个进程，然后一直循环，上图看到的4个cpu都利用到了，其实说白了python其实是可以用到多核心的
python多线程:
#!/bin/python
from threading import Thread
def ThreadProcess():
while True:
pass
if __name__ == ‘__main__‘:
t1 = Thread(target=ThreadProcess)
t1.start()
t2 = Thread(target=ThreadProcess)
t2.start()
t3 = Thread(target=ThreadProcess)
t3.start()
t4 = Thread(target=ThreadProcess)
t4.start()
t5 = Thread(target=ThreadProcess)
t5.start()
t6 = Thread(target=ThreadProcess)
t6.start()
t1.join()
t2.join()
t3.join()
t4.join()
t5.join()
t6.join()
多线程的代码建立6个线程，其实超过了4核心了，但是这样没问题，总共4核心超过了照样跑，上图的cpu显示基本都用到了4核心了，但是建议不要用多线程，为什么？1.多线程不同多进程，多线程的数据在不同线程中都是可以共享的，cpu的资源分享可不想你想的那样，在多线程跑的时候是那个空闲跑哪个，很容易出现数据乱的情况( 如果有修改数据的情况下)，2.当然多线程还是可以保证数据的统一的，只是要加上一个threading.Lock(),那就是要加上锁，想运行的时候必须先获取lock锁，请问这本质不是把多线程的快速处理性能降低了吗？真是然并卵啊。关于进程，不多说，如果不是变态的业务程序需要到进程间数据访问的话，基本上进程都是独立运行的，但是系统在建立一个进程跟建立一个线程的资源耗费是不同的，明显进程相对线程大得多。果然这个世界上什么鱼与熊掌不可兼得的事情还是少之又少啊。
好了，到此为止，基本上对python的多线程、多进程的情况有了个比较客观了解了。下面还是要测试一下openerp在多核心利用情况。
其实新版的odoo8、9都是支持gevent、multiprocess、threading的运行方式，测试只是用了gevent跟multiprocess的情况，至于threading就不要去测试了，除非用的是单核心的cpu。笔者用的是openerp 7跟odoo 8去做测试，这里主要说odoo 8，odoo 8 的环境是centos7,直接用odoo rep文件,yum install的，我比较懒，当然可以用source的方式，这就不详细介绍，不懂看官网去。yum安装的好处是基本上缺少什么依赖都给你安装好了。
一、先测试multiprocess的事况测试之前直接修改配置文件/etc/odoo/openerp-server.conf,设置workers = 4(我是4核心的虚拟机)，这里说一下设置workers的情况，如果设置workers = 0的话就只有一个odoo的进程，如果workers =1就立刻变成了4个进程，还有出现一个openerp-gevent进程，这个最要是用odoo聊天客户而用的，有安装了gevent的情况下面就会出现,当然可以在openerp-server.conf配置文件里面去掉，所以除掉这个进程理论上是workers =1的时候拉起了3个进程，然后workers =2 就是5个进程以此类推推算 ，启动systemctl start odoo.service,首先用最原始的方式，打开url按住F5不停刷新，一边观察，后面还用了./webbench -c 1000 -t 10 http://192.168.1.125/ 去测试
：
果然都用到4核心了，也验证了python多进程的多核心利用
二、接下来测试gevent，gevent是python个一个异步并发框架，跟tornado有点相识，但是用是的协程的概念，如果有时间找gevent源码看看，不过我这里主要是模仿多进程的，想法：4核心的虚拟机，开启4个openerp-gevent的进程，通过不同的端口来访问，但是我了统一80端口访问，就用了nginx来作为前端转发，同时也测试一下nginx的多核心使用情况，当然nginx本身也是异步的，后面测试完了不得不承认加了nginx在访问上面真心比没加好很多，这里贴上nginx的部分配置：
XXXXXXXXXXXXXXX # 很多没有贴出来
worker_processes 4;
worker_cpu_affinity 0001 0010 0100 1000;
events {
use epoll;
worker_connections 65563;
}
XXXXXXXXXXXXXXX # 很多没有贴出来
server {
listen 80 default_server;
listen [::]:80 default_server;
server_name _;
root /usr/share/nginx/html
location / {
proxy_pass http://openerp;
}
XXXXXXXXXXXXXXX
upstream openerp{
server 192.168.1.125:8072;
server 192.168.1.125:8073;
server 192.168.1.125:8074;
server 192.168.1.125:8075;
}
XXXXXXXXXXXXXXXXX
启动四个/usr/bin/openerp-gevent -c openerp-server.conf
/usr/bin/openerp-gevent -c openerp-server8073.conf
/usr/bin/openerp-gevent -c openerp-server8074.conf
/usr/bin/openerp-gevent -c openerp-server8075.conf
启动nginx : systemctl start nginx.serivce
查看端口：
ok，测试：./webbench -c 1000 -t 30 http://192.168.1.125/
1000并发 ，持续30秒
结论：python可以利用多进程的情况实现多核心利用，java在性能方面确实比python要好，但是python开发速度相对快，odoo其实也可以实现多核心利用情况，估计性能会上一个台阶，另外nginx的多核心利用只能支持到8核心(网上说的，懒得去测试)。
本文出自 “fengyunsen” 博客，请务必保留此出处http://samfeng.blog.51cto.com/52272/1764852
标签：python 多核心 odoo multiprocess gevent threading
原文地址：http://samfeng.blog.51cto.com/52272/1764852
