眼看巨浪來襲，生還的惟一希望是相信直覺，這樣才能安然度過災難。當處理令人頭疼的應用程序響應時間時，具有數百名終端用戶的企業或許會發現自身正處于上文所述的類似境況。應用程序部署以后隨時可能會出現用戶不滿浪潮，特別是在您對自身的基礎架構不自信
眼看巨浪來襲，生還的惟一希望是相信直覺，這樣才能安然度過災難。當處理令人頭疼的應用程序響應時間時，具有數百名終端用戶的企業或許會發現自身正處于上文所述的類似境況。應用程序部署以后隨時可能會出現用戶不滿，特別是在您對自身的基礎架構不自信，并且部署前沒有花時間運行相關壓力測試的情況下。
近期的趨勢和技術文章1 表明，如果企業選擇關系管理系統 (RDBMS) 但卻不了解 RDBMS 如何或者是否能夠正常升級，隨著用戶負載的不斷增加問題可能會接踵而至。然而，許多軟件編輯器（包括 Cisco Systems 和 SugarCRM）現已考慮向自身支持的平臺添加 IBM? Informix?，因為其他 RDBMS 編輯器已無法提供足夠的性能和穩定性。如今在技術論壇中，有關將各種 RDBMS 實施項目遷移至 Informix 的相關問題出現得越來越頻繁。
運行 IBM Informix 的企業發現產品升級行之有效，但事實上還有一些用戶從未留意過飽受壓力的 Informix 的 CPU 消耗量，近年來也未發布過真實的統計數據。為什么不呢？是由于競爭對手要“埋沒”Informix、缺乏與競爭對手產品的實際性能對比數據，還是普遍而言的市場冷漠性？答案無關緊要；重要的是要確定基礎版本的 IBM Informix 的每個聯機事務處理 (OLTP) 應用程序平均能夠承受多少個終端會話。
事務處理性能 (TPC) 委員會負責發布 DBMS 基準評估的規范、場景和結果。該機構會遵循“盡可能貼近現實生活”的準則，制定不同類型的 DBMS 基準以設置等級。
當前的 TPC 基準包括 TPC-C、TPC-E 和 TPC-H，但 TPC-C 是最具代表性的 OLTP 活動基準。雖然用戶可以在 Internet 上找到大量開源 TPC-C 運行程序，但其中絕大部分均以 Java 語言編寫。下列測試采用的運行程序由西班牙巴利亞多利德大學團隊開發、由 Diego Llanos 教授負責管理，用來與 IBM Informix 執行運行對比測試。
測試目標
由于未采用 TPC 委員會頒發的正式 TPC-C 副本且未獲 TPC 委員會批準，因此這項測試不能作為 TPC-C 官方基準。然而，測試過程中嚴格遵循 TPC-C 基準制定的所有規則。基本上，這項操作已對 Informix Innovator-C 運行壓力測試，以便指出單一 Informix 服務器上能夠同時運行多少個終端會話（即事務監視器中運行的 TPC-C 用戶會話）。
預備步驟與選定配置
首先使用源代碼啟動操作，只需很少成本。以下是基準測試的必要準備步驟：
1) 依據以下規格安裝基于 linux 的服務器（Fedora 14，內核 2.6.35.14 x86_64）：
? 單插座 Intel 四核 Q9400（四個 2.66 Ghz 處理器）
? 16 Gb DDR-2 RAM
? 四個 500 Gb SATA II，7,200 rpm 磁盤驅動器
請注意，上述配置成本低于 900 歐元。
2) 在 Linux 服務器上安裝和配置 IBM Informix Innovator-C Edition。
Innovator-C Edition 是免費的，所以沒有成本。所選的版本是 11.70 FC4。
3) 采用巴利亞多利德大學推出的 TPC-C 應用程序（最初在 PostgreSQL ESQL/C 開發）以運行 IBM Informix。這項任務相對輕松，因為根據 Informix 服務器機制調整對 PostgreSQL 進行修改是整個任務的主要修改。此外，最初的數據庫創建語句已經過優化，以便充分利用 RAW 表和預處理語句。同樣，這項基準測試不會測量數據庫加載語句，因此加載時間越短越好。
4) 編譯和調試應用程序。
5) 優化 Informix。
6) 運行測試，逐漸增加壓力直到出現系統性能下降。嚴格遵循 TPC-C 規則，確保測試通過。
基準規則
即使是開展非官方測試，也必須遵循以下規則：
? 不要修改數據庫模式。TPC-C 數據庫包含九個表，每個表均包含預定義結構、經過確認的索引和完整性約束。不得修改、添加或刪除其中任何元素。
? 不要修改表的基數。表基數均存在嚴格的規則限定；例如，一個倉庫將托管 100,000 個項目，一個區將包含 3,000 名客戶等。
? 不要修改事務的應用程序代碼。TPC-C 采用五個不同的事務，旨在反映典型 OLTP 應用程序的運行狀況：新訂單、付款、交貨、訂單狀態和庫存水平。最后一項指標包含非索引列的查詢數量（不同的）和 WHERE 子句，因此需要施加少許壓力放置數據庫引擎。
? 各事務類均規定了最大允許響應時間。對于各事務類，至少有 90% 的事務必須按照如下方法執行。如果出現負值，則測試失敗。
? 各項測試均包含等候（或預熱）時間和測量時間（性能測量間隔）。等候時間有助于服務器適應不斷增長的負載，這樣即可在性能穩定時過渡至測量時間。
? 檢查點間隔沒有制定確切的規則，只是規定測量時期內必須至少測試一個檢查點。這在使用 Informix Innovator-C 時根本無關緊要，因為檢查點僅會阻止極少量的事務。本測試采用 15 分鐘間隔，現實系統也是采用這一間隔。
? 磁盤實施也沒有任何規則。同一 SATA 控制器上的全部四個 SATA II 7,200 rpm 磁盤全部得到應用，從而盡量準確地平衡各表和索引的位置。
? 同一臺計算機上的所有 Informix Innovator-C 實例共享內存量均限制在 2 Gb。此項測試完全使用這 2 Gb，同時還要預留 SHMVIRTSIZE 空間，以便執行排序及類似操作。
