5.1 小節是以 IoTtalk V1 伺服器為測試環境，而 IoTtalk V1 是 HTTP 架構，進 行不同條件下的裝置端反應延遲測試。以下將會探討 ESM 拉動週期、本地端與遠 端伺服器、使用 Wi-Fi 與 Ethernet 對於裝置端反應延遲的影響。在架構圖圖 5-1 中，IoTtalk 伺服器(圖 5-1 (1))與 ESP8266(圖 5-1 (2))在同一個 Wi-Fi 路由器 (圖 5-1 (3))的 LAN 裡。此處 IoTtalk 伺服器是 V1 版本，即 HTTP/HTTPS 架構。
ESP8266 使用 Wi-Fi 或 Ethernet(圖 5-1 (4))與路由器連接。IoTtalk 伺服器用乙太網 路線(圖 5-1 (5))連接至路由器。
測試方式：(1)測試 1000 筆資料，每一筆測試資料之間間隔 500ms。因為我們希望 能減少伺服器的封包隊列對每一筆資料的處理速度的影響，同時也減少 ESP8266 記憶體的負擔。(2)Push 一筆資料後隨即 Pull 下來。
圖 5-1 LAN 中測試 ESM 運作週期之架構圖
以下四張圖(圖 5-2 ~ 圖 5-5)是 ESP8266 延遲測試結果的分布圖，將說明 ESP8266 在不同的情境下，ESM 拉動週期長短對延遲的影響，並且於 5.1.1 ~5.1.3 小節深入討論。
圖 5-2 使用 Wi-Fi，IoTtalk 伺服器在本地端，ESM 拉動週期對延遲的影響
圖 5-3 使用 Wi-Fi，IoTtalk 伺服器在遠端，ESM 拉動週期對延遲的影響
圖 5-4 使用 Ethernet，IoTtalk 伺服器在本地端，ESM 拉動週期對延遲的影響
圖 5-5 使用 Ethernet，IoTtalk 伺服器在遠端，ESM 拉動週期對延遲的影響
ESM 拉動週期的影響
5.1.1 小節要比較的是 IoTtalk V1 伺服器(圖 5-1 (1)) 的 ESM 拉動週期對 ESP8266 反應時間的影響。
ESM 負責處理裝置端 Push 與 Pull 到伺服器的資料。在 IoTtalk V1 的架構下，ESM 週期性的檢查是否有裝置端 Push 新的資料到伺服器端，而這個週期就是 ESM 拉 動週期(Pulling Period)。
ESM 拉動週期越短，Push 到伺服器端的資料就越快地被處理。反之 ESM 拉動週 期越長，資料就會比較慢被處理，但是伺服器的負擔會比較小，沒有執行時伺服 器就是處於閒置的狀態，可以隨伺服器的硬體規格，及使用情境的需求進行調 整。
因此我們將測量，當 ESM 拉動週期設為 10、30 與 50ms 時，ESP8266 Push 一筆資 料到 IoTtalk 伺服器後再 Pull 同筆資料回來，所需多少時間，此段時間就代表著 ESP8266 對於 IDF 所 Push 到 IoTtalk 伺服器的資料作出反應所需的時間，單位為毫 秒（ms）。
在我們的測試環境中，我們先測量網路中封包的延遲及 ESP8266 執行 Push、Pull 程式碼所需的時間。(1)ESP8266 與伺服器之間網路的平均延遲為 2.5ms。
(2)ESP8266 各執行一次 Push 與 Pull 的指令平均合計需要 30ms。
圖 5-6 的結果為圖 5-2 ~ 圖 5-5 分布圖所計算出的平均延遲。圖 5-6 測試結果是 ESP8266 在不同的測試環境下，受 ESM 拉動週期對於延遲的影響的平均結果。由 圖 5-6 可以明顯的看出，ESM 拉動週期越高，ESP8266 的延遲就越高，且在四種 測試環境中，都呈現同樣的走勢。
圖 5-6 ESP8266 在不同測試環境下之 ESM 拉動週期對延遲的影響結果
更深入的探討圖 5-3，可以從圖中看出發生頻率最高的延遲時間點約是 ESM 週
期再加上 40ms。40ms 非常接近執行 Push 與 Pull 程式碼的執行時間與網路中 Ping 看得出來，ESP8266 在各種測試環境中，使用 Wi-Fi 的平均延遲都比使用 Ethernet 時來得低。因為 ESP8266 本身就是一顆具有 Wi-Fi 功能的微控制器(MCU)，所以 ESP8266 使用 Wi-Fi 功能的行為是發生在晶片內部。相較於使用 Ethernet 是使用外 接模組的方式，ESP8266 使用 SPI 協定與 Ethernet 模組通訊，與 Ethernet 模組的通 訊時間就要比使用 Wi-Fi 高得多。在我們的實驗中使用 Wi-Fi 執行一次 Pull 程式
碼約需 17ms，而使用 Ethernet 執行一次 Pull 程式碼約需 27ms。
另外由圖 5-9 我們將 ESP8266 連到本地端 IoTtalk 伺服器，ESM 拉動週期設定為 10ms，比較 Wi-Fi 與 Ethernet 延遲的分布。可以看出，Wi-Fi 的測試結果相較於 Ethernet 顯得相當離散，原因如下。第一點，因為 ESP8666 目前只能使用 2.4G 頻 段，在生活中常見的藍芽裝置也使用 2.4G 頻段，容易干擾 Wi-Fi。而 Ethernet 因 為是使用有線通訊所以比較不容易被干擾。第二點是 Wi-Fi 傳輸資料的過程中還 有相關的無線調變技術，而有線通訊從裝置端傳輸到路由器的過程穩定許多。
使用者可以依據自身需求選擇通訊方式。如果使用者想要減少佈線，那我們會建 議使用 Wi-Fi。若使用者在的環境干擾很嚴重，那會建議使用 Ethernet 通訊。
若是像智慧農場的應用情境，因為都有乙太網路供電（Power over Ethernet，簡稱 PoE）了，所以我們會建議在接近農地附近放置一台 Wi-Fi 路由器，供 ESP8266 使用 Wi-Fi 連上網。而 ESP8266 的電力來源，因為我們要控制的裝置應該都有電 力，因此要供電給 ESP8266 就變得容易。而且如果希望一個 ESP8266 要控制多個 裝置的話，使用 Ethernet 的話會佔據太多腳位，因此我們會建議智慧農場的環 境，使用 Wi-Fi 會是比較好的方案。
圖 5-8 ESP8266 Wi-Fi 與 Ethernet 平均延遲比較圖
圖 5-9 ESP8266 使用 Wi-Fi 與 Ethernet 的延遲分布圖
ESP8266 與 Arduino YUN 比較
此節將比較 Arduino YUN 與 ESP8266 在不同的連網方式(Wi-Fi、Ethernet)、不 同的 IoTtalk 伺服器位置(本地端、遠端)、不同的 ESM 拉動週期(10、30、50ms)的 條件下，對封包反應延遲的影響，測試方式與 5.1 節相同。
由圖 5-10 可以看出 Arduino YUN 與 ESP8266 的性能實際上並沒有太大的差 距。
第一點要解釋的是 Arduino YUN 與 ESP8266 的硬體效能差異，在 ESM 拉動週期較 短 （10ms）的設定條件下，因為伺服器端已經很快地將資料處理好了，所以延 遲主要取決於裝置端運作的速度，網路延遲或者等待資料被伺服器端處理的時間 相對較短。所以可以看得出來 Arduino YUN 的延遲比 ESP8266 短一些，我們認為 這是硬體效能上的差異，在我們的測試中，Arduino Yun 進行一次 Pull 資料（不 論有無得到經 ESM 處理好的資料）約需要 5ms，而 ESP8266 約需要 17ms。當 ESM 拉動週期較大（50ms）的時候，因為伺服器端還沒有處理 Push 到伺服器的 資料，因此裝置端沒有辦法 Pull 到新資料，裝置端必須多次的 Pull，直到 ESM 拉 動週期到後，ESM 處理完資料，裝置端才能夠 Pull 到新資料。這時候 Arduino YUN 與 ESP8266 的效能差異的影響就會變小，因為不管裝置端處理的多快，都必 須等待伺服器端 ESM 處理完，因此 ESM 拉動週期為 50ms 時，每一個測試條件
的延遲結果大約都是 ESM 拉動週期 50ms 加上執行一次 Pull 所需時間的總和。
圖 5-10 ESP8266 與 Arduino Yun 比較 Wi-Fi 與 Ethernet
第二點要比較的是 Wi-Fi 與 Ethernet。在 Arduino YUN 上，使用 Ethernet 都比 使用 Wi-Fi 的延遲更低，Ethernet 比 Wi-Fi 更穩定延遲更低，因為 Arduino YUN 是 官方整合調整過的開發板，效能比較穩定，且網路晶片的效能也比較好。
而 ESP8266 使用 Wi-Fi 的延遲比 Ethernet 更低，因為 ESP8266 晶片本身只有整合 Wi-Fi，而 Ethernet 使用的是外部的模組，所以 ESP8266 晶片需要額外與 Ethernet 模組的溝通時間。雖然延遲結果較差，可是 Ethernet 模組的價格相當低廉，因此 效能也反映在價格上。
第三點要比較的是伺服器是在本地端或者遠端。如圖 5-11 非常明顯的，在 使用 Wi-Fi 與 ESM 拉動週期設定為 10ms 的情況下，本地端的延遲都比遠端的更 低。
圖 5-11 ESP8266 與 Arduino Yun 比較本地端與遠端
第四點要比較的是不同的 ESM 拉動週期的影響如圖 5-12，在 5.1.1 小節已經
有詳盡的討論。隨著 ESM 拉動週期越長，反應的時間也會越長。
圖 5-12 ESP8266 與 Arduino Yun 比較 ESM 拉動週期
MQTT 架構
效能測試
此小節將重複 5.1 節之測試架構圖 5-1，測量 ESP8266 連到 IoTtalk V2 伺服器 在各種條件下的效能。因為 ESM 改為使用 MQTT 架構，而 MQTT 是由事件觸發 並不是使用程式迴圈式的掃瞄，因此沒有 ESM 拉動週期這項參數。受惠於 MQTT 協定，資料是由經紀人(Broker)主動送給訂閱者(Subscriber)，即 IoTtalk 伺服 器主動將資料送給裝置端，所以訂閱者可以更即時的收到最新的資料。此小節我 們僅測試伺服器所在位置(本地端、遠端)及使用 Wi-Fi 或 Ethernet。
首先要比較 Wi-Fi 與 Ethernet 的差距，由圖 5-13 所示，Wi-Fi 跟 Ethernet 的差 距非常巨大，不管伺服器是在本地端或者遠端，使用 Wi-Fi 的平均延遲大約是 6 毫秒左右，而使用 Ethernet 時的平均延遲大約是 42 毫秒左右。
這樣的差異原因是因為 Ethernet 是使用外掛模組，而 ESP8266 本身就支援 Wi-Fi 功 能。因為操作 Wi-Fi 功能的速度比較快，可以將 MQTT 事件觸發式協定的優勢發 揮得更好。但是使用 Ethernet 的話，因為受限於硬體效能限制，即便伺服器很快 就將資料送給 ESP8266，但是 ESP8266 操作 Ethernet 模組還是很花時間，所以延遲 就會被拖慢。
圖 5-13 IoTtalk V2, Wi-Fi vs Ethernet
接著我們要比較本地端與遠端的差異，如圖 5-14 所示。不管是使用 Wi-Fi 或 Ethernet，本地端與遠端的差異都非常的小，使用 Wi-Fi 時，本地端的延遲平 均約 6.05 毫秒，而遠端的延遲平均約 7.58 毫秒。而使用 Ethernet 時，本地端的 延遲平均約 42.76 毫秒，而遠端的延遲平均約 43.91 毫秒。差距非常小，接近於 網路中傳播速度的差距。
圖 5-14 IoTtalk V2, Local vs Remote
ESP8266 與 Arduino Yun 比較
此小節我們將比較 ESP8266 與 Arduino Yun 在 IoTtalk V2 伺服器上的表現，如 圖 5-15 所示。結果可以分成兩類來看，即 Wi-Fi 與 Ethernet。
在使用 Wi-Fi 時，ESP8266 比 Arduino Yun 有更低的延遲，而兩者本地端的延遲都 比遠端低。因為 ESP8266 沒有作業系統，而 Arduino YUN 有。ESP8266 僅僅只是 單晶片執行程式碼，不用透過作業系統操作 Wi-Fi，因此更接近底層硬體，所以 效能更好。
在使用 Ethernet 時，Arduino YUN 比 ESP8266 有更低的延遲，而兩者本地端的延遲 都比遠端低。Arduino YUN 的 Ethernet 整合的程度比較高，使用的晶片效能也比較 好，所以 Arduino Yun 使用 Ethernet 時延遲的結果比 ESP8266 低。
圖 5-15 IoTtalk V2, ESP8266 vs Arduino YUN