Skip Navigation Links首頁 > 產品與服務 > 技術分享

技術分享

[效能實測]HPE NonStop X 高效實例與系統轉移考量

作者/黃俊源
前言

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

 

回上一頁