[效能實測]HPE NonStop X 高效實例與系統轉移考量
作者/黃俊源
前言
HPE Integrity NonStop X型主機是目前最新推出的NonStop系統，如同下面圖示，以往新一代NonStop系統效能較前一代均有顯著提升，筆者針對NonStop X進行相關效能測試，以實際測試結果來觀察NonStop X高效性能；並依據此次測試過程將測試程式由NB-series升級到NonStop X的實際經驗與各位分享。
《圖一》
- 測試環境
1.主機環境NonStop NS7 X1與NB54000c。
2.以C語言編譯，native mode。
3.訊息傳送量為10000筆。
4.測試變數，分別依照CPU、IPU以及訊息長度做測試驗證。
- 相同CPU及IPU的測試結果
《圖二》
《圖三》
《圖四》
- 相同CPU及不同IPU的測試結果
《圖五》
《圖六》
《圖七》
- 不同CPU的測試結果
《圖八》
《圖九》
《圖十》
二、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.測試變數，分別依照不同訊息長度做測試驗證。
《圖十一》
- 測試結果
1.當訊息長度小於4K時，效能約維持2.4倍之差距；隨著訊息長度的放大，效能差距越大。56K之訊息長度將放大到5倍。
《圖十二》
《圖十三》
三、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倍。
《圖十五》
《圖十六》
四、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平均值，其對照如下：
《圖十八》
《圖十九》
《圖二十》
《圖二十一》
系統移轉考量
下列為各系統版本升級時，針對應用程式是否需重新編譯彙整之對照表：
《圖二十二》
針對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