Perl CGI的性能

Perl CGI可能在開發網站的初期是一種常用方式。但在實際使用后采用Perl CGI，性能問題就開始變得很明顯。這種情況在原型應用程序應用在實際環境中經常碰到，表現為較慢的響應速度、不尋常的行為和系統失敗等。在一個站點遭遇Perl CGI腳本產生的性能問題之后，不可能再次允許其出現在實際環境中。

Perl CGI在測試一個Web程序的初期工作很好，但隨著站點使用得越來越多，應用程序負載也更大，CGI進程產生越來越多的開銷，并最終超過服務器的能力。處理器過載，內存被占滿，數據庫沒有可用連接，系統將比預期地更早終止。

Perl 的隨機編譯器在這里是一個最大缺陷，執行Perl CGI進程時CPU的許多負載都來源于編譯和初始化程序。最明顯的結論是Perl相對當前任務響應太慢了，當然不會有任何公司會鼓吹Perl CGI的速度，在實際使用中，經過優化的Perl程序的例子更少。

一次性任務

Perl CGI進程在原型測試環境下工作得很好，這時通常每次只有一個用戶訪問Web應用程序，并且所有界面延遲時間只是由于用戶請求的處理引起的。這與Perl程序在Web處理之外的其他情況下的使用方式很類似，所以，那些情況的假設在此都成立，也就是每次只有一個請求，在請求完成后，程序和數據就不再需要了。

這些假定在演示原型時也是正確的。這時演示者是訪問系統的唯一用戶，通常處理過程產生的延遲很小并且也被解釋過程給掩蓋了。結果，CGI進程響應的緩慢性不可能在演示或可用性測試階段覺察出來。即使單一用戶注意到運行緩慢，也可能注重其他考慮而被忽視。

把原型投入實際使用就會截然不同。關于一個用戶、很少的請求和沒有對資源競爭的假設不再成立，應用程序的負載會按指數規律增長，這是由于Web請求的性質，他們不像單一用戶應用程序中那樣在同意時刻輸入，也不像大多數用戶應用程序（如數據庫或群件）那樣固定在一定范圍之內。Web請求可能同時輸入，并且數量可能不斷增加，而不采取定單處理過程中排隊請求那樣簡單的方式。相反，要求Web服務器存在和請求一樣多的進程，附加進程的負載似的現有進程更加緩慢，因此，在處理以前進程的時候，會有更多的進程輸入進來。在有限負載下，這種情況很容易失控，從而導致所有的Perl CGI進程阻塞停止，在處理過程中的所有請求都失敗了。

Perl進程的內存痕跡

一個Perl CGI進程可能占用1MB到15MB的RAM空間。占用這些內存的進程如果單獨處理很容易管理，甚至不能使最一般的Web服務器崩潰。然而，CGI進程處理過程中使用的Perl編譯器可能是靜態鏈接而不是動態鏈接，導致一個不在進程間共鄉的Perl解釋器。如果許多CGI進程在同時運行，Perl解釋器就可能復制無數次，將占用更多的內存開銷。

如果新進程在舊進程沒結束之前就開始了，新進程會站用更多的系統內存。隨著站點的經常光顧的訪問者的增多，將會產生更多的覆蓋和系統資源的更大消耗。例如，如果一個站點的一個CGI應用程序每秒接到20個請求，那么最少需要2秒鐘來處理，可能要40個CGI進程不停地開始和結束，這樣會占用500M的RAM空間，隨著請求率的增加，對一個實際的Web應用程序來說，100個請求每秒仍是一個非常保守的數字，內存請求增加不是只簡單相加，而是呈幾何基數地增加。每個進程通過增加CPU負載從而減慢其他進程，但這樣又會增加必須的進程數，并且會惡性循環下去。這樣即使用最昂貴的Web服務器，可用RAM的限制也將很快突破。

當可用RAM被CGI進程需求超過后，大多數服務器開始使用磁盤上的交換空間來為進程產生虛擬內存。這時，進程開始明顯變得緩慢，處理一個進程的時間成10倍地增加，同時，活動進程的數量也同樣增加了。進程總負載一旦超過系統的極限，所有進程都會終止。同樣，請求失敗，連接的系統可能會處在不確定的狀態下，并產色懷念感不尋常的行為和管理上的混亂。

　

編譯的費用

Perl CGI的大部分開銷來自于編譯成字節碼和初始化程序數據。每個Perl程序在執行前都要經過編譯，每個程序（不管采用什么語言）都需要出事內存結構和運行時系統庫函數。編譯過程對任何在系統環境中不許要解釋器就運行的程序都是必須的。

編譯過程在運行一個單用戶程序時很少能看得到，如 C 程序，編譯過程需要幾分鐘甚至幾小時。編譯步驟也是檢查系統相關錯誤的時候，所以如果第一個編譯步驟沒成功，就需要更多的調試，也就需要更多的時間。因此，編譯過程通常在程序提交給用戶之前就已完成了。即使開放源代碼程序通常也只在目標系統上第一次安裝時編譯一次。

而Perl程序要在執行前進行編譯，這使Perl程序可以更迅速地對系統環境變化做出響應，也比編譯過的執行程序更容易跨平臺移植。Perl runtime在幾秒（或幾毫秒）內編譯每個程序，包括所有庫函數和核心程序。Perl程序開始時同時開始編譯和執行步驟，這就給人Perl是解釋不是編譯的印象。而Perl runtime（有時叫Perl解釋器）需要在編譯和執行每個程序時激活，這種印象也就更深了。

對有些Perl程序，編譯時間不止幾秒鐘。程序更大時更是如此，因此要添加大量的模塊到程序中。初始變量、系統連接和更大的數據結構都可能增加系統初始階段的時間開銷。例如，把較大的XML文檔分析Perl數據結構，可能會占用相當的時間，這些額外的編譯和初始時間造成了PerlCGI使用范圍的限制，因為更復雜的過程可能會包含不允許的性能損失。

除了大多數集中處理器操作的Perl程序，編譯一個Perl程序會比簡單執行編譯過程的程序占用更多的CPU時間，因為編譯程序需要于Perl語言本身同樣的文本操作、系統集成和磁盤輸入/輸出，但更復雜一些。實際在大多數情況下，一個Perl CGI進程占用比相同的經過預編譯的程序多20倍的CPU處理器時間。

小結

　

建立Web應用程序的原型是Perl的用武之地，許多Perl程序開始是作為Perl原型的。Perl的靈活性和強大的系統集成模塊使原型設計和實施特別容易。Perl CGI的性能在短時間內受到挫折，并且Perl CGI進程占用更多內存和CPU時間，最后可能使系統過載，完全終止Web服務器進程。這主要是由于Perl進程的實時編譯的開銷引起的，雖然是一、兩秒鐘，但這比程序本身還需要更多的處理能力。