究竟网络环境对应用性能有影响吗？

medsonk

首先请大家看看一套测试方案：
分别在wifi、3g、2g环境下，点击对方头像，查看对方资料，记录下拉取完所有数据需要的时间。
然后等到下一个版本出来，开发说性能优化了，然后要我们用新版本再测一次。对比下时间是否减少。

我想问，这个时间可信吗？
即使是多次测试，上午的网速跟下午的网速也不一样，前半小时的网速跟后半小时的网速又不一样，2g网络这种差异最明显了。
而且主题是性能，一个软件的性能跟网速的快慢我认为是没有关系的。至少对于这种软件。
搞得好像是让我们在测试联通移动的网络，根本不是测软件性能。

大家侃侃大山，说说想法

lsekfe

首先请大家看看一套测试方案：
分别在wifi、3g、2g环境下，点击对方头像，查看对方资料，记录下拉取完所有 ...
medsonk 发表于 2013-8-27 21:51

    基础网络部分指物理的网络结构和链路，主要有下面几个方面的因素：

1.网络的速率和带宽。这是一个根本的问题，如果网络的基础设施不够快的话，那么其他都面谈。
2.通讯计算机之间的距离和路由。最基本的知识，在LAN内的应用程序就能够跑的飞快，因为基本上LAN的计算机第一个条件满足了，而且距离短，且路由跳数少，但对于WAN的应用程序来说距离和路由是决定程序性能的很重要的方面，一般来说距离越远，信息的传输延迟时间越长，而路由的跳数基本上与距离有关，但路由的路径却可以确定，那么选择一个好的路由（时延最小的）是必要的。时延的大小可以通过tracert或其他的工具来测量。
3.计算机的处理能力。一般情况下，CPU频率高的计算机处理起来要比CPU低的高，特别对于需要高速传输数据的应用程序，某个CPU频率可能是处理流量的极限，但使用相对频率高的CPU可能轻松处理。另外CPU的频率高低对程序的影响在发送和接收端都存在，如果接收端不能很快的从缓冲区中把数据取出来，那么发送端必然会收到0窗口的报告，从而停止等待对方的窗口恢复（TCP），造成本来可以利用的带宽被浪费。
那么在给定的基础网络部分之上怎么样尽量利用其发挥最大的性能着就属于网络应用程序本身编写的责任了，这也是很有讲究的，下面基本方面可以参考：

1.使用阻塞套接字。阻塞套接字可能会对应用程序的性能造成影响，在阻塞套接字时，程序必须等待SOCKET处理完毕或者出错后才返回，这段时间CPU就无聊的等待，对于非阻塞可以在这段时间做一些数据准备工作，一旦SOCKET可以用就立即发送数据，并行性更好。
2.频繁的调用send和recv。如果发送很很小的数据包且流量很大的时候（例如：每秒30000个150字节的包），而一次只发送一个包，就可能导致每秒中要调用30000次send函数，这个代价很大，因为每次调用send都要从用户态到核心态的switch，所以这个时候应该尽量减少send的调用次数，例如使用WSASend或用一个更大的发送缓冲区。对于recv也是同样的结果，最好使用一个较大的缓冲区来接收，然后使用内存COPY。实践发现，内存COPY比调用send或recv耗费的CPU时钟周期要少的多。
3.频繁的出错。对于在套接字不可用的时候调用send或recv函数，只会导致出错，而每出错一次就浪费一定的CPU周期，这个代价比较大，所以尽量保证每次调用send或recv的时候都能够正确，因此应该在调用他们之前使用select函数来检查一下（对于非阻塞），在出错之后也要检查等待可用后再调用。
4.不必要的网络数据量。网络传输数据的时候即使一个无用的字节也是负担，特别对于WAN，所以在自己定义数据包的时候应该尽量采用最小化的原则，例如，使用bit可以完成的就不要使用一个字节，使用一个字节完成的就不要用两个字节（当然最小也的一个字节），这个可以参考TCP/IP各类协议定义的时候采用的格式，非常精简。
以上这些是本人工作总结的结果，希望与大家一起分享探讨。

lsekfe

希望能够帮助到你！

Miss_love

学习