前言：有些朋友說，做性能，不需要了解業務邏輯，直接按接口文檔，或者抓包寫壓測接口的腳本，然後壓測、監控、分析、調優、迴歸；
我覺得這樣的回答，可能是他們沒喫過不熟悉業務邏輯的虧；
最近壓測的時候，遇到一個等待鎖超時的問題，就是因爲不熟悉業務邏輯造成設計的腳本不合理，下面和大家分享一下！
由於是臨時任務、時間緊迫、對應的開發又出差了，他遠程信誓旦旦給我說直接壓，根本不給我熟悉業務邏輯的機會，趕鴨子上架一樣；
請求參數用戶名是變化的，做了參數化，由於各種客觀因素，參數數據只准備了100個，參數取值策略是唯一、用完後循環；
當壓一會兒後，就會出現下面的錯：等待鎖超時。
經過分析定位，問題的原因是如果相同用戶反覆請求，會出現等待鎖超時，因爲相同用戶從第二次請求開始，都是update操作，會鎖行數據，其餘更新相同數據的請求就等待，最終出現超時，經和開發溝通，確實如此，且這種場景的概率是很低的，隨後協調資源，重新調整了壓測腳本的參數數據量，相同用戶只發送一次請求，重新壓測，未出現此問題；
所以，壓測前熟悉業務邏輯是非常有必要的，除了可以設計合理的性能腳本，還可以在分析定位的時候，方便我們定位代碼邏輯問題。