SNA 與 TCP/IP

TCP/IP 與交易整合器 (TI) 無法調整,但在 OLEDB 測試) 上,TCP/IP 在其他領域中更有效率,例如檔案傳輸和資料存取 (大約 10-15%。 此外,IBM 簽署 TCP/IP 可簡化公司網路基礎結構,並讓您更容易與網際網路互通。

為了研究 TI 與 TCP/IP 作為上流連結通訊協定與 SNA 的效能差異,Microsoft 執行了壓力測試,其中設定的唯一變更是上行通訊協定。 SNA 測試已設定為使用 SelectionHint 屬性設定,因為這是 TCP/IP 上行連結所執行的相同程式。 如需屬性效果 SelectionHint 的詳細資訊,請參閱 使用 SelectionHint 屬性進行遠端環境選取

Microsoft 發現 TCP/IP 與 SNA 一樣快速,分析平均回應時間做為交易的函式。 事實上,當負載低於每秒 100 筆交易時,TCP/IP 的速度比 SNA 快, (tps) 。 對於某些部署,也就是典型的作業範圍。 隨著負載增加,無連線 TCP/IP 上行連結會開始讓回應時間變慢,並在 500 tps 裁剪最高效能。 SNA up-link 可在整個負載範圍內啟用穩定的回應時間,因此可達到更高的延展性。

為了分析 SNA 相較于 TCP/IP 的較佳延展性,Microsoft 會透過骨幹 LAN 繪製每秒的畫面格。 SNA 會維護其會話,從交易到交易,TCP/IP 必須為每個交易建立並終結 TCP/IP 連線。 這會導致相較于 SNA,透過上行連結傳輸更多畫面格。 在我們的測試中,如果 TI 伺服器與主機之間的連結速度較慢,100baseT 乙太網路 LAN 不會成為瓶頸,但這可能會成為重大問題。 在任何情況下,TCP/IP 連線和中斷都會針對兩端產生一些額外的中斷。

其他分析顯示 TCP/IP 上行連結透過 SNA up-link 的優點,可能會成為真實世界部署中的決定因素。 當您使用 SNA up-link 時,TI 自動化伺服器必須與 TCP/IP 上行連結案例相比,幾乎需要兩倍的內容切換量。 這是因為使用 SNA 時,訊息會先從 TI 傳遞至 SNA 伺服器節點,然後再傳遞至 SNA 連結服務。 這些是個別的進程,因此有進程對進程通訊和內容切換。 若是 TCP/IP,則不會發生此情況;TI 會將訊息直接傳遞至 NDIS 驅動程式。 在發生其他商務邏輯處理的伺服器上,可能會發生許多內容切換,而輸送量和延展性會受到影響。

另請參閱

交易整合器效能指南