2010-11-25 86 views
4

我有一個php程序,有大約50-55個代碼文件。具有最大代碼量的文件大約有1200行代碼(這包括空格,製表符和多行換行符......),其餘代碼文件比這個小。與mvc/oop相比,spaghetti php code的性能和可擴展性?

在幾乎每個文件中的應用程序代碼是混合的HTML,SQL和PHP(你稱之爲意大利麪條),除了幾個文件是純PHP包含文件....例如包含功能的文件在許多其他地方需要。

我一直在考慮將此應用程序重構爲mvc類型的體系結構是否是一個好主意。

現在我知道一個mvc應用程序提供了很多優點,例如便於維護,重用和易於進一步開發等,但是可伸縮性和性能如何 - 特別是在這種情況下?我認爲這是一個小應用程序(我相信,你認爲它足夠小嗎?),我不會想象在維護或添加更多功能(最大)時很難,這可能意味着現有文件中的一些增加,或者可能會增加最多5-10個新文件。

所以我想我不應該爲了維護而轉換爲mvc。

據我瞭解,你可能會把每個組件的mvc放在一個單獨的服務器上來傳播負載,以便有一個不同的服務器提供html,數據庫和邏輯服務,並進一步做其他優化/緩存以及做一個很好的是mvc應用程序的縮放和執行。

我認爲即使在一個小型的意大利麪條應用程序中,我們也不能爲html,數據庫等設置不同的服務器,我們可以通過在Web服務器,數據庫服務器等前設置負載均衡器來輕鬆擴展而不會降低性能。到一個服務器是不夠的)

更重要的是,它自己的意大利麪代碼應該比mvc執行得更好,因爲它沒有任何開銷,如需要包括文件或文件夾下的文件或函數調用屬於mvc的不同組件。

因此,考慮到所有這些事情,您是否真的認爲將相對較小的意大利麪應用程序重構爲mvc以實現可伸縮性和性能很有用?

請不要告訴我重構將在未來有用(我知道這將有助於並考慮我們是否真的需要添加更多的代碼到現有的代碼庫),但請給我一個明確的答案

1)我真的需要將此應用程序轉換爲mvc體系結構以獲得可伸縮性和性能嗎?

2)像這樣的一個意大利麪條應用程序可以擴展和執行一天至少100萬的請求,其中一半發生在某些高峯時間?

+1

通用框架實際實現的稱爲「PMVC」,它不允許將組件分佈到不同的服務器上。你還應該首先將代碼從意大利麪(全局範圍)代碼轉換爲適當的程序結構(這是不同的)。在嘗試在它上面放置一個假設模式之前,分解輸出和處理邏輯中的SQL處理。 – mario 2010-11-25 22:02:23

回答

5

據我理解你可以將MVC的每個組件單獨的服務器上,以分散負載

我從來沒有聽說過自己 - 但我來自一個。網絡世界中,你可以在同一臺服務器上運行所有的託管代碼(這不像在Java世界中,你經常有一個單獨的「應用」服務器和「網絡」服務器)。你可能會轉移到MVC的主要原因(就像你提到的那樣)是爲了管理代碼帶來的好處:關注點分離,重用等;不是表演。

理論上你可以用基於對象/組件的技術來完成這項工作,例如組件之間相互通信的Java或.Net,但是在程序代碼中?我不這麼認爲!

因此,考慮到所有這些事情你真的認爲重構一個相對較小的麪條應用MVC的可伸縮性和性能是非常有用?

沒有 - 通過可擴展性和性能假設你指的運行時系統的特質,我相信這是你的意思。如果您將可擴展性和性能純粹納入開發環境(人員編碼 - 他們可以在系統上工作的速度和容易程度,您可以輕鬆地將開發人員添加到項目中),那麼答案將爲

2)這樣規模的一個意大利麪條的應用和能爲atleast最低100萬項的要求進行了一天半在一些高峯時間,其中發生的呢?

空話不可能的 - 我喜歡沿着這些線路戈登的意見 - 但我相信你會同意,這可能不是你可以上最好的基礎。

4

不,您不必轉換,因爲無限預算任何應用程序都可以無限擴展。只需添加更多服務器。問題是,你有無限的預算嗎?如果你沒有無限的預算,找出更便宜的方法:添加更多硬件或優化代碼。

所以真正的答案是:也許。

我們無法告訴您應用程序需要什麼才能實現可伸縮性目標。我們不知道它做了什麼,也沒有爲期望的性能提供硬性限制。例如,請求需要多長時間才能提供服務?運行ab或Siege並測量您的現狀。在您的代碼上運行一個分析器並確定瓶頸。找出你是IO,CPU還是RAM綁定。你使用操作碼緩存嗎?拿出你的所有發現並對成本進行有根據的猜測。然後決定如何優化。

需要花費幾微秒的努力比簡單地添加更好或更多的硬件更高。在實踐中,您可能會採用混合策略來找到滿足您需求的最具擴展性和經濟實惠的解決方案。

請注意,將一大塊泥漿重構爲原始的OOP應用程序並不一定意味着它會在以後運行得更快。事實上,越鬆散耦合,越是間接,層越多,應用程序可能變得越慢。這是一個更好的可維護性的折衷。可維護性也是一種節約成本的方法。它會減少你的時間來提供新功能。

1
  1. 沒有

50+文件是不小。意大利麪代碼不可維護且效率非常低,因此在適當的框架下沒有性能優勢。最後,一個好的框架提供了設計良好,經過充分測試和不斷更新的插件,以實現最常見的任務,從而減少必須編寫和維護的代碼量。

早在1995年,高流量的網站就一直在糾纏着大量意大利麪代碼。今天,你甚至不應該考慮在意大利麪條代碼上運行高流量的網站(或任何類型的網站!)。