參加 ISUCON6 預選淘汰

之前在公司內就聽到同事在找人參加 ISUCON 6,因為懶得好好準備跟擔心拖累參加過的人,這次就跟公司內的都是第一次的台灣同事(W 和 H)一起報名參加。雖然說沒什麼在準備,還是有看一下去年考古題。基本上就是主辦方提供複數語言實作好的 web app,然後在比賽時間 8 小時內調好效能,主辦方會透過 benchmark 工具測量時間跟正確性,資料正確且延遲越少分數就會愈高的競賽。例如去年的考古題就是類似部落格系統,程式中可能有 bug,n+1 查詢,少了 index ...等等。據說還有強者自己用 c++ 之類官方未提供的語言重新實作完 web app(今年也有這種團隊且晉級了...)。

今年題目是一個類似 wiki 的系統,因為沒有 Java 的實作,所以我們挑了 JavaScript 來挑戰(同事 H 是 js 為主的工程師)。沒想到一開始程式本身就有超時問題,我們直到中午過後才開始得到分數,流程上大概如下:

  1. 先處理 table 少了 index 或是資料庫查詢結果含有不必要欄位的問題。
  2. 文章內如果有其他文章的標題,必須轉換成連結的部分,這部分我們就用 redis 快取所有系統內的標題,避免資料庫的存取,並且只要有新增或刪除文章就更新快取。
  3. 另一位同事則幫忙設定 nginx 來處理靜態檔案。
  4. 最後發現處理最慢的部分是 js 的 replace,用來將文內其他文章標題取代成連結。
result.replace(new RegExp(escapeRegExp('title1|title2|title3...'), 'g'), link);

原本想開始改善這部分,但後來時間不足所以成績只在九千多分就結束了本次的比賽(沒記錯的話第一天第一名應該是20多萬分)。

反省點
  • 後來發現別人提到可以實作 trie 來取代慢慢的 replace(賽後簡單實作一下就從 1s 降到 500ms左右),想想平時偶爾也會玩一下 topcoder 或是 AtCoder,竟然沒來的及想到。
  • 記得要認真 profiling,字串取代慢的問題太晚發現。
  • 同事 W 想到可以快取 / (根目錄也就是第一頁)的資料,但是我想太多以為官方測試會故意新增刪除再進入首頁,認為沒什麼用而沒去實作。最後回去看 log 發現評分程式看起來會故意重複進入首頁,下次要記得看看 access log。
  • 本地開發環境建置的練習和假設不太足夠,花了同事大概兩三小時在建置但我們也沒用到。
  • 因為自己太過心急,常常會想撈過界去幫忙,造成兩三人同時解一個問題,以後分工後應該謹守自己本份...0rz。

希望明年還有機會參加呀!