狀態update:
1. 光纖申請了固定IP – 122.116.180.22
2. crawler做了很多的改善，主要針對中文網頁抓取時，如何聰明的判斷他的編碼，以免在後續轉成utf-8的時候，造成亂碼。因為這部分的改良，才發現很多網站有以下的缺失：
a. 關於meta http-equiv, 例如<meta http-equiv=”content-type” content=”text/html; charset=iso-8859-1″>，常見的錯誤是寫了兩次，或者charset寫錯，或者是沒寫，或者是位置放太後面。
b. web server設定中，在response時沒有告知文件編碼 也就是 response.content_type中只會看到 text/html，看不到 charset。
如果1裡面沒寫meta，2的web server又不告知編碼，該文件又沒有宣告任何的 encoding，除了能判斷是否是unicode文件外，其他編碼目前就判斷不出來了（例如big5, euc-kr, euc-jp, gb2312….)。這種網頁居然也很多。
3. 全文搜尋引擎開始實做horizontal Partitioning。為了效能與擴展性考量。並加入自動化indexing的機制。
4. 122.116.180.22/search可以看到目前的開發階段的內容。
5. 122.116.180.22/search/show_recent可以看到最新爬進來的網頁。
這都只是一個thread的Ror Ap，不用想他會多快。還是在開發測試階段。
做了搜尋引擎的prototype建立，感覺Google的優勢是：
crawler的數量，計算效能與頻寬真的很大，他可以 用 60MB/ sec的傳輸速度去對一個網站做indexing（這是實際觀察到的案例）。相當於是開了多個crawler去＂攻擊＂一個網站，短短十五分鐘內，Google可能就能將數十萬的網頁帶走index。
用一台1.5G ram的舊機器，爬了一個晚上，差不多才能抓最多十萬個網頁，每秒抓取的資料量不會超過500k。差別就在於：機器只有一小台；演算法須最佳化；以及頻寬不能比。
但Google的這個優勢，又不是完全無法模仿的，上述缺失皆可以透過良好的規劃解決，包括技術面與財務面，也難怪還是有創業者投入這塊做搜尋。更由於Google這種大到不容易做niche搜尋功能的公司，各種垂直搜尋引擎紛紛的出籠。
先寫到這裡，出去攀岩了。