1：首先需要有非常良好的網路頻寬，若有上萬人同時錄入資料的普通的web資訊管理系統，至少需要10m左右的網路頻寬，而且網通、電信的主幹網都有接入比較好，否則全國各地的網路情況都不太一樣，有的城市錄入資料時可能會遇到網路非常緩慢的情況，甚至到無法忍受的程度。
2：須有一台牛x的web伺服器 + 一台牛x的資料庫伺服器(備註接近頂配的奢侈硬體伺服器非個人pc)，由於是需要錄入1000萬條以上資料，最好採用oracle資料庫比較理想一些，經得起考驗一些。
3：需要進行適當的記憶體快取優化策略，不能所有的資料庫都依靠sql資料庫的方式把壓力放在資料庫伺服器上，盡量多使用記憶體的方式處理資料。
4：需要乙個牛x的，經得起考驗的資料庫訪問層，因為每秒都有可能成千上萬的人在訪問，若是質量不良好的資料庫訪問元件、或者不穩定的資料庫訪問元件，更容易導致系統崩潰、或者占用非常龐大的記憶體，最後容易導致整個系統的崩潰。
5：需要優化分頁訪問資料功能，應為有可能會有1000萬條資料，若分頁讀取資料的功能沒能優化到最高，也很容易導致系統的崩潰，因為上萬人萬一在同一時間，或者接近同一時間點了查詢某頁資料時，那系統就真崩潰了，分頁訪問資料一定需要做到極致才可以。
6：需要進行資料庫索引優化，有索引和沒索引的效能差距有時候會是100倍，大資料量時可能會有1000倍都有可能，資料庫索引優化到極致了更容易得到執行順暢的資訊管理系統。
7：嚴謹高效的資料庫事務處理，由於高併發，並且有些單據是需要同時寫入多個表，需要保證資料庫的一致性，要麼全部成功，要麼全部失敗重新錄入資料，所以需要乙個高效的資料庫事務處理機制的配合。
8：所有的系統的操作日誌、異常資訊都需要完整的記錄下來，當系統發生一些故障時，可以快速排查問題，對正確診斷系統發生的故障的原因做分析參考用。
9：需要經常檢測系統的各項指標、例如各伺服器的記憶體使用情況、cpu使用情況、網路頻寬使用情況，高峰時的各個引數是什麼情況、系統不繁忙時的情況等，若伺服器快承受不了壓力了，就得馬上增加負載均衡的伺服器，網路頻寬不夠了需要增加等等，總不能等系統崩潰了再去做這些事情。
10：每個頁面的html、js都進行優化，若某個頁面多餘發了100個字元的垃圾html**，那1萬人每天獲得100次，那得占用多少網路頻寬，100×100×1萬個字元的多餘html被網路上傳輸了，要知道接入主幹網的網路資源是多麼寶貴，費用是多麼昂貴。
11：html、js等都可以考慮用壓縮模式傳輸，那樣網路傳輸效率會更高一些。
12：由於全國各地上萬人，會有各種各樣的人，這些人也未必全是好人，可能某些人心情不好，或者其他什麼的，可能就會攻擊我們的軟體系統破壞資料，這些也可能是由於好奇心導致的，所以系統需要有嚴格的許可權管理控制，不應該進入的頁面絕對不能進入，不應該看的資料絕對不讓看，不能操作的功能絕對不讓多操作，一方面防止沒必要的多餘的麻煩，另一方面也可以減少系統被攻擊破壞的可能性。
詳解 優化API介面響應速度的套路
api介面響應慢？sla一直提不上去？其實這是後端程式設計師想高階必須要跨過去的坎 就是把它優化掉。那麼這其中到底有沒有套路呢？答案是 有的。本文將介紹目前正在用並且十分 無腦 有效的這個套路。首先呢，第一部肯定是在關鍵函式 有db 檔案 複雜計算等操作 的前後，進行時間的記錄。這裡分享乙個前文跟蹤...
提高Github的訪問速度
由於cdn被遮蔽導致的github 的訪問速度很慢，但是可以通過修改本地的hosts檔案，繞過dns的解析來實現訪問的提速。實現如下 1 將c windows system32 drivers etc目錄下的hosts檔案用文字編輯器開啟備用。2 開啟 3 查詢assets cdn.github.c...
部署在本機的Tomcat響應速度慢！
問題現像 新開乙個瀏覽器，開啟 本機部署 第一次請求的時候響應很慢，但是第二次響應就很快，但是停止操作幾分鐘後，再請求又變慢。www.hooblogs.com 猜測及驗證 1.tomcat的問題，重新安裝了乙個tomcat，情況依然存在。2.第一次請求後，在 中debug了乙個斷點，發現隔幾秒鐘才能...