一次優化web項目的經歷記錄
這段時間以來的總結與反思
前言：最近很長一段時間沒有更新博客了，忙於一堆子項目的開發，嚴重拖慢了學習與思考的進程。開水倒滿了需要提早放下杯子，晚了就會燙手，這段時間以來，寫的東西越來越不嚴謹，各種低級錯誤頻出，早該停下總結並鞏固一下了，但出於一些原因一直沒付諸於行，終於，燙到手了
第一章：50分鐘打不開的一個網頁
事故現場爲互聯網上的一個角落
我負責的一個社會實踐微足跡項目的管理員端登陸頁面（準確的說，我負責的部分是後端+用戶h5、微信前端頁面，管理員端頁面是交由X負責，我提供數據），接到反饋說，校級管理員在登錄頁卡了50min（從21:00到21:50）。親測結果雖然沒那麼誇張，但也用了將近3分鐘（考慮到管理員網絡狀況、失去耐心刷新頁面，以及”反正是網頁卡住了我先喝杯咖啡”等動作，他花了50min纔打開網頁是可信的）。如此還了得，不想繼續打噴嚏就趕緊修復
爲什麼訪問這麼慢呢？瓶頸在哪兒？
根據chrome開發者工具的Network日誌來看，其實登錄接口(login)在一瞬間就完成了（700ms），主要是卡在了拉取信息的接口(overview)。這個接口原本是要返回一個信息概覽的，但X爲了簡tou單lan，要求在這裏就拿到所有會用到的數據，導致單接口要處理的任務較多。但就算如此也不應該會卡這麼久，顯然是什麼地方設計錯了。
第一想到的當然是數據庫
衆所周知，數據庫連接是很耗時的，一般來說大部分項目的瓶頸都發生在數據庫上。但我當初創建數據庫的時候我是做過精心設計的，藉助sqlalchemy做orm（忘了說了，這次後端用的python來寫），合理的使用foreignKey與relationship，其實已經是很優的做法了，雖然後來發現仍然有可優化的空間，但那絕不是造成如此巨大耗時的原因。
話雖是這麼說，但當事實（141s的延時）放在眼前時，很難有這麼大的自信不去懷疑自己，爲此做了很多無用功，耽誤了不少時間。不過在boss兼學長兼老師的L幫助下，雖然沒解決問題但確實加深了對原生SQL語句的理解運用。
（就個人來說，數據庫比較複雜時通常就直接用orm了，所以說更大的收穫其實是讓我更加認識到了sqlalchemy背後所做的工作到底爲我省了多少事情）
這樣的話就麻煩了
在折騰了半天后醒悟到不是數據庫的瓶頸後，我意識到這次的問題可能會有些麻煩了，不是那種能一眼發現恍然大悟進而分分鐘搞定的bug。如果不去實際的做點什麼，簡單的分析代碼猜測原因只是在浪費時間。
這裏不得不提的是，Docker確實是很方便的技術，但畢竟使得代碼部署多了一層容器，一定程度上確實會給修復bug調整代碼造成一些麻煩，你不得不重構你的鏡像，重啓你的容器（除非你用volume把代碼掛載到宿主機上，但這不就失去了一鍵交付、快速部署的意義了嗎，我通常只在開發環境中這麼做）。
嘛，比起它的好處來說這也不算什麼，我只是想說，如果你只是做個很小的玩具，它負責測試你的想法，實驗你的靈感，而你經常會隨意修改它並且不打算集羣部署發佈或者交付給其它人使用，那麼你大概不需要Docker。
好吧，那麼下面我就得調試我的代碼，監控它的運行並找出耗時瓶頸
下面的內容纔是重點，是我一定要記錄下這次經歷的原因所在，我們明天再繼續