編程語言的速度對Web應用程序是否重要？

Question

我在整個互聯網上看到PHP，Python，Ruby等之間的許多基准測試。 Ruby因超級速度而受到很多抨擊，導致開發人員出於“性能原因”而拒絕將其用於Web開發。 但是，解釋器的性能對Web應用程序真的很重要嗎？ 99％的時間不是瓶頸位於數據庫中嗎？ 那么為什么每個人都嚇壞了？

注意：我意識到在某些邊緣情況下，例如某些數學/科學Web應用程序，性能很重要，但我不是在談論那些; 我說的是你的平均社交網絡，Stack Overflows等。

Answer 1

什么應該讓你害怕在角落里發抖，amazon.com和google.com進行的多項研究發現，頁面加載時間減少<1秒對他們的轉換率和利潤有顯着影響（對他們而言）。

因此，即使是小型網站，性能也很重要。 問題是它有多重要。 當你每天做100次獨立時，失去.1％的銷售並不重要，但是當你做1000萬時，那么突然間.1％會花費你很多錢。

即使響應時間的微小變化也會產生重大影響。 谷歌發現，從0.4秒的10個結果頁面加載到0.9秒的30個結果頁面加載，流量和廣告收入減少了20％（Linden 2006）。 當谷歌地圖的主頁從100KB減少到70-80KB時，流量在第一周增加了10％，在接下來的三周內增加了25％（Farber 2006）。 亞馬遜的測試顯示了類似的結果：亞馬遜的加載時間每增加100毫秒，銷售額下降1％（Kohavi和Longbotham，2007年）。 微軟在Live Search上的實驗顯示，當搜索結果頁面減慢1秒時：（Kohavi 2007）

 * Queries per user declined by 1.0%, and * Ad clicks per user declined by 1.5% 

將搜索結果頁面減慢2秒后：

 * Queries per user declined by 2.5%, and * Ad clicks per user declined by 4.4% 

http://www.websiteoptimization.com/speed/tweak/psychology-web-performance/

Answer 2

性能是否重要？ 最后，當然。

但是，您的網站必須變得如此之大，以至於您在傳統優化之外甚至會成為一個問題（例如，在您的數據庫中正確編制索引）之前，您將達到每月數百萬次點擊量。

我不認為Ruby厭惡與性能有很大關系（盡管存在問題）。 它更多的是它未經證實，有不穩定的聲譽，並強迫你的一個非常嚴格的框架（是的，我知道你可以使用沒有Rails的Ruby等）。 我不是Ruby的粉絲，因為我不是像CakePHP或Symfony這樣的重量級PHP框架的粉絲：我發現這些框架過於侵入性和重量級，你不再做PHP了。 相比之下，像CodeIgniter這樣的輕量級框架，它具有更好的投資回報率（imho）。

Answer 3

我認為你的問題沒有經過深思熟慮。

首先，您斷言大多數Web應用程序在應用程序方面都不需要出色的性能，這對很多人來說可能都是如此。 然后你給的那些需要良好性能的Web應用程序的一些例子，和波他們離開話說，人們只是把它們記C ++或Java，而不是！

那么，你不覺得他們可能更喜歡用Ruby或Python編寫它們嗎？ 也許這就是人們對測量Ruby和Python性能感興趣的原因！

編輯 ：好的，所以你對普通的網絡應用感興趣。 那么你和我都可以看到有兩種可能性：

• 性能實際上很重要，這就是為什么他們關注Ruby和Python以及PHP的性能。

• 表現並不重要，所以他們錯了，他們要么不知道這個事實，要么找借口。

Answer 4

這不應該是你問題的焦點。 相反，您應該專注於如何以最有效的方式將內容傳遞給最終用戶。 如果Web應用程序寫得很好，我認為任何主要的服務器端語言都是一個不錯的選擇。

Answer 5

性能對Web應用程序是否重要？

是! 甚至超過桌面應用程序！

使用桌面應用程序，如果需要，您可以使用用戶計算機上幾乎所有可用的資源。 使用Web應用程序，一台計算機必須能夠為大量並發用戶運行應用程序。 如果你不能輕易做到這一點，那你就陷入了困境。

Answer 6

根據具體情況，它可能很重要。 大多數網站都是在共享主機服務器上運行的，這些內容會增加。 在同一個盒子上運行幾百個Web應用程序，您將遇到CPU和內存瓶頸。

Answer 7

這里有幾個不同的參數：因為代碼在您的服務器上運行，如果您的代碼效率低下，那么它會過載並降低每個人的體驗。

硬幣的另一面是， 你需要成功才能發揮作用 ，正如Ted Dziuba如此雄辯和褻瀆地說。 開發中的“慢”語言往往比編譯語言更快，更具表現力，因此它們允許團隊更快地啟動和運行網站。

Answer 8

你是對的。 大多數情況下，瓶頸將獨立於您的服務器端語言。 當然，所有統計數據中有90％是動態編寫的，但我會說10次中有9次瓶頸要么是帶寬/傳輸速度還是數據庫操作。

假設您充分利用了每種語言，那么PHP與Python與Ruby vs .NET的性能相比，用戶可能會注意到的情況有限。 當像XML解析和壓縮這樣的事情大規模地完成時，你可能會開始注意到，但是否則我只會堅持你最熟練的東西。

通常，網站速度的一些最大改進可能來自gzip壓縮和小心使用緩存/內容過期。 這兩件事都可以在Apache或IIS中配置。 我在這里寫了關於這個主題的文章： http ： //swortham.blogspot.com/2007/10/three-ways-to-improve-your-websites.html

Answer 9

一旦網站正常運行，大多數網站都會發布第一版代碼。 如果它們一點都很成功，很快就會出現多秒頁面，他們需要關注硬件或軟件，我猜你是在暗示頁面代碼和數據庫軟件之間的隱含區別。

您是否想知道我們是否應該不關心頁面代碼並假設數據庫中存在任何非硬件擴展問題？ 那不是我的經歷; 雖然它通常是最快發布的數據庫，因為像馬蹄鐵一樣，通常關閉足夠好（只要答案是你所期望的。）

但是我已經看到了更多的頁面代碼試圖做數據庫的設計（例如使用數組）而不是反之亦然（例如游標），同時對速度和可伸縮性產生同樣的不利后果。 優化數據庫查詢在我的工作中比修復PHP代碼要少。

我認為大多數速度問題不是語言（或dbms本身），而是設計和代碼的質量。 所以我認為優秀的開發人員會更關心一種語言是否有助於良好的設計和良好的代碼，而不是它的運行速度。

Answer 10

根據我的經驗，一旦你真正開始變得忙碌，那么它就在你可以做出最大差異的數據庫中。

但我還要添加另一個考慮因素，就像圖像，JS和HTTP請求而言，頁面大小是多么“大”。 你可能會有一個非常慢的網站，因為你的超快速數據庫和應用程序代碼創建了一個帶有臃腫的JS和圖像的網頁怪物。 :)

Answer 11

jfar讓你沿着正確的道路前進。 至於你的語言對此有多大影響，分析可能會表明你的語言不是你的瓶頸。

• 避免像old-scool cgi那樣的每次請求編譯。 大多數現代Web框架需要駐留在請求之間。
• 如果它沒有太大變化，則生成它並提供靜態。
• 壓縮。 如果可以，請啟用gzip，並刪除空格和注釋。 白色空間用於開發和調試。
• 找出主要的數據庫用例，查詢或插入，並調整正確的數據庫用例。
• 緩存/渲染你可以。
• 如果您是操作人員將允許您更改/升級，請嘗試對不同的應用服務器進行基准測試。

任何其他人都有一些通用的網絡調整提示或其他SO問題的鏈接？

是否有關於Web應用程序性能調優的好書？