服务器程序内网测试响应速度很快，放到互联网却慢的要死，这是什么原因？

[kuoxin]

当前开发了个iocp服务器程序，在局域网测试非常快，但放到托管中心，响应速度非常的慢

[wolfgang amadeus]

先测测rtt呗，还有带宽

On 7/2/09, kuoxin <xin...@gmail.com> wrote:

当前开发了个iocp服务器程序，在局域网测试非常快，但放到托管中心，响应速度非常的慢

[张晓衡]

是不是服务器与你测试的客户端不是一条线路，比如网通连电信。

2009/7/2 wolfgang amadeus <swin...@gmail.com>

[kuoxin]

我测试了，没问题，在两个不同的机房都测试过，不是带宽和南北电信的问题，我猜测是我的程序内部的问题有可能是设置问题，在局域网1700用户都没问
题，到了广域网就4个用户都处理的很慢

On Jul 2, 6:38 pm, wolfgang amadeus <swingb...@gmail.com> wrote:
> 先测测rtt呗，还有带宽
>

[Kouga]

检查下有没有因为网络速度变慢引起长时间等待的锁、资源等。

2009/7/2 kuoxin <xin...@gmail.com>

--
签名是什么东西？？

[benegg]

那要看你的程序是什么样的逻辑了. 单凭这点信息, 无法解答你的问题. 很有可能是你的程序逻辑用到了某种停止等待, rtt增大时问题就来了.

[kuoxin]

我只使用了临界值，其他类型的锁没用。为什么会停止某种资源锁住，会增加rtt呢？

[benegg]

增加RTT是网络硬件改变导致的. 当你的应用网络从局域网变更到广域网时, 最明显的变化是RTT增加, 以及丢包率增加, 还有网速的变化. 如果
你使用TCP, 就不需要考虑丢包率, 但不能改变RTT, 这是一个硬件参数. 建议你完整描述下你的程序逻辑, 越详细越好, 否则这样空对空讨论
没有意义.

[Kouga]

其实这个时候，如果局域网正常而互联网异常，除了网络不同之外，有没有可能在程序哪里存在“小插销”之类的东西？

2009/7/3 benegg <ide...@163.com>

--
签名是什么东西？？

[张晓衡]

我还是觉得与环境有关系，比如防火墙、线路，你可以找个其它程序试试看另的程序是不是像你的程序一样很慢。

2009/7/3 Kouga <ncw...@gmail.com>

[kuoxin]

除了iocp的控制锁，我把程序中的锁全去了也不行，还是那样

[lau stephen]

把微软的那个 iocp echo 的例子放上去试试。
通常这种情况都是找个简单干净的程序放上去对比一下。

2009/7/3 kuoxin <xin...@gmail.com>:

[kuoxin]

谢谢哦

On Jul 3, 4:56 pm, lau stephen <stephen....@gmail.com> wrote:
> 把微软的那个 iocp echo 的例子放上去试试。
> 通常这种情况都是找个简单干净的程序放上去对比一下。
>

> 2009/7/3 kuoxin <xin....@gmail.com>:

[服务器开发]

正常的IOCP应该问题都不大。
我的IOCP内网一万七千测试也没有问题。
公网目前也没有出现什么问题。压力比较稳定
可能是你的逻辑问题。比如资源锁之类的。

> > >> 签名是什么东西？？- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[lincoln]

我在设计IOCP服务器时，有个疑问。当应用层产生完client所需要的数据包，
1.直接使用wsasend投递，
2.放在网络层的发送队列中，等待上个client数据包发送完毕后，再发送下个client的数据包。（比如开了四个工作线程，可以分别同时向四个client投递wsasend，当其中一个client数据投递完毕后，会通知pendingSend线程，此线程会从队列头取一个新的数据包继续wsasend。）

现在我采用的是第二种方法。但是想到了个问题，如果排在发送队列前面的client网络不好或数据包的流量大，势必会占用更多的时间，而影响排在发送队列后面client的响应时间。
不懂大家是怎么设计的。

2009/7/3 服务器开发 <huzhang...@gmail.com>:

[Eric.Wang]

局域网和互联网的网络特性不一样。要避免频繁的小块数据传输。

[lincoln]

怎 样才算小，，我分别开辟了2K的空间用来接收，发送。这样小吗？

2009/7/4 Eric.Wang <wangsh...@gmail.com>:

[Kouga]

IOCP是异步模型，要wsasend请直接调用，剩下的事情交给IOCP底层，无需用第二种设计方式，有点重复了。

2009/7/4 lincoln <linc...@gmail.com>

--
签名是什么东西？？

[lincoln]

是啊，原先也是用倾向第一种方法，但如果在理论上我向1000个客户端或是更多的客户端同时投递数据，考虑到会造成内存页锁定的问题才使用了第二种案。

上面那位仁兄说 "局域网和互联网的网络特性不一样。要避免频繁的小块数据传输。"

那我分别开辟2K 的收发缓存会小吗？

2009/7/4 Kouga <ncw...@gmail.com>:

[Dogvane]

我觉得"要避免频繁的小块数据传输。"应该是指拼数据包到一定量再发送，例如在10ms内投递10个1k的数据要比先收集10ms的数据一次投递要慢一
些。

On 7月4日, 下午2时32分, lincoln <lincol...@gmail.com> wrote:
> 是啊，原先也是用倾向第一种方法，但如果在理论上我向1000个客户端或是更多的客户端同时投递数据，考虑到会造成内存页锁定的问题才使用了第二种案。
>
> 上面那位仁兄说 "局域网和互联网的网络特性不一样。要避免频繁的小块数据传输。"
>
> 那我分别开辟2K 的收发缓存会小吗？
>

> 2009/7/4 Kouga <ncwh...@gmail.com>:

>
> > IOCP是异步模型，要wsasend请直接调用，剩下的事情交给IOCP底层，无需用第二种设计方式，有点重复了。
>

> > 2009/7/4 lincoln <lincol...@gmail.com>

>
> >> 我在设计IOCP服务器时，有个疑问。当应用层产生完client所需要的数据包，
> >> 1.直接使用wsasend投递，
>
> >> 2.放在网络层的发送队列中，等待上个client数据包发送完毕后，再发送下个client的数据包。（比如开了四个工作线程，可以分别同时向四个client投递wsasend，当其中一个client数据投递完毕后，会通知pendingSend线程，此线程会从队列头取一个新的数据包继续wsasend。）
>
> >> 现在我采用的是第二种方法。但是想到了个问题，如果排在发送队列前面的client网络不好或数据包的流量大，势必会占用更多的时间，而影响排在发送队列后面client的响应时间。
> >> 不懂大家是怎么设计的。
>

> >> 2009/7/3 服务器开发 <huzhangyou2...@gmail.com>:

[flywav]

这样的讨论没意义。

这个时候你要做的事情是 定点检测。

我提供一些检测的技术方案

1 客户端抓包， 通过 包的数据， 定义出 握手时间， 发送的时间， 接受的时间
2 服务器 打印日志， 接收数据时间， 发送数据时间

比较2者， 可以看出问题在那里，是网络还是服务器的内部运行。

具体的问题 一分析就可以了， 这种问题很常见，也很好定位。

[flywav]

以现在的计算机能力 1000个连接的压力，各种方案的优劣一点都分不出来。

On 7月4日, 下午2时32分, lincoln <lincol...@gmail.com> wrote:

> 是啊，原先也是用倾向第一种方法，但如果在理论上我向1000个客户端或是更多的客户端同时投递数据，考虑到会造成内存页锁定的问题才使用了第二种案。
>
> 上面那位仁兄说 "局域网和互联网的网络特性不一样。要避免频繁的小块数据传输。"
>
> 那我分别开辟2K 的收发缓存会小吗？
>

> 2009/7/4 Kouga <ncwh...@gmail.com>:

>
> > IOCP是异步模型，要wsasend请直接调用，剩下的事情交给IOCP底层，无需用第二种设计方式，有点重复了。
>

> > 2009/7/4 lincoln <lincol...@gmail.com>

>
> >> 我在设计IOCP服务器时，有个疑问。当应用层产生完client所需要的数据包，
> >> 1.直接使用wsasend投递，
>
> >> 2.放在网络层的发送队列中，等待上个client数据包发送完毕后，再发送下个client的数据包。（比如开了四个工作线程，可以分别同时向四个client投递wsasend，当其中一个client数据投递完毕后，会通知pendingSend线程，此线程会从队列头取一个新的数据包继续wsasend。）
>
> >> 现在我采用的是第二种方法。但是想到了个问题，如果排在发送队列前面的client网络不好或数据包的流量大，势必会占用更多的时间，而影响排在发送队列后面client的响应时间。
> >> 不懂大家是怎么设计的。
>

> >> 2009/7/3 服务器开发 <huzhangyou2...@gmail.com>:

[Kouga]

这种时候只有在有压力存在的情况下才能分辨出来优劣，一个好的设计能够承载更多的连接，但是，如果用于该设计的时间不如多买一颗CPU的话，很多企业会更加倾向先买这颗CPU吧？呵呵。

另外，上面说的测试方法应该可行，建议做跟踪日志，毫秒级别，看哪里调用卡住了才是真的。很多测试工具可以做这个的。

2009/7/5 flywav <ppms...@gmail.com>

--
签名是什么东西？？