Odoo平臺簡介

Odoo（以前叫OpenERP）是世界排名第一的開源ERP系統，最早由比利時一家公司開發，經過十幾年發展，目前全世界Odoo的使用者超過2百萬人，Odoo被翻譯成幾十種語言，Odoo社群活躍的開發人員超過5000人。從2012年開始，美國著名IT雜誌Info World連續5年評選Odoo為“世界最佳開源軟體大獎” ERP領域第一名。

Odoo的底層結構很強大，所有模組都可以根據需要自行安裝和御載，所以使用者能像搭積木一樣建構自己期望的系統。即使完全不安裝與ERP相關的模組，僅利用 Odoo 自身的底層框架，也能構建出適合各種用途的系統。Odoo是B/S架構，後端基於Python開發，前端基於HTML5和Javascript技術開發，所有功能和操作介面都能在手機上使用，支援手機自適應。

Odoo系統功能繁多，包含幾千個功能模組，如銷售、採購、庫存、財務、生產、專案管理、CRM、門店零售（POS）、人力資源、車輛管理、午餐管理等等。從8.0開始，Odoo大量增加了電子商務、網際網路方面的支援，包括電商模組eCommerce, 企業建站系統CMS，和郵件整合的企業及時訊息IM。Odoo不再侷限於ERP範疇，因而改名為Odoo。Odoo 8.0中，除了增加網際網路功能，另一個大改善是重寫了倉庫管理模組(WMS)，極大提升了WMS的功能和效能。Odoo 9.0中，重寫了會計模組，極大增強了會計報表功能，並簡化了會計操作。Odoo 10.0中，重寫了生產管理功能，增強了MRP功能，簡化了MRP操作，同時增加了PLM、QC等功能模組。

傳統商業ERP按模組、按使用者銷售，對於發展迅速的客戶，會受到很大的制約。使用者購買之後，如要定製適合自身的需求，會受到非常多的限制。官方系統升級後，使用者如要升級則需要再次花錢。如果不升級，按一般系統發展規律，5-7年將不再適應公司發展要求，又要重新尋找合適的系統。Odoo則非常開放，所有模組都免費下載，沒有使用者數限制，模組可以任意安裝、解除安裝和升級。

報告目標

Odoo作為世界排名第一的開源ERP系統，目前發展勢頭很快，軟體功能不斷改善，版本更新很快。筆者最近5年一直在研究這個軟體，陸續實施過一些案例，有成功的，也有不太成功的。這些年，筆者一直在想，這個軟體到底能做什麼，不能做什麼，適合做什麼，不適合做什麼？

由於是開源軟體，軟體背後沒有一個強有力的商業推廣公司，甚至連成體系的推廣文件都沒有。加之軟體功能在快速發展，這幾個問題不是三言兩語能講清楚的。因而一直找不到足夠權威的人來幫忙解答這些問題。

為了解決自己的疑惑，同時也將我們這些年的研究經驗釋出出來，給有ERP需求的各位多一個參考選擇。

Odoo效能測試報告

測試目的

1) 在XD公司給定的硬體環境，網路環境狀況，多併發使用者情況下，測試Odoo系統的響應速度；

2) 根據測試結果，判斷Odoo是否可以滿足XD公司的效能要求。

測試背景

1) XD公司現行CRM系統響應速度慢，各地分公司業務員抱怨較大；

2) XD公司全國各地分公司有35家，代理公司有25家。分佈於各地分公司及代理公司的業務員約700名，預計3年內人數將達到1500人；

3) 在XD公司給定的硬體環境，網路環境下，基於Odoo的新系統能否滿足XD公司現在及將來發展後的效能要求。

測試範圍

本次測試在XD公司總部辦公室進行，主要測試伺服器的效能（包括Odoo伺服器和PostgreSQL資料庫伺服器），不測試網路狀況，不測試客戶機的狀況，不測試各地分公司的訪問狀況。

測試環境

【客戶機】

聯想膝上型電腦，i5雙核CPU，8G記憶體，SSD硬碟。

【Odoo伺服器】

XD公司虛擬機器，12核CPU，16G記憶體

【Odoo資料庫伺服器】

XD公司虛擬機器，12核CPU，16G記憶體

【網路環境】

XD公司總部區域網，客戶機和伺服器間網路狀況極好。

測試需求、內容、工具及方法

測試需求

本次測試需求是：

1) 測試XD公司700多名系統使用者（員工），高峰期200名使用者同時登入系統的情況下，Odoo系統的響應速度能否達到XD公司的要求。

2) 本次測試在XD公司總部辦公室進行，主要測試系統軟體及伺服器的效能，不考慮異地網路延遲問題。

併發數估算

根據統計規律，軟體系統的併發使用者數（同時作業系統的使用者數）的估算公式如下：

（1） 平均併發使用者數： C = n * L/T

（2） 併發使用者數峰值： C’ ≈ C + 3 * C的平方根

公式（1）中，C是平均的併發使用者數；n是登入使用者（線上使用者）的數量；L是登入使用者的平均線上時間，T指考察的時間段長度。

公式（2）則給出了併發使用者數峰值的計算方式中，其中，C’指併發使用者數的峰值，C就是公式（1）中得到的平均的併發使用者數。該公式假設使用者行為符合泊松分佈規律。

XD公司的使用者情況如下：

1) 總使用者數是800，實測高峰線上使用者數200;

2) 大部分使用者（超過500）是銷售業務員，系統登入時間較短，平均每天在1小時以下，銷管和財務人員登入時間較長，平均每天估算為4小時；

3) 所有使用者的每天的平均登入時間估算為2小時；

4) 使用者只在上班時間使用系統，因而考察時間段為上班時間，8小時。

XD公司的併發使用者數估算如下：

平均併發使用者數 C = n * L/T = 200 * 2/8 = 50

併發使用者數峰值 C’ = C + 3 * C的平方根 = 50 + 3 * 7 = 71

使用者響應時間標準

軟體系統的使用者響應時間，業界有一個普遍的標準，即2/5/10原則。也就是說，使用者一次操作，如果系統在2秒之內響應，使用者會認為是“非常有吸引力”的使用者體驗；如果在5秒之內響應，會認為“比較不錯”的使用者體驗；如果在10秒內響應，會被認為“糟糕”的使用者體驗；如果超過10秒還沒有得到響應，那麼大多數使用者會認為這次請求是失敗的。

測試內容

本次測試根據XD公司的業務特點，測試了五個代表性操作：

1) 客戶查詢，輸入關鍵字，查詢客戶，測試系統響應時間；

2) 新建銷售合同，輸入客戶、課程等資訊，點選儲存，測試系統響應時間；

3) 客戶打款單列表，點選“客戶打款單”選單，系統顯示打款單一覽，測試響應時間；

4) 開啟打款單，隨機點選一覽中的一條客戶打款單，測試系統響應時間；

5) 打款單稽核，點選打款單稽核按鈕，測試系統響應時間。

為了分析不同併發使用者數情況下，系統的響應速度的變化，本次測試將依次測試1併發，50併發，100併發，150併發，200併發情況下，上述五個操作的響應時間。

經調查，XD公司現在的CRM系統有客戶69080個，客戶合同4060條，打款單17890條。本次測試系統匯入了XD公司6萬多條客戶資訊，建立了2萬多個模擬客戶合同。

測試工具

主要測試工具為JMeter 測試軟體，JMeter是一款廣泛應用的Web系統性能測試工具。JMeter是開源軟體，JMeter的詳細介紹及下載連結參考： http://jmeter.apache.org/ 。

本次測試的輔助工具還有FireFox瀏覽器，Firebug瀏覽器外掛，Excel電子表格。

JMeter可以模擬多使用者併發向伺服器傳送請求，並記錄每個請求，伺服器的響應時間。不過，由於Odoo系統大量使用Ajax連線，每個頁面都會同時發出多個請求（根據頁面複雜度不同，少的2個請求，多的有20個請求），JMeter記錄的單個請求的響應時間並不能反映整個頁面的響應時間。

為了獲得整頁面的響應時間，測試中用JMeter模擬併發使用者操作，再通過瀏覽器訪問系統，用Firebug記錄整頁面響應時間。

測試方法

本次測試採用的方法步驟說明如下：

1) 先用JMeter錄製客戶查詢、新建銷售合同、客戶打款單列表、開啟打款單、打款單稽核五個動作動作；

2) 修改錄製的指令碼，主要是將session_id替換成變數；

3) 用JMeter模擬多使用者同時執行上述操作；

4) 同時用Firefox瀏覽器手工操作客戶查詢、新建銷售合同、客戶打款單列表、開啟打款單、打款單稽核五個動作，用Firebug檢視系統響應結果及時間；

5) 依次測試1使用者、50併發、100併發、150併發、200併發情況下系統響應時間。

JMeter模擬使用者向伺服器發出請求，擷取伺服器的響應資料，響應時間等引數。JMeter可以開啟多執行緒，模擬多個併發使用者作業系統的情況。JMeter測試截圖如下：

Firebug會記錄頁面上所有的Ajax的響應時間，及整個頁面的響應時間。Ajax記錄的系統響應包括三個時間：連線建立時間、伺服器響應時間、伺服器響應結果傳輸時間。

在網路狀況良好的情況下，連線建立時間、伺服器響應結果傳輸時間幾乎沒有。下圖是在網路狀況較差情況下，開啟銷售合同時候，Firebug記錄的頁面響應時間。這個截圖說明了：

1) 開啟銷售合同頁面，系統發起了10個Ajax呼叫；

2) 每個Ajax呼叫包括連線建立時間（灰色），伺服器響應時間（紫色），結果傳輸時間（綠色）；

3) 兩個Ajax呼叫之間的間隔時間是本地Java script執行時間；

4) 同一頁面的Ajax呼叫存在併發呼叫（同時呼叫）的情況；

5) 包括所有Ajax的呼叫時間，本地Java script的執行時間，整頁面的響應時間是1.49秒；

測試結果及分析

系統性能測試結果

併發數為1, 50, 100, 150, 200情況下，客戶查詢、新建銷售合同、客戶打款單列表、開啟打款單、打款單稽核五個操作的系統響應時間如下：

系統負載情況

當併發使用者數從1逐步增加到300時候，Odoo伺服器的CPU使用率逐步上升。下圖記錄的是，測試工具JMeter從16:40測試開始，每3秒鐘增加一個併發測試使用者，至16:55，併發使用者達到300個，伺服器的CPU使用率情況。

從圖中可以看到，300併發使用者時候，CPU使用率約36%。

測試結果分析

1) 從測試結果來看，1個併發使用者和50個併發使用者，系統響應速度幾乎沒有變化，五個操作的響應時間都在2秒上下；

2) 100併發使用者時候，系統響應速度略有下降，響應速度在2秒至2.5秒之間；

3) 從100併發到200併發，系統響應速度略有波動，但都在2秒至3秒之間；

4) 以目前XD公司的使用者數800，連線使用者數200，平均併發使用者數50，峰值併發使用者數71的情況下，系統常見操作的響應時間在2.5秒以下；

5) 考慮到將來的發展，如果員工總數翻一倍，使用者數1600，連線使用者數400，平均併發使用者數100，峰值併發使用者數達到142人，系統常見操作的響應時間在3秒以內；

6) XD公司各分公司訪問系統時候，考慮到異地網路延遲問題，正常情況下，系統響應時間在4秒內（考慮增加1秒的網路延遲）。根據使用者響應時間標準，這個響應時間屬於“比較不錯”的使用者體驗（5秒以內）。

關於開源智造（OSCG）

開源智造專注於通過開源技術為企業資訊化服務的專業諮詢與技術支援的團隊，公司核心團隊成員均來自各類開源社群的大咖，有著濃厚的開源技術背景和實際客戶方業務架構設計能力，公司連續三年獲得Odoo官方全球核心夥伴榮譽，Odoo亞太區金牌服務機構，擁有8年行業經驗。為廣大中小型企業提供開源自主可控的垂直深度行業資訊化服務。

我們尤其精於新零售行業ERP，國際外貿行業ERP，智慧生產行業ERP，全網互聯CRM整合解決方案。

文章編輯：開源智造(OSCG) - 源自歐洲，業界領先的免費開源ERP專業服務商