62,272
社区成员
发帖
与我相关
我的任务
分享网站速度慢的原因
想了解一下网站访问不稳定的原因。
网络高手指点一下。
程序和页面的原因在这里就不用说了。主要想了解一下网络问题。
我有一个服务器带宽是共享10M的。
以前是独享2M的，感觉和现在也差不了多少。
有几个问题想了解一下
1、如何测试出服务器带宽是否给够？用任务管理器查看带宽不太准，因为个别时候可以达到12%，平时就是2%以下。换句话说别人一占了带宽我就就小了。
2、常用的命令有ping tracert，这两个好象用处也不是很大，ping值高低，我感觉区别也不是很大，国外的空间PING值在300左右，打开速度也很快。还有就是tracert如果路由器不出大问题的话也看不出什么。
3、有什么好办法可以判断出是我本地网络的问题点是服务器网络的问题，还是服务器IIS出问题了？
有相关的文章书籍也可以。
网络高手指点一下。
程序和页面的原因在这里就不用说了。主要想了解一下网络问题。
我有一个服务器带宽是共享10M的。
以前是独享2M的，感觉和现在也差不了多少。
有几个问题想了解一下
1、如何测试出服务器带宽是否给够？用任务管理器查看带宽不太准，因为个别时候可以达到12%，平时就是2%以下。换句话说别人一占了带宽我就就小了。
2、常用的命令有ping tracert，这两个好象用处也不是很大，ping值高低，我感觉区别也不是很大，国外的空间PING值在300左右，打开速度也很快。还有就是tracert如果路由器不出大问题的话也看不出什么。
3、有什么好办法可以判断出是我本地网络的问题点是服务器网络的问题，还是服务器IIS出问题了？
有相关的文章书籍也可以。
...全文
请发表友善的回复…
发表回复
myhope88 2010-09-24
- 打赏
- 举报
你用外网访问一下网站，如果正常的话，那应该是你本身网络的问题了，如果不正常的话，那可能就是服务器有问题了
threenewbee 2010-09-24
- 打赏
- 举报
当adsl下行接近满负荷的时候，上行会阻滞。
lpc444 2010-09-24
- 打赏
- 举报
带宽10M的上行是多少？也可能和2M的上行差不多
wuyq11 2010-09-24
- 打赏
- 举报
检查带宽
把连接超时设置到1S以上。
做计数器，记录每秒下载的字节数。
在下载线程中判断“当前秒”中下载的字节数是否超限。超限了就停止下载。
等到下一秒再开始新的下载。 Thread.Sleep(sleep);延迟
http://topic.csdn.net/u/20090821/09/8358875d-44a9-4da1-894b-7971fd25c402.html
把连接超时设置到1S以上。
做计数器，记录每秒下载的字节数。
在下载线程中判断“当前秒”中下载的字节数是否超限。超限了就停止下载。
等到下一秒再开始新的下载。 Thread.Sleep(sleep);延迟
http://topic.csdn.net/u/20090821/09/8358875d-44a9-4da1-894b-7971fd25c402.html
别样苍茫 2010-09-24
- 打赏
- 举报
随着网络的发展，越来越多的应用程序需要依赖于网络，所以网络的性能直接影响到我们应用程序的性能。那么都有那些因素影响到网络程序的性能来？
我们以Windows平台上的应用程序来分析，首先将影响因素分为两个部分：基础网络部分，应用程序的网络驱动部分。
基础网络部分指物理的网络结构和链路，主要有下面几个方面的因素：
网络的速率和带宽。这是一个根本的问题，如果网络的基础设施不够快的话，那么其他都面谈。
通讯计算机之间的距离和路由。最基本的知识，在LAN内的应用程序就能够跑的飞快，因为基本上LAN的计算机第一个条件满足了，而且距离短，且路由跳数少，但对于WAN的应用程序来说距离和路由是决定程序性能的很重要的方面，一般来说距离越远，信息的传输延迟时间越长，而路由的跳数基本上与距离有关，但路由的路径却可以确定，那么选择一个好的路由（时延最小的）是必要的。时延的大小可以通过tracert或其他的工具来测量。
计算机的处理能力。一般情况下，CPU频率高的计算机处理起来要比CPU低的高，特别对于需要高速传输数据的应用程序，某个CPU频率可能是处理流量的极限，但使用相对频率高的CPU可能轻松处理。另外CPU的频率高低对程序的影响在发送和接收端都存在，如果接收端不能很快的从缓冲区中把数据取出来，那么发送端必然会收到0窗口的报告，从而停止等待对方的窗口恢复（TCP），造成本来可以利用的带宽被浪费。
那么在给定的基础网络部分之上怎么样尽量利用其发挥最大的性能着就属于网络应用程序本身编写的责任了，这也是很有讲究的，下面基本方面可以参考：
使用阻塞套接字。阻塞套接字可能会对应用程序的性能造成影响，在阻塞套接字时，程序必须等待SOCKET处理完毕或者出错后才返回，这段时间CPU就无聊的等待，对于非阻塞可以在这段时间做一些数据准备工作，一旦SOCKET可以用就立即发送数据，并行性更好。
频繁的调用send和recv。如果发送很很小的数据包且流量很大的时候（例如：每秒30000个150字节的包），而一次只发送一个包，就可能导致每秒中要调用30000次send函数，这个代价很大，因为每次调用send都要从用户态到核心态的switch，所以这个时候应该尽量减少send的调用次数，例如使用WSASend或用一个更大的发送缓冲区。对于recv也是同样的结果，最好使用一个较大的缓冲区来接收，然后使用内存COPY。实践发现，内存COPY比调用send或recv耗费的CPU时钟周期要少的多。
频繁的出错。对于在套接字不可用的时候调用send或recv函数，只会导致出错，而每出错一次就浪费一定的CPU周期，这个代价比较大，所以尽量保证每次调用send或recv的时候都能够正确，因此应该在调用他们之前使用select函数来检查一下（对于非阻塞），在出错之后也要检查等待可用后再调用。
不必要的网络数据量。网络传输数据的时候即使一个无用的字节也是负担，特别对于WAN，所以在自己定义数据包的时候应该尽量采用最小化的原则，例如，使用bit可以完成的就不要使用一个字节，使用一个字节完成的就不要用两个字节（当然最小也的一个字节），这个可以参考TCP/IP各类协议定义的时候采用的格式，非常精简。
我们以Windows平台上的应用程序来分析，首先将影响因素分为两个部分：基础网络部分，应用程序的网络驱动部分。
基础网络部分指物理的网络结构和链路，主要有下面几个方面的因素：
网络的速率和带宽。这是一个根本的问题，如果网络的基础设施不够快的话，那么其他都面谈。
通讯计算机之间的距离和路由。最基本的知识，在LAN内的应用程序就能够跑的飞快，因为基本上LAN的计算机第一个条件满足了，而且距离短，且路由跳数少，但对于WAN的应用程序来说距离和路由是决定程序性能的很重要的方面，一般来说距离越远，信息的传输延迟时间越长，而路由的跳数基本上与距离有关，但路由的路径却可以确定，那么选择一个好的路由（时延最小的）是必要的。时延的大小可以通过tracert或其他的工具来测量。
计算机的处理能力。一般情况下，CPU频率高的计算机处理起来要比CPU低的高，特别对于需要高速传输数据的应用程序，某个CPU频率可能是处理流量的极限，但使用相对频率高的CPU可能轻松处理。另外CPU的频率高低对程序的影响在发送和接收端都存在，如果接收端不能很快的从缓冲区中把数据取出来，那么发送端必然会收到0窗口的报告，从而停止等待对方的窗口恢复（TCP），造成本来可以利用的带宽被浪费。
那么在给定的基础网络部分之上怎么样尽量利用其发挥最大的性能着就属于网络应用程序本身编写的责任了，这也是很有讲究的，下面基本方面可以参考：
使用阻塞套接字。阻塞套接字可能会对应用程序的性能造成影响，在阻塞套接字时，程序必须等待SOCKET处理完毕或者出错后才返回，这段时间CPU就无聊的等待，对于非阻塞可以在这段时间做一些数据准备工作，一旦SOCKET可以用就立即发送数据，并行性更好。
频繁的调用send和recv。如果发送很很小的数据包且流量很大的时候（例如：每秒30000个150字节的包），而一次只发送一个包，就可能导致每秒中要调用30000次send函数，这个代价很大，因为每次调用send都要从用户态到核心态的switch，所以这个时候应该尽量减少send的调用次数，例如使用WSASend或用一个更大的发送缓冲区。对于recv也是同样的结果，最好使用一个较大的缓冲区来接收，然后使用内存COPY。实践发现，内存COPY比调用send或recv耗费的CPU时钟周期要少的多。
频繁的出错。对于在套接字不可用的时候调用send或recv函数，只会导致出错，而每出错一次就浪费一定的CPU周期，这个代价比较大，所以尽量保证每次调用send或recv的时候都能够正确，因此应该在调用他们之前使用select函数来检查一下（对于非阻塞），在出错之后也要检查等待可用后再调用。
不必要的网络数据量。网络传输数据的时候即使一个无用的字节也是负担，特别对于WAN，所以在自己定义数据包的时候应该尽量采用最小化的原则，例如，使用bit可以完成的就不要使用一个字节，使用一个字节完成的就不要用两个字节（当然最小也的一个字节），这个可以参考TCP/IP各类协议定义的时候采用的格式，非常精简。
