---
title: 591 定期爬蟲實驗分析 Round I
tags: Rentea
---
# 591 定期爬蟲實驗分析 Round I

這項實驗是為了決定更新 591 的爬蟲的執行頻率而設計，總共使用了 5、15、30、60 分四種頻率當變數，從 2019-10-19 執行爬蟲至 2019-11-04 ，共計 2 週，經歷了兩次的平日與假日，希望可以找出更新完整，而且失敗率低的參數。

相關程式碼以及實驗設計，請參考 [Github Issue](https://github.com/rentea-tw/rentea-crawler/issues/4) 。

## 實驗數據觀察

實驗包含了三項分析，分別是

1. 執行時間分析 / Execution Time Analysis
- 判斷每個參數的程式是否都能在時限內執行完畢，避免重複執行或對資料更新頻率有錯誤的期待
3. 重複物件分析 / Duplication Detection Analysis
- 判斷同一組執行頻率內，每次執行所重複抓到的物件有多少
- 因為爬蟲的設定是只抓新增的物件，所以重複率應該要幾乎沒有，才是合乎期待的
4. 物件完整度分析 / Equivalency of Different `minuteago` Job
- 透過比較不同執行頻率的物件集合，判斷是否有抓到所有新增物件
- 理想上同樣的時間範圍內抓到的物件集合，應該要差不多

實驗的原始資料可見此 [sql](https://drive.google.com/open?id=1RJy5dmZKKRg0Ztwkr49U1O_3SNQzh-G6)。

### 執行時間分析 / Execution Time Analysis

| | Test[05] | Test[15] | Test[30] | Test[60] |
|-----------------|--------------|------------|--------------|----------|
| 執行次數 | 137 | 1469 | 741 | 371 |
| 跳過次數 | 4397 | 52 | 0 | 0 |
| 耗時平均（分） | 11.5 | 12.3 | 14.1 | 18.0 |
| 耗時中位數（分） | 11.4 | 12.2 | 13.4 | 16.7 |
| 耗時分佈（分） | 13.0 - 8.1 | 17.2 - 10.6 | 23.3 - 10.5 | 35.8 - 10.8 |
| 耗時標準差（分） | 0.7 | 1.2 | 2.8 | 6.0 |

觀察：

1. `Test[05]` 因為不明原因，爬完物件後爬蟲會無法結束，導致接下來的測試，由於存在同週期的測試，在系統裡而被跳過。
1. 在尖峰時刻，`Test[15]` 有可能會花超過 15 分鐘爬資料，因此超過執行週期。
2. 週期在 `Test[30]` 以上的測試，都可以順利執行完畢，最短的執行時間都在 10 分鐘左右，表示 591 在冷門時段，只需要 10 分鐘就可以抓完所有物件，大約是 250 筆物件。
3. 從最長耗時可以發現，物件刊登的時間分佈沒有太集中，因為 `Test[60]` 只有 `Test[15]` 耗時的兩倍，但週期則有四倍，可能是指數型的關係。

小結：

1. 使用 `Test[30]` 是較保險的參數選擇，因為比最長耗時多了 33% 的時間，即便是連假過後的刊登高峰，也還是有餘裕可以處理。
2. 爬蟲依然需要防止同時執行，當發現前次爬蟲尚未結束時，下次爬蟲須改變 `minuteago` ，涵蓋上次未爬的時間，從 `30` 變成 `60` ，即使在刊登尖峰，也可以在一兩次延誤後修正回來，確定在最糟的情況下，物件清單每小時也會更新一次。

### 重複物件分析 / Duplication Detection Analysis

| 整體重複狀況 | Test[05] | Test[15] | Test[30] | Test[60] |
|------------------|--------------|------------|------------|----------|
| 總共找到物件數 | 3102 | 46037 | 48221 | 48458 |
| 執行次數 | 137 | 1469 | 741 | 371 |
| 每次的物件數平均 | 22.6 | 31.3 | 65.1 | 130.6 |
| 重複物件數 | 1575 | 2142 | 1934 | 1770 |
| 物件重複次數-平均* | 20.9 | 169.6 | 97.3 | 57.9 |
| 物件重複次數-中位數* | 13 | 99 | 66 | 44 |
| 物件重複次數-分佈* | 134 - 2 | 1468 - 2 | 740 - 2 | 371 - 2 |
| 物件重複次數-標準差* | 25.7 | 266.8 | 138.6 | 70.7 |

\* `物件重複`的定義是，在同測試週期的所有工作中，累計出現**超過** 1 次的物件

| 相鄰的執行重複率 | Test[05] | Test[15] | Test[30] | Test[60] |
|----------------|--------------|---------------|---------------|----------|
| 物件重複率-平均 | 47.9% | 45.4% | 41.4% | 37.1% |
| 物件重複率-分佈 | 55.5 - 41.6% | 56.0% - 32.8% | 55.3% - 28.5% | 53.2% - 20.7%
| 物件重複率-標準差 | 2.8% | 4.1% | 6.2% | 7.6% |

觀察：

1. Test[05] 因失敗次數過多，略過分析。
2. 重複次數差異極大，應該包含了不同的重複原因：
1. 重複次數的分佈狀況（以 Test[15] 為例，但[各次實驗都差不多](https://docs.google.com/spreadsheets/d/1mJDRzWKIAv4dWVVG9FXHIaGBUhPVAFz9LLUgf9Y-V4I/edit#gid=0)）
1. 中位數較平均低，可見大部分物件的重複次數偏低
2. 三種測試參數產生的重複次數分佈接相似，總物件數也相近，表示重複的原因和測試參數無關
3. 根據廣告篩選機制，所有實驗裡收集到的廣告*約有 1256 個
4. **類型 1 - 生意不好的廣告** - 大約有 60 個物件是高度重複，大概 2/3 的執行都會看到，其中 50 個物件是每次都有出現，明顯是連續兩週都還沒下架的廣告
5. **類型 2 - 生意好的廣告** - 大約有 1200 個物件是低度重複，而且重複次數和不同測試的執行次數成正比，可見也是廣告，只是投放時間在 10 小時 - 250 小時不等，大部分廣告在 90 小時左右結束
3. 相鄰執行的重複率平均都在四成左右，執行頻率越高的標準差越小，可見在非尖峰時間，廣告的佔比很大，如果可以事先確認廣告是否是在時限內建立的，最多可以省下四成的爬蟲執行時間，主要省下的是非尖峰時間的執行時間就是，但對尖峰的影響也有 20% - 30%

> \* 廣告的判斷方式為單次執行中，出現超過一次的物件，總計次數可用以下 sql 找到
> ```sql
> select count(*) from (
> SELECT house_id, sum(update_count) FROM taskhouse WHERE
> update_count > 1 group by house_id
> )
> ```

小結：

1. 絕大部分的重複，應該都是由廣告產生的，爬蟲本人與 591 API 回傳的資料沒有問題 XD
2. 需要增加廣告物件建立時間的篩選機制，可以省下尖峰 20% ，離峰 50% 的執行時間

### 物件完整度分析 / Equivalency of Different `minuteago` Job

| | Test[05] | Test[15] | Test[30] | Test[60] |
|------------------|--------------|------------|------------|----------|
| 每 1 小時爬到物件的涵蓋率平均/標準差 | - | 80.4% / 5.7% | 62.0% / 5.9% | 48.8% / 9.3% |
| 每 6 小時爬到物件的涵蓋率平均/標準差 | - | 96.7% / 5.0% | 95.9% / 5.3% | 88.4% / 7.2% |
| 每 12 小時爬到物件的涵蓋率平均/標準差 | - | 94.8% / 5.2% | 97.0% / 12.4% | 95.9% / 12.5% |
| 每 24 小時爬到物件的涵蓋率平均/標準差 | - | 93.5% / 4.6% | 96.3% / 11.1% | 96.5% / 10.8% |

觀察：

1. 驗證的時間長度越長，長週期的涵蓋率越高，不同週期的測試的涵蓋率也越一致。
2. 以 1 小時為單位驗證時， Test[15] 的物件數明顯比其他兩種週期多很多，但若對照`重複物件分析`，三者兩週內所抓到的不重複物件，總數是差不多的，表示 Test[15] 在執行時，會多抓到很多根本不存在的物件。
1. 但這個現象在驗證的時間拉長後幾乎改善，到 12 小時後幾乎消失。
2. 要嘛沒有這個問題了，要嘛不同週期都會定期碰到這個問題 XD
3. 重新檢查 `periodic591` 的物件篩選邏輯後發現，在碰到完全沒回傳物件（但可能有廣告）時，爬蟲會進入無窮迴圈，直到出現一筆已過期的物件才停下來（汗）。
1. 當測試週期越短時，越有可能碰到這個情況，這也有可能是 Test[5] 有大量無法結束的任務的原因之一。
2. 當這個情況發生時，廣告因為沒有建立時間的資訊，所以已然會被爬蟲拿來爬，導致雖然 minuteago 較短，但卻抓了較多物件的狀況發生。
3. 廣告佔了回傳物件裡相當高的比例，以每小時的統計為例，至少有三成的物件 (Test[15] - Test[60] 的量) 是長尾廣告，若能減少廣告的抓取量，就能加速爬蟲很多。

小結：

1. 找出避免抓取廣告，但仍能抓到刊登廣告的物件資訊的方法
2. 修正 `periodic591` 物件篩選邏輯的錯誤，[票已開好](https://github.com/rentea-tw/rentea-crawler/issues/8)
3. 重新執行一次爬蟲實驗，確定沒有其他問題 orz..