前言

HPE Integrity NonStop X型主機是目前最新推出的NonStop系統，如同下面圖示，以往新一代NonStop系統效能較前一代均有顯著提升，筆者針對NonStop X進行相關效能測試，以實際測試結果來觀察NonStop X高效性能；並依據此次測試過程將測試程式由NB-series升級到NonStop X的實際經驗與各位分享。



NonStop X測試案例說明

一、Latency improvement – IPC

• 測試環境
  
  1.主機環境NonStop NS7 X1與NB54000c。
  
  2.以C語言編譯，native mode。
  
  3.訊息傳送量為10000筆。
  
  4.測試變數，分別依照CPU、IPU以及訊息長度做測試驗證。



• 相同CPU及IPU的測試結果
  
  
  
  《圖二》
  
  
  1.當在相同CPU及IPU的情況下，4K以下的訊息長度，NS7 X1相較於NB54000c其效能提升約1.7倍。56K之訊息長度其效能提升約1.15倍。
  
  
  
  《圖三》
  
  
  2.兩者曲線圖如下：
  
  
  
  《圖四》



• 相同CPU及不同IPU的測試結果
  
  
  
  《圖五》
  
  
  1.當在相同CPU不同IPU的情況下，NS7 X1相較於NB54000c其效能平均提升約2.6倍。128至56K之訊息長度其效能提升差異不大均維持在2.4~2.7之區間。
  
  
  
  《圖六》
  
  
  2.兩者曲線圖如下：
  
  
  
  《圖七》



• 不同CPU的測試結果
  
  
  
  《圖八》
  
  
  1.當在不同CPU的情況下，NS7 X1相較於NB54000c其效能隨著訊息長度的放大，其效能提升亦隨之增加。128至56K之訊息長度其效能提升從3倍提升到14倍。
  
  
  
  《圖九》
  
  
  2.兩者曲線圖如下：
  
  
  
  《圖十》

二、Latency improvement – Informatica Ultra Messaging

• 測試環境
  
  1.主機環境NonStop NS7 X1與NB54000c。
  
  2.以C語言編譯，native mode並且使用Informatica Ultra Message library(註一)。
  
  3.lbmping-pong (RTT)。
  
  4.訊息傳送量為10000筆。
  
  5.測試變數，分別依照不同訊息長度做測試驗證。
  
  
  
  《圖十一》
  
  
  註一、 Informatica Ultra Message Library為低延遲middleware library，提供通訊底層訊息傳輸的控制，用戶可以無需考量socket底層管理，僅需依middleware的回覆作相對應的控制，一方面滿足低延遲的需求，另一方面亦簡化程式開發者的處理。



• 測試結果
  
  1.當訊息長度小於4K時，效能約維持2.4倍之差距；隨著訊息長度的放大，效能差距越大。56K之訊息長度將放大到5倍。
  
  
  
  《圖十二》
  
  
  2.兩者曲線圖如下：
  
  
  
  《圖十三》

三、Throughput improvement – Informatica Ultra Messaging

• 測試環境
  
  1.主機環境NonStop NS7 X1與NB54000c。
  
  2.以C語言編譯，native mode並且使用Informatica Ultra Message library。
  
  3.Source與Receiver (單向傳輸)。
  
  4.訊息傳送量為100000筆。
  
  5.測試變數，分別依照不同訊息長度做測試驗證。
  
  
  
  《圖十四》



• 測試結果
  
  1.當訊息長度小於4K時，效能約維持3倍之差距；隨著訊息長度的放大，效能差距越大。56K之訊息長度將放大到4.8倍。
  
  
  
  《圖十五》
  
  
  2.兩者曲線圖如下：
  
  
  
  《圖十六》

四、Application porting

• 測試環境
  
  1.主機環境NonStop NS7 X1。
  
  2.混和環境應用程式，包含Linux上的Client、Gateway再到NSK端的CLIM與NonStop X上的server 程式。
  
  3.以C語言編譯，native mode並且使用Informatica Ultra Message library。
  
  4.訊息傳送量為100000筆。
  
  5.訊息長度64 bytes。
  
  6.測試變數，分別依照不同流量控制每秒1000至10000筆訊息測試。
  
  
  
  《圖十七》



• 測試結果
  
  1.以每秒1000筆之流量測試，比較NB54000c與NonStop NS7 X1 Client端所統計的RTT平均值，其對照如下：
  
  
  
  《圖十八》
  
  
  NonStop NS7 X1相較於NB54000c提升約7.5倍。
  
  
  
  《圖十九》
  
  
  2.若以NonStop NS7 X1每秒從1000至10000筆訊息流量測試，測試結果如下表：
  
  
  
  《圖二十》
  
  
  
  
  《圖二十一》
  
  
  從Gateway RTT以及Client RTT可知，於每秒10000筆的流量下，尚未觸及NonStop NS7 X1之瓶頸，故Client RTT仍可維持在0.3 ms以下。

系統移轉考量

下列為各系統版本升級時，針對應用程式是否需重新編譯彙整之對照表：



針對TNS 程式，基本上不需重新編譯即可直接執行，不過針對native mode 程式，則是均需重新編譯才可於系統上運作。

一、執行環境說明

• 相同部分
  
  1.Native開發環境如同TNS/E 開發環境，C、C++、COBOL以及pTAL語言均支援。
  
  2.編譯器支援32-bit環境。
  
  3.編譯器針對OSS程式支援64-bit環境。
  
  4.支援PC上的cross-compilation。
  
  5.一般而言從TNS/E native mode升級到TNS/X native mode不需要針對source code做修改。
  
  6.如果從TNS升級到TNS/X所需更改的部分，如同TNS升級到TNS/E。
  
  7.TNS開發環境如同在H版本或是J版本。



• 改變部份
  
  1.編譯工具使用不同的指令與選項。
  
  2.不同的除錯工具 einspect / xinspect (Visual Inspect已不支援，改由NSDEE取代)
  
  3.TNS/X所使用的public library與TNS/E的public library具備不同的名字。
  
  
  • 32 bit library ZnnnDLL (H及J版本使用) XnnnDLL (L版本使用)
  
  
  
  • 64 bit library YnnnDLL (H及J版本使用) WnnnDLL (L版本使用)
  
  
  
  
  《圖二十三》
  
  
  4.通訊協定中，如果不是架構在CLIM下，包含SNAX，legacy IPv6、ATM、X.25均不支援。
  
  5.NonStop Edition(ETK) 開發環境L版本已經不支援，由NSDEE取代。
  
  6.NonStop TUXEDO 應用程式於L版本將不支援。
  
  7.TNS/R(MIPS)開發工具(包含nld、nmc、nmcpp、nmcobol等)將不支援。



• J和H版本到L版本升級方式
  
  1.TNS/E native mode升級到TNS/X native mode：通常僅需要使用TNS/X native compiler重新編譯即可。
  
  2.J或是H版本的TNS mode升級到L版本的TNS mode：可以直接使用原有的TNS object code在L版本上直接執行。如同J以及H版本，L版本支援TNS object 的轉譯以及加速模式。L版本將持續支援Guardian TNS編譯器及相關工具。
  
  3.J或是H版本的TNS mode升級到L版本的native模式：如同TNS 轉換成native模式。



• 開發環境說明
  
  1.L版本主要支援TNS/X native開發環境與執行環境。同時亦支援TNS/E native開發環境，不過並不支援TNS/E object file的執行。
  
  2.TNS環境
  
  
  • 提供新的accelerator。
  
  
  
  • 新的TNS viewer工具TNSVUX以便查看TNS object相關資訊。
  
  
  
  • Visual Inspect於L版本已不支援。
  
  
  
  • TNS debuger不支援舊的snapshot檔案。
  
  
  
  • SQL/MP程式必須透過SQLCOMP重新編譯。
  
  
  3.TNS/X native環境
  
  
  • public library的命名與TNS/E不同。
  
  
  
  • 提供xinspect以及NonStop Development Environment for Eclipse(NSDEE)，NonStop Edition(ETK)開發環境將不支援。
  
  
  
  • TNS/X native debugger將不支援舊的snapshot file。
  
  
  
  • TNS/R(MIPS)等開發環境的工具(包含nld、nmc、nmcpp、nmcobol等)將不支援。
  
  
  4.TNS/E環境
  
  
  • 支援使用TNS/E 開發工具，可以在L版本上編譯及連結TNS/E native 程式。
  
  
  
• 升級注意事項
  
  1.C/C++應用程式
  
  
  • 編譯時如果有指定TARGET或是-Wtarget則須從TNS/E變更為TNS/X。
  
  
  
  • 編譯時如果有指定 -Weld或是-Weld_obey則須更改為 -Wxld或是-Wxld_obey。
  
  
  
  • C與C++ main routine object file與run-time library隨著不同應用需做調整。
  
  
  
  • 如果有使用test macro確認平台版本，需做調整
    　　‧TNS　0
    　　‧TNS/E　2
    　　‧TNS/X　3
  
  
  
  • PRAGMA預設值變更
    　　‧ELD改成XLD。
    　　‧TARGET更改為TNS/X。
  
  
  
  • c89 c99變更的flag
    　　‧-Weld變更為 –Wxld。
    　　‧-Weld_obey變更為-Wxld_obey。
    　　‧-Wtarget新增tns/x。
  
  
  2.COBOL應用程式
  
  
  • Native compiler工具由原來ECOBOL改成XCOBOL。
  
  
  
  • COBOL RTL從原來ZCOBDLL拆成XCOBDLL及XCOBADLL，這部分不影響編譯操作，XCOBDLL有設定與XCOBADLL的關聯性，因此LINKER會自動連結。
  
  
  3.pTAL應用程式
  
  
  • Native compiler工具由原來EPTAL改成XPTAL。
  
  
  
  • XPTAL設定雙態元件為_TNS_X_TARGET_以取代TNS/E的_TNS_E_TARGET_。
  
  
  4.與NB、NS系列並存AP跨node之運作考量
  
  
  • NB與NS系列需要安裝T9205H01ADU的TACL版本，才可以支援遠端於NonStop X-series執行code 500的相關程式。

結論

從上述測試數據得知，NonStop X除了CPU本身效能提升以外，因為內部傳輸採用InfiniBand FDR (56Gbps)，針對CPU之間、CPU與周邊設備之間的傳輸，都大幅提升效能，相較於NB系列，CPU之間或是與周邊設備之間的傳輸延遲時間更有顯著的改善，尤其是訊息越長，提升效果越大，甚至於橫跨CPU之間的IPC最大可達14倍以上之差距。

針對應用程式升級部分，整體上程式碼幾無須更改，僅需調整相關編譯用的工具名稱，即可將原有NonStop應用程式輕易移轉到NonStop X。

<作者目前服務於凌群電腦NSK服務總處>


參考資料

1.Mark Pollans, HPE Integrity NonStop Technical Boot Camp It’s the Hardware

2.L-Series Application Migration Guide