場景：
前端：VUE框架，後端：spring boot +spring security認證。
問題描述：登錄的時候，每3到4次才能成功登錄一次，其他都是超時，前端設置的超時時間是20s，對大多數接口來說這個已經足夠用了。
服務器配置：騰訊雲，2核4G1M帶寬。
過程：
第一次嘗試：最開始以爲是服務器配置太低，因爲超時的時候去查看在線人數大概200+，以爲是人多，同時訪問請求多，導致1M帶寬不夠用，然後嘗試吧服務同時放在一個配置更高的服務器上（也就是有2個服務器都能訪問後端服務，通過nginx配置負載均衡），配置完成後，reload nginx，測試效果，發現沒有什麼變化，依然超時。--------------方案失敗
第二次嘗試：考慮到某類用戶用的比較多，所以把這些用戶用到的頁面，加了緩存，這樣能減少服務器的壓力（以爲在登錄的時候，有很多人正在用系統，就把系統常用的加了緩存），升級測試，發現沒有什麼變化，依然超時。--------------方案失敗
第三次嘗試：打開系統監控，發現耗時最多的就是登錄接口，覺的登錄接口應該是有問題的，應該有很耗時的數據庫讀寫操作。排查結果，登錄的時候，使用的是spring security來實現認證的，並將查到的用戶和相關信息（和登錄人有關的信息，SQL關聯的比較多）放到緩存中，供以後使用，這個相關信息就是多餘的，完全可以重新寫個接口去完成，SQL也可以進行優化，不用在登錄的時候去加載；登錄的時候要往中間表寫入登錄記錄，日誌要加入登錄日誌，這2個操作完全可以異步進行；將上述過程優化拆分之後，發包測試，發現登錄超時的頻率變低了，說明是有作用的。但是依然超時存在。-----------方案沒有完全成功
第四次嘗試：因爲是登錄，登錄又用了spring security，所以懷疑spring security是不是有什麼坑，去百度了下，發現有人的博客，寫了用這個技術實現的登錄，第一次特別慢，按照那個方法，嘗試了之後，測試，發現沒有什麼變化。--------方案失敗
第五次嘗試：在上面都嘗試了之後，沒有任何發現。決定用最笨的方案，將登錄裏的每一步可能消耗時間的過程，都加入時間統計日誌，也就是在執行之前獲取時間，執行之後獲取時間，2個的時間差就是這個語句的執行時間。加完發包。測試登錄，超時，打出日誌，查看日誌，發現異常，其中有一個不起眼的步驟，理論上應該不會有問題，在這個地方的執行時間最長，而且成功的機率很低，但是底層封裝的如果出錯，返回一個默認值，所以不打日誌是沒有辦法發現的。這個過程就是：根據登錄人的ip去查所在地理位置，這個過程是調用淘寶的一個接口：http://ip.taobao.com/service/getIpInfo.php，這個接口真的是沒有什麼實際價值，不推薦使用。最終把這個接口乾掉了，不用存這個信息。發包，測試，登錄秒入進去--------------方案成功，歐耶
總結：除了第四次嘗試沒有對系統起到任何作用外，其他的步驟，都是有一定幫助的。解決了這個問題之後，發現定位問題的思路有問題。步步高說過，哪裏不會點哪裏，咱們肯定要哪裏出問題找哪裏，所以一開始的方向不對（可能也對自己的系統的健壯性蜜汁自信了一把）。應該沿着登錄這個切入點進行，也就是最起碼從第三部開始嘗試，不要放過任何一個簡單的步驟。
總之，優化系統的時候，以下幾個方面入手：
SQL效率
是否要加緩存
是否要使用異步或者多線程解決
是否有調用外部系統中的接口
服務器的配置優化
接口邏輯優化