netmiko

 

https://zhuanlan.zhihu.com/p/546340640

https://zhuanlan.zhihu.com/p/541592293

3.6.7 登錄與執行速度比較慢

netmiko和設備交互，都是通過write_channel寫入命令到通信隧道中，然後以某種頻率去隧道中循環讀取數據。所以在網絡條件恆定的前提之下，適當調小停頓等待時間，進而調高隧道中讀取的頻率，可以讓回顯儘早收集齊，完成相關操作的確認。而提高整個頻率就是靠延遲因子的調整，我們之前講解的延遲因子很多都是方法內部的延遲因子，實際上netmiko的延遲因子不是隻有這一個，或者說，這個延遲因子只是局部延遲因子（大部分局部的延遲因子默認值都是1），還有一個隱藏的全局延遲因子。只要是和設備有相關命令行交互的方法，大都會有delay_factor這個參數。但是並不是由這個局部延遲因子單獨決定最終的實際延遲因子進而控制頻率的，netmiko有一套比較靈活的延遲因子選舉機制：

​ 在初始化連接的時候，有一個全局延遲因子global_delay_factor（默認值爲1）和fast_cli模式（默認值爲False）。

​ 當不開啓fast_cli模式的時候，netmiko在各個方法內選擇局部延遲因子delay_factor和全局延遲因子global_delay_factor中的較大者。所以我們單純調整任何一個延遲因子不得其法可能都不會有效果。

​ 當開啓fast_cli模式的時候，netmiko會認爲用戶需要優化讀取數據的性能，需要提高讀取信息的頻率，這時它會選擇局部延遲因子delay_factor和全局延遲因子global_delay_factor中的較小者。

​ 以上行爲是netmiko內部的select_delay_factor方法的基本邏輯，各個方法執行的時候基本都先調用此方法來判定最終的延遲因子，比如取消分頁的時候，在取消分頁方法內部調用select_delay_factor方法，大多數設備給其賦值局部延遲因子是1，這個時候我們單純調整全局的延遲因子，並不會提高效率。

​ 爲了調高讀取隧道信息中的頻率，我們調小程序停頓等待的時間，調小延遲因子是我們的“出路”。結合上面的邏輯，爲了提高登錄速度，fast_cli調整爲True，開啓快速模式，全局延遲因子global_delay_factor調小，比如筆者設置爲0.1。有些設備不調整參數，使用默認值，筆者的模擬器設備華爲CE交換機登錄耗時大約8秒甚至更久，但是調整上面的參數後，時間可以縮短到一秒。

from netmiko import ConnectHandler
import time
# 設備連接信息 開啓fast_cli快速模式，全局global_delay_factor延遲因子調小（默認值爲1）
dev = {'device_type': 'huawei',
       'host': '192.168.137.201',
       'username': 'netdevops',
       'password': 'Admin123~',
       'port': 22,
       'timeout': 180,
       'fast_cli':True,
       'global_delay_factor':0.01,
       'session_log': 'session.log',
       }
print(time.time())
with ConnectHandler(**dev) as conn:
       print(time.time())
       print(conn.is_alive())

以上方法實際上也會讓執行速率變快，但是這塊有時候在感官上並不是特別明顯。全局延遲因子已經調整的比較小的情況下，各類發送命令或者配置的延遲因子也可以無需調整。