在大型社交網站上用PHP實現什麼東西代價高昂？

聽到在「後端」應該使用C++或Java來提高性能是很常見的。我相信像Facebook這樣的網站擁有基於C++的「服務」來實現關鍵性能。在大型社交網站上用PHP實現什麼東西代價高昂？

例如：這是在任何時候更具成本效益，以取代SQL「SELECT * FROM ......」型的命令通過PHP通過別的東西，因爲數據庫是一個巨大的一個進行搜索？

一般可以通過某人的例子什麼樣的事情之一可能不應該是即使在現場的早期階段使用PHP解釋。

2011-04-07 algorithmicCoder

不成熟的優化是萬惡之源。直到你達到足夠的點擊PHP成爲瓶頸不要浪費你的時間。你的大多數性能問題將與IO相關（即數據庫查詢），這可以很容易地使用memcached之類的東西來抵消。 – GWW 2011-04-07 05:26:43

您並未構建大型社交網站。你可能會認爲你是，但你不是。這不會很大。使用您熟悉並習以爲常的工具和實踐來構建它。如果您以後需要進行深層次的架構變更，因爲您以某種方式設法變得流行，那就這樣做吧。但稍後處理這種可能性*。不要將自己建設成一個角落。 – Charles 2011-04-07 05:27:11

被授予，大量的人在開始時從來都不是問題......但是有些情況下，即使是少數人也需要大量的**數據** ......在這種情況下，擔心什麼是高效是生存的根本......我不知道過度的架構師我只是對數據的規模相關時人們擔心的事情的具體原因和具體事例感到好奇...... – algorithmicCoder 2011-04-07 05:34:47

我不是web開發人員，我也沒有PHP程序員和這個問題是更多的討論，所以讓我試試。

在這種超大型網站上，您需要智能高效的算法，而不是高效的語言。很多運行他們網站的Google代碼都是用Python編寫的，它們的速度與惠普PHP相同。

我認爲數據庫需要構建的方式，它儘可能返回儘可能少的數據，它需要儘可能少的查詢數和返回的數據需要儘可能少的處理顯示。它也是白衣插入。

如果您設法以這種方式設計此類頁面，那麼您的頁面將不會是處理器詳盡的，並且意味着您將使用哪種語言並不重要。

您也不需要像銀行一樣使用防爆類型的數據庫（100％轉換比較，數據庫鎖定等），因此您可以平衡可靠性主幹速度。但爲此，你需要specal數據庫。

來源

2011-04-07 05:39:23

究竟會更換什麼「SELECT ...」用？數據庫越大更多您應該對其使用SQL。如果訪問速度緩慢，請檢查您使用的查詢是否受索引支持。

你問題的其餘來自主觀和議論文的標題下，而是從痛苦的經驗，我不會爲任何事情預計將增長超過一個很小的初始大小使用PHP的。

來源

2011-04-07 05:26:05 EJP

你說過「我不願意」 t使用PHP進行大型項目「，那麼你的建議是什麼？請與我們分享 – Predator 2011-04-07 05:34:13

@Gens，那會有什麼好處？當然，他會推薦他覺得最舒服的一切;這與它是否是最合適的工具無關。很有可能，這項工作沒有最合適的工具。使用任何你想要的。如果你失敗了，（幾乎）不會是工具的錯。 – Bombe 2011-04-07 08:33:48

@Gens我會使用靜態類型和強類型語言。有幾個衆所周知的例子。 PHP無法通過這些測試。 – EJP 2011-04-08 10:15:02

類似Facebook的網站往往是漸進的，經常有很多重寫。但是，他們確實經常運行在C++ DLL之上。 SQL雖然基於字符串是相當快的。需要牢記的一點是，有數百個SQL處理軟件。 SQL是一種語言，而不是軟件。

來源

2011-04-07 05:26:26

SQL是*語言*不是協議，它不是'基於字符串'的。 – EJP 2011-04-07 05:28:07

我很想與你交流。我意識到它不是以原始字符串的形式存儲的。 – 2011-04-07 05:31:43

您不與SQL進行通信。您在* SQL中編寫命令*，這些命令是通過特定於供應商的協議遠程執行的。如果這意味着SQL是基於字符串的，那麼每一種其他編程語言都是如此，但這並不能阻止大部分編程語言的快速發展。評論並不意味着什麼。 – EJP 2011-04-08 00:24:23

是我agree..there許多DLL的運行寫在C++ ..或者甚至是每秒更新服務器cron作業......但我覺得有幾個數據庫，Facebook的利用你的位置..depending你將連接到server..and數據更新自動後端腳本或代碼將運行到這些數據庫同步後...

來源

2011-04-07 05:35:35

在大型社交網站上用PHP實現什麼東西代價高昂？

回答

相關問題