免费开源ERP openerp与gunicorn整合方案.pdfVIP

Deploying OpenERP Server with Gunicorn Vo Minh Thu, OpenERP s.a. (@noteed) April 11, 2012 Overview We wanted to achieve: ➲ Better performance on multi-core machines ➲ Better stability (CPU and memory consumption monitoring, less interference between a misbehaving request and other requests) ➲ Simplify our code base uses the new setup for some times now, and it really proves useful. Overview (contd) The puzzle pieces: ➲ Multi-threading and the GIL ➲ Stateless processes ➲ OpenERP is WSGI compliant (since 6.1) ➲ Gunicorn is a WSGI compliant HTTP server (with some nice features) Multi-threading and the GI In CPython, the Global Interpreter Lock (GIL for short) prevents multi- ple OS threads from executing Python bytecode at the same time. This is also true on multi-core systems. To take advantage of multiple cores, a solution is to use multiple pro- cesses instead of threads (e.g. with the standard multiprocessing library). To have multiple instances of the OpenERP server talk to the same database, we have to make the server stateless. See e.g. the Python wiki /moin/GlobalInterpreterLock or Understanding the GIL at /GIL/. State Prior to v6.1, OpenERP server was not stateless (it is still not striclty stateless but thats ok). osv_memory Model registry (installing a new module updates the registry) @tools.ormcache Various other caches and other hidden places (e.g. Float fields digits_compute implementation) We treat the last point as caches too. State (contd) - osv_memory osv_memory are now implemented as regular osv objects (now called TransientModel and Model respectively). TransientModel are simply deleted from the database automatically af- ter some time, or after a numerical limit (just as osv_memory were re- moved from memory in the same way). For instance, a wizard can be initiated on one process, and the next re