SNA 与 TCP/IP
TCP/IP 的可缩放性不如事务集成商 (TI) 的 SNA，但 TCP/IP 在其他方面更有效，例如文件传输和数据访问 (OLEDB 测试) 约 10-15%。 此外，IBM 对 TCP/IP 的认可简化了企业网络基础结构，并简化了与 Internet 的互操作性。
为了研究 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 在整个负载范围内实现稳定的响应时间，因此可实现更高的可伸缩性。
为了分析与 TCP/IP 相比 SNA 的优越可伸缩性，Microsoft 在主干 LAN 上绘制了每秒帧数的图表。 SNA 维护其从事务到事务的会话，而 TCP/IP 必须为每个事务建立和销毁 TCP/IP 连接。 与 SNA 相比，这会导致通过上链路传输的帧数更多。 在我们的测试中，100baseT 以太网 LAN 没有成为瓶颈，但如果 TI 服务器和主机之间的链接速度较慢，这可能会成为关键问题。 在任何情况下，TCP/IP 连接和断开连接都会为两端生成一些额外的中断。
其他分析表明，TCP/IP 上行链路比 SNA 上行链路具有优势，而 SNA 上行链路可能成为实际部署中的决定因素。 使用 SNA 向上链接时，TI 自动化服务器必须承受的上下文切换量几乎是 TCP/IP 上行链路情况的两倍。 这是因为使用 SNA 时，消息首先从 TI 传递到 SNA 服务器节点，然后传递到 SNA 链接服务。 这些是单独的进程，因此存在进程到进程通信和上下文切换。 使用 TCP/IP 时，不会发生这种情况;TI 将消息直接传递到 NDIS 驱动程序。 在发生额外业务逻辑处理的服务器上，可能会发生大量上下文切换，导致吞吐量和可伸缩性受到影响。