壓力測試後的收穫

最近開發的站點進行壓力測試，伺服器cpu佔用率居高不下，發現了一些影響站點效率的**問題：

1 太多的string + string操作，最後通通改為了stringbulider。其實這是自己的程式設計習慣不好，明明知道stringbuilder的效率高，寫**時圖省事，就直接用了+操作，量變引起質變。

2 正規表示式會對速度的影響，多餘的正規表示式要刪除，原來是有一段ubbcode需要轉換，於是呼叫了共通的轉換類，這個類中定義了n多正則轉換，但我用到的就是那麼幾個，不需要的在程式執行時也執行了。

3 資料進行了快取，但頁面沒有進行部分快取，當時是考慮頁面上有些每次都要更新的東西，於是就沒對頁面進行快取處理，片面的認為資料快取已經夠了。現實是頁面的部分快取還是要做的。實現頁面部分快取有兩種方式：一種子是將頁面中需要快取的部分置於使用者控制項中，並對使用者控制項設定快取功能，是通常所說的「控制項快取」。另外一種是「快取後替換」的方法，該項方法與使用者控制項快取正好相反，將頁面中的某一部分設定為不快取，雖然快取了整個頁面，但是當再次請求該項頁面時，將重新處理那些沒有設置為快取的內容。這些都有成熟的方法了。但公司的同事教了我另乙個方法：

主要是利用了system.io.stringwriter和rendercontrol，將頁面的顯示用div進行了快取，其中的div都是runat="server".

string content1 = "";

string content2 = "";

string content3 = "";

string content4 = "";

string content5 = "";

string content6 = "";

+ "_item1");

+ "_item2");

+ "_item3");

+ "_item4");

+ "_item5");

+ "_item6");

content1 = cache[_pid.tostring() + "_item1"] as string;

content2 = cache[_pid.tostring() + "_item2"] as string;

content3 = cache[_pid.tostring() + "_item3"] as string;

content4 = cache[_pid.tostring() + "_item4"] as string;

content5 = cache[_pid.tostring() + "_item5"] as string;

content6 = cache[_pid.tostring() + "_item6"] as string;

if (!string.isnullorempty(content1) && _sub == 0)

else

}

壓力測試後的收穫

壓力測試後，BCH採用增加

ab壓力測試 mysql MySQL壓力測試

mysql 壓力測試 golang 壓力測試

壓力測試後的收穫

壓力測試後，BCH採用增加

ab壓力測試 mysql MySQL壓力測試

mysql 壓力測試 golang 壓力測試

相關推薦