對於小的併發量,我們能做的一些簡單的優化,特別實際

2022-02-13 15:10:30 字數 783 閱讀 3211

其實很多時候,我們在現實生活中遇到的很多併發量並沒有像**雙十一一樣,可能只有它的1%而已,不要總想著,要麼你的專案併發量特別大,要麼你的專案併發量基本沒有。

其實在實際中,我們應該盡可能的去優化我們的系統。

這裡我就只列舉那些現實可用的,簡單的,我們能力範圍之內的。這些優化方案其實對於小的併發來說足夠了。

1、cdn,這個可能實現起來需要條件,它能快取你系統的所有靜態的頁面資料,注意只有那些靜態的頁面,css,js等可以快取,cdn能減少你從主要伺服器取資料的操作。而且真的很快,其實很多時候,我們可以使用網上的一些cdn的jquery也是同樣的道理。

2、redis,快取資料庫,它能幫助快取一些後端方法極其頻繁的資料,他的訪問速度很快,併發量抗的很高,類似的這種也有很多。存放的方式多數都是以鍵值對的方式存放讀取,很方便。

3、儲存過程,其實訪問很多時候,時間慢是因為網路的延遲,而對於資料庫的訪問,如果乙個sql非常複雜,那麼它的傳輸和執行就特別受網路延遲的影響,所以解決的方式就是使用儲存過程,它把你的sql預先放在了資料庫上面,這樣減少了sql的資料量,執行的速度就能提高,也減少了對於網路延遲的影響。

4、前端控制,利用簡單的js其實就可以限制一些正常使用者的操作,防止使用者的頻繁操作等,這裡我就不列舉了,總之,控制使用者的訪問也特別重要。

5、位址控制,有時可以通過加密,先儲存真正的操作位址,讓使用者無法真正訪問到,等到時間到,再開啟訪問。

對於伺服器的負載均衡什麼的,涉及架構方面的,本人能力有限,還沒有研究到那步,暫時我覺得如果能做到以上的優化,至少對於小的併發量來說,還是很有效果的。

java 對於高併發的一些理解

併發是什麼 就是多個執行緒同時處理不同的操作 高併發 就是很多使用者同時訪問,導致系統資料不正確,出現髒讀等情況.常見的解決放法 硬體來說使用集群技術,更好的伺服器以及資料庫 從技術層面來說 使用快取,最常見的是redis,一般來說,可以允許丟失,變更頻率較低,全專案通用的,實際上還是要根據相應的業...

頻寬對於併發連線的一些總結

示例頁面 首頁是有105個請求,頁面大小為730kb.客戶端環境為win7 ie8 httpwatch,載入完www.qq.com為4.6s ie8 瀏覽器的預設併發數是6,即同乙個網域名稱的併發連線數為6個.所以img.qq.com和www.qq.com同時出現在乙個頁面中,則可以有12個併發連線...

對於工作的一些思考

感覺自從領導讓我管專案以來,一直沒有讓領導很滿意的地方是自己在專案上花的心思太少.很簡單的一些例子就證明了,比如自己雖然是中途接手的專案,然後並沒有仔細檢視招標檔案,沒有針對招標檔案的要求 去核對乙方的一些功能是否完成.其次,對於乙方,我還在心裡上和行動上 做到完成把控住,我不僅要去分析我領導的想法...