一個流量並發很高的項目，最佳化是從什麼時候開始的？

當前頁面遇到問題就立刻最佳化嗎還是等到（模組/項目）接近完成了才開始最佳化？
一直get不到點

回複內容：

當前頁面遇到問題就立刻最佳化嗎還是等到（模組/項目）接近完成了才開始最佳化？
一直get不到點

一開始架構肯定要搭建好啊，不然後面只能對硬體設施進行最佳化，

回答問題麻煩看清楚問題

首先當然是編碼人員自身的意識-編寫高品質的代碼

在不影響進度的條件下可以最佳化代碼邏輯。

然後先保證開發完成，跑起來再分析哪些是瓶頸，進行最佳化。

因為可能你現在絞盡腦汁最佳化的點佔整體瓶頸的1%，最佳化從重點著手效率才最高。

最後，每一階段的最佳化重點可能不一樣，也要更具需求來分析解決瓶頸。因為你現在最佳化的點，可能在這一階段根本用不到。

站在資料庫角度來說：

一開始就知道是並發很大，那就需要從設計表結構開始，避開一些並髮帶來的設計，比如拆分一部分不常用欄位到另外的表等，大架構基本方向對就可以。

至於其他的，就需要看具體需求，現在的設計基本是先完成功能，後最佳化！

我舉個簡單的例子，你過年回家，開始是想騎單車回家，然後一直在思考用什麼樣的單車，怎麼騎才能快的。。。可是大家回家都是坐飛機回去的，所以，要看你最佳化的有沒有意義，最後你都不採用現有方案，最佳化再好也沒用。。。架構的時候就應該想好最佳化的問題。。。一點個人見解。。

題主的問題是當前頁面遇到問題就立刻最佳化嗎還是等到（模組/項目）接近完成了才開始最佳化？
我的答案是：遇到問題，解決問題

從重構開始。

你的問題其實算不上一個問題，就是想問馬上改還是稍後再改，對嗎？應對問題你肯定要有個方案，然後評估優先順序，然後實施就是了，從這個角度來說沒有任何問題是發現後馬上改的。但是怎麼評估優先順序就要看具體情況了。
簡單說：
高並發僅在特定應用上發生，影響範圍被限制在某個模組內，不是核心功能，且不對其它功能產生直接影響，這個最後處理也沒問題。
高並發僅在特定應用上發生，影響範圍被限制在某個模組內，但是是核心功能，也對其它功能產生直接影響，方便的時候解決就行了。
高並發在2個或以上應用上發生，影響不限於某個模組內，儘快安排解決。
這也就是一般的情況，實際開發的時候你還要綜合考慮外部壓力之類的問題（比如客戶死活讓你下周上線）。

最佳化應從設計邏輯開始.
商務邏輯思路清晰就最好了,尤其是開始時候就和程式員從高並發角度做準備,整體可以給業務帶來比較小的壓力,或者功能比較好拆分,都能在項目開始階段把問題解決掉.
當然這是最理想狀態,通常做不到.
那麼就要根據已有商務邏輯,儘可能將業務規劃為容易拆分的模組,理想狀況是,將來哪裡成為瓶頸,哪裡直接加台機器裝上對應邏輯就解決.
這也是理想狀態,沒人Crowdsourced Security Testing先覺,但有經驗的架構師可以預先處理掉大部分問題.
接著就是根據實際情況解決問題,這個就要看,實際業務上,究竟哪裡是瓶頸.
一般說來,出問題的就幾種情況:
1.程式員寫的東西本身不過關,我見過有人在業務裡遞迴查資料庫的,還不限制層數,在本地跑的好好的,一上線,cpu爆表直接掛掉.
2.訪問過多,這也可能是靜態檔案太多引起的,或者頻寬被佔滿了.那麼就需要考慮CDN或者把一些固定檔案資源分派到專門伺服器上面去.
3.資料庫頂不住了.這個也非常常見,一般就是單表資料量太大引起的. 或者還不算大但查詢很慢這類問題一般是索引不足或者過度索引造成的.處理完還要看看是否可以最佳化資料庫配置,營運有時候只負責資料庫跑起來,其餘最佳化配置全不管.接著還不行就考慮加緩衝,增加一層或者乾脆換成 Nosql資料庫,但這個就需要看具體商務邏輯才可以.

我遇到的問題,一般在這幾個層面都可以解決的掉了.所以更高深的還在學習中.
拋開具體商務邏輯也只能說些比較空泛的了,所有拋開商務邏輯的最佳化,並發都是偽命題.

