在因特網上，競爭的勝負常常在於 “一瞬” 之差。返回信息時的延遲就意味著丟失業務。因此，在開始設計應用程序時，就要考慮到性能問題。
在檢查客戶的應用程序和基礎結構時，我發現的最常見的問題是為分布式 Java 應用程序提供服務的連接、內存或計算能力的效率很低。在面向服務環境中，進程分布在許多本地和遠程服務器上。對一位客戶的 Java 應用程序的分析表明，這個應用程序必須連接七個不同的服務器才能完成關鍵的事務。其中一些服務器已經達到 100% 利用率，所以這個應用程序不得不等待連接。因此，應用程序常常產生不可預測的事務結果。當然，通常認為這是數據庫惹的禍；但是，在這種情況下，糟糕的性能不是數據庫導致的，而是另有出因。
當我查看分布式服務器的統計數據、監視報告和錯誤日志時，卻發現為了節省資源，監視功能已經被關閉了。打開監視之後，又難以通過服務器-服務器路由跟蹤事務 “服務” 和協調日志上不同的時區時間戳。
在某些服務中，沒有進行 SQL 錯誤碼檢查。所以，無論數據庫 SQL 是否成功，服務都不報告錯誤。因為服務不處理來自 SQL 的錯誤，數據庫也沒有在表結構中定義引用完整性關系，所以這個事務和數據庫完整性問題導致了錯誤的數據。
一種有問題的 Java 應用程序編程方法是把整個 SQL 結果集都放到內存或持久化層中，這個問題在對象關系映射、Hibernate 或 iBathis 應用程序體系結構中很常見，應該在應用程序測試階段加以糾正。這種做法在測試環境中常常效果良好，因為在測試環境中數據庫只包含數百或數千個記錄。當把應用程序轉移到生產環境時，它可能需要從數據庫獲取數百萬個記錄，這會導致大量占用內存或應用程序停止運行，而且不報告錯誤。為了避免這個問題，程序員必須學會如何使用 FETCH FIRST xx ROWS SQL 游標語句。
Web 工作負載高峰常常比平均事務速率高 5 到 10 倍，所以會很快達到容量限制。為了避免容量風險，在開始應用程序項目時，應該問自己四個簡單的問題：
應用程序要處理多少個 SOA 事務？應該做出這樣的回答：“我們預期每天有 500 萬個事務，包括 100 萬次更新、200 萬次插入和 1500-2000 萬次頁面查看。” 應該在獲得足夠信息之後，再做出回答。
服務器的硬件組件是什麼？回答應該包含 CPU/核的數量、CPU 的速度、服務器涉及的內存分配以及網絡連接的數量和速度。
使用哪些監視設施？在項目開始時就要獲得性能報告，從而了解 CPU 負載統計數據和當前的網絡通信量數據。
涉及哪些服務、服務器和數據庫應用程序 DB2 包？因為 Java 應用程序通常使用動態的 JDBC SQL，所以很難跟蹤應用程序的執行。應該向架構師和應用程序程序員索取應用程序執行圖。了解哪些服務或進程可以調用哪些其他服務。當有人在夜裡叫醒您詢問 “數據庫問題” 時，可以用這些服務調用信息幫助解決問題。
准備好適當的基礎結構和監視信息。請記住，“數據庫問題” 會導致用戶離開。在 IDUG 會議（包括本月在 Dallas 舉行的會議）和 IDUG.org 上可以找到更多性能提示。
