PHP或Vanilla Perl CGI更快嗎？

Question

我正在為Apache共享托管服務器開發Web應用程序。 我已經在Perl中編寫了一些代碼，但是最近我發現，令我驚訝的是，共享主機提供商沒有提供mod_perl或安裝它的方法。

我一直擔心通過不使用mod_perl的CGI運行Perl Web應用程序會很慢嗎？ 我應該將所有代碼都改為PHP，這樣會更快嗎？

首先選擇Perl的原因是，我對Perl的了解比對PHP的要多。 我也希望能夠在Web開發領域之外使用我的Perl庫。

因此，如果你們中的任何一個都具有Apache Web開發的經驗，那么您能否闡明我應該朝哪個方向發展。

為了解決這個問題，可以說該Web應用程序每天將獲得500多次點擊。

如果沒有mod_perl，哪種PHP或Perl會更快？

在此先感謝您的幫助。

Answer 1

每天只有500次點擊，您幾乎可以編寫任何代碼，而不必擔心速度變慢。 每天有500次點擊，平均每3分鍾顯示一頁。 即使假設點擊數呈非正態分布，您也不必擔心如此小的訪問量。

Answer 2

PHP會更快。

但是，每天只有500次點擊，使用cgi不會有問題。 甚至每小時點擊500次也不行。

Answer 3

除非您的共享主機將PHP作為CGI應用程序運行（而不是mod_php或FastCGI），否則PHP幾乎總是¹會更快。 雖然以CGI身份運行的Perl可能每天可以處理500次匹配，但是使用CGI開發的應用程序/頁面將變得緩慢。

CGI的工作原理是為每個請求生成一個新進程來運行您的程序。 mod_php和FastCGI應用程序都通過生成一組進程，然后使用它們來運行您的應用程序來緩解這種情況。 換句話說，不會為每個請求生成一個新的進程。 （這是一個過於簡化的解釋，請不要在CS術語文件中使用。有關更多信息，請參見mod_php和FastCGI文檔）

1. 您可能想出了本來不會出現的病理性例子，但是那樣的話，您將成為提出事物的病理性例子的人，沒人會想要

Answer 4

在很大程度上取決於您的體系結構。 現代Perl框架不太適合用作CGI（較長的啟動時間）。 如果使用CGI，則Catalyst可能不是一個好主意。 就是說，使用經典體系結構應該很容易管理。

Answer 5

速度不應該是您的問題。 兩種語言都適用於Web應用程序。

Answer 6

擴展Alan Storm所說的內容 ，您也許可以將Perl與FCGI結合使用。

FCGI通過一種獨立的服務器來工作，該守護程序是一個守護程序，如果需要，它可以通過FCGI協議與Web服務器連接並委托/調度請求。

這比普通的CGI更快，因為它模擬了一種“ Servlet”模型，應用程序是持久的，並且不需要像普通CGI那樣對每個調用都進行新的初始化。

我尚未親自學習如何執行此操作，但是我相信Catalyst具有此選項，因此只需學習如何復制此操作即可。

由於FCGI應用程序不是特定於Web服務器的，並且某些Web服務器通過fcgi實用程序實現了PHP，因此與普通的mod_perl相比，FastCGI / FCGI可以在更多主機上使用。

我已經對FCGI Webserving進行了一些試驗，初步測試表明它可以處理至少500 req / s，遠遠快於上述500 /天或500 /小時的速度。

Answer 7

對於您正在查看的流量，使用香草CGI的Perl應該不是問題，盡管我會贊同較早的建議，以檢查FastCGI作為托管服務可能提供的另一種選擇。

或者另一個選擇是尋找其他托管公司...

Answer 8

可以將fastcgi支持破解到不支持的托管帳戶中。 我編譯的fastcgi庫的安裝前綴設置為與托管帳戶的主目錄相同。 然后，我將其同步並設置了催化劑以使用小型cgi-fcgi橋。 運行良好。 又好又快，因為cgi橋只是一個很小的小可執行文件。 催化劑過程在后台持續良好就可以了。

Answer 9

每個人心中的答案是：誰在乎。 每天500個請求是什么。

只需使用最快的工具來實施/維護和繼續前進。

Answer 10

對於可以使用CGI的較輕的Web框架，請查看...。

• 蹲坐
• CGI ::應用程序
• CGI :: Lazy

Answer 11

這主要取決於代碼的復雜程度以及代碼的組合方式。 如果將其作為CGI運行，perl將在每次調用時編譯腳本和模塊，並且必須針對每個請求重新連接到數據庫。 如果您的代碼足夠復雜，則每次瀏覽量可能要花費幾秒鍾，這可能會妨礙用戶體驗。

如果您的代碼庫和使用的模塊不是很大，那么應該沒有任何問題。

您可以在代碼上執行perl -c，以了解perl啟動的時間和編譯時間。