如此iocp模型的测试结果正常？

client并发1000个连接,连接上后发一个1k的包
server用AcceptEx模型（每次post 10个请求）接受client的connect请求，然后投递一Recv服务
recv服务返回后，投递一send的请求，回应一个1k的包给client！我的测试结果为：
1000个连接同时并发，连接成功率为500-750之间，如此成功率是不是我的iocp模型有问题！server：p2.4,512m,10m带宽

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

client 跟server不在同一台机,在同一局域网中在同一台机测试的话,成功率为<=100%
<=100%是什么意思
1% <= 100%
100% <= 100%
你每次投递100个AcceptEx试验一下，最好别设置为等待数据到后才返回，那比较安全
1000不实用,但LISTEN的设置可以提高一点,或者POST多些SOCKET
同时_beginthreadex 1000个线程
每个线程产生一个套接字
然后用这个套接字去连server
每一个都能成功？
to wwwllg(wwwllg) ( ) 信誉：99 不知道大哥是如何做测试！？？
我在局网，刚刚测试过。2000个联接，试了10次开，关，一切ok.联接成功后发送256个字节。iocp接收到后，马上回传给这个联接。
10次测试，成功100%
服务器运行在我公司局域网内，100M网络。
自己写了一个client，在button事件中，for(2000) create->connect ->send 256 char.
sver: accept ->ui->res 256 char->send to cleint .
server端用的是acceptex还是accept？
acceptex的话开始投递了多少个？
如果一开始就投递2000个的话，应该是100%的
你不要在一个for里面做连接
你产生1000个线程
每个线程里面创建两个socket
连接两次
看看效果如何
我觉得是你的处理iocp的逻辑函授，来不及响应造成的。也就是说，当你投递acceptex的时候，不是投递多少的问题，就算我投递一个acceptex，也可能能100%，虽然我没之样做。
当你接到到一个acceptex的时候，应该马上再投递一个新的acceptex。作为上一个的补充。这个过程应是不占用时间（很少）。这种情况只会增加cpu的负担，而不会丢失联接。
另外有一种假设(纯粹搞笑)，你是不是ui显示不正确?
你不要在一个for里面做连接
你产生1000个线程
每个线程里面创建两个socket
连接两次
看看效果如何
------------这样设计是不是弱XXX。
同时_beginthreadex 1000个线程
每个线程产生一个套接字
然后用这个套接字去连server
每一个都能成功？
-----------
你这样，只会增加你测试的机器的负担，不会对sver有任何引响。
我想应该不是投递acceptex的原因
如果是投递acceptex延迟的原因
客户端也应该会等待一段时间
而不是直接失败
连接失败的原因我想大概是客户端连接的速度太快
导致服务器的待接受队列已满
所以client才会直接失败的
你是单个线程去连接server的
没有并发
所以连接成功率才为100%
这不是设计的问题
这只是测试
事实上我们不希望客户这么快的连接
只想看看系统能允许多少的并发connect
同时_beginthreadex 1000个线程
每个线程产生一个套接字
然后用这个套接字去连server
每一个都能成功？
-----------
你这样，只会增加你测试的机器的负担，不会对sver有任何引响--------------------------------
你测试过吗,sever这样会忙于refuse,如何不会受影响!
我想应该不是投递acceptex的原因
如果是投递acceptex延迟的原因
客户端也应该会等待一段时间
而不是直接失败
连接失败的原因我想大概是客户端连接的速度太快
导致服务器的待接受队列已满
所以client才会直接失败的
你是单个线程去连接server的
没有并发
所以连接成功率才为100%
-------------------
你说的也有一定道理，我确实没有在多台机器上发启联接，也不可能有那么多机器。但是（10次没有一次丢），这足以证明，和设计还是有一定关系。
现在的web服务器都同时在成千上w的并行访问。他们能做到，从理论上，应是可行的，何况只是上k.还是多多分析原理，不要停留在代码上找问题。
现在的web服务器都同时在成千上w的并行访问，从理论上，应是可行的
---------------------------------------------------------------------------
老兄这点说的是，只是从理论到实际的应用，这个换价是多少
向在我 server：p2.4,512m,10m带宽
如此的机子上，有可能实现同时在成千上w的并行访问（同时_beginthreadex 1000个线程
每个线程产生一个套接字然后用这个套接字去连server）？？
有可能实现同时在成千上w的并行访问（同时_beginthreadex 1000个线程
每个线程产生一个套接字然后用这个套接字去连server）？？
---------------
我一点不明白你为什么要开1000个线程，开50-100个就足够了。
线程的数目不是要讨论的关键问题
只要足够就可以了只有一个线程的话IO和CPU会互相阻塞
没有并发效果主要是想看看服务器在并发大量的客户端连接时候的表现
如果没有并发那就没法测了
我的测试acceptEx效率很高，没有这种问题。估计是您的代码逻辑什么的有问题
线程的数目不是要讨论的关键问题
只要足够就可以了只有一个线程的话IO和CPU会互相阻塞
没有并发效果主要是想看看服务器在并发大量的客户端连接时候的表现
如果没有并发那就没法测了
--------------------------
你从哪里得出的这些结论？
线程的数目这个问题我是针对你前面的现象。线程用的好，是服务器系统高效率的关健。
只有一个线程的话IO和CPU会互相阻塞----你这费话，这里没有人用一个线程来处理这些
主要是想看看服务器在并发大量的客户端连接时候的表现----前面给你说过几次了，完成端口这方面非常出色，只是你没理解透，用不好罢了。
线程的数目这个问题我是针对你前面的现象。线程用的好，是服务器系统高效率的关健。
-------------------------------------------
兄弟你看清楚点
我这是客户端的测试线程
不是服务器端的只有一个线程的话IO和CPU会互相阻塞----你这费话，这里没有人用一个线程来处理这些
---------------------------------------------
反正说的没错就行，是不是废话我无所谓，有人或许连这个也不明白吧主要是想看看服务器在并发大量的客户端连接时候的表现----前面给你说过几次了，完成端口这方面非常出色，只是你没理解透，用不好罢了。
----------------------------------------------
我大概是没理解透完成端口，可是我肯定你连现在讨论的问题是什么都没能理解
我的意思不是已经存在连接上的大量客户端时候完成端口的表现
而是连接时的表现，一个是状态，一个是动作，明白？
这么说吧，我是这么做的
首先投递一批（比如说100个）AcceptEx
同时用一个线程调用WSAEventSelect监视listen socket上的FD_ACCEPT事件
如果先前投递的AcceptEx已经被连接完毕
那么这个线程会得到一个事件
这时候再投递一批AcceptEx
我在给你解释为什么有联接被丢失了。
劝你在其他网站上下载一些code分析一下。
问题已经清楚了
当AcceptEx已经用完并且连上但是未接受的socket队列已满的时候
客户端就会返回拒绝连接的错误最后,这个问题的解决办法就是等未完成的AcceptEx降到一定值得时候就投递
而不是等到全部用完的时候
(即使全部用完,也是未接受的连接队列满了以后客户端才会出错
假如不是大量的客户端同时连接的话
连接也是不会失败的
)
问题已经清楚了
当AcceptEx已经用完并且连上但是未接受的socket队列已满的时候
客户端就会返回拒绝连接的错误最后,这个问题的解决办法就是等未完成的AcceptEx降到一定值得时候就投递
而不是等到全部用完的时候
(即使全部用完,也是未接受的连接队列满了以后客户端才会出错
假如不是大量的客户端同时连接的话
连接也是不会失败的
)
这个问题的解决办法就是等未完成的AcceptEx降到一定值得时候就投递
而不是等到全部用完的时候
------------
你可能就是刚才我说的，你在一次accept事件到来时，来不级去投递新的联接，所以就丢失了。
你现在的策略其实只是降低了出错的可能性。
可以这么说
但是并不是AcceptEx用完了后面的连接就会立刻失败的
而是待决的未接受队列满的时候后面的连接才会失败你的策略大概就是AcceptEx完成一个就再投递一个吧？
这样虽然也能解决问题
但是对于客户端频繁连接的情况下
批量的投递AcceptEx表现要好一些
一个线程里：for(2000) conn
与
2000个线程,每个线程执行一个conn这两个是不一样的概念，我在我这里作的测试，一个线程里3500个连接都没有问题，100%接收连接。未出现一个被拒绝的情况。说到底，你在一个线程里先后创建socket并执行连接，是达不到预想中的并发连接测试效果的，还是使用多个线程要相对好一点（我仅指并发连接测试）。
listen第二个函数设成1000 这个办法你测试了吗如果测试了请把结果告诉我谢谢
首先确实我没明白你们所说的起1000个线程的用意。现在明白还不晚。告诉大家一个不幸的消息。我按照你们的方法测试结果是，联接还是100%的成功。
以下是我的测试代码。
void CClientDlg::OnButton7() //启动1000个线程。
{
for(int i=0;i<1000;i++)
{
AfxBeginThread(threadpool,this);
}
// TODO: Add your control notification handler code here

}
UINT CClientDlg::threadpool(LPVOID lparam)//线程函授
{
CClientDlg * pDlg = (CClientDlg*)lparam;
pDlg->Test();
return 0;
}
void CClientDlg::Test()//执行体
{
WaitForSingleObject(m_event,INFINITE);//1000个线程等在这里
CSocket * pSocket = new CSocket();
pSocket->Create();
if(!pSocket->Connect("10.22.13.193",3333))
{
m_Socket.Close();
return;
}
char test[256];
memset(test,2,256);
m_Socket.Send(test,strlen(test));
m_cs.Lock();
m_testsocket.AddTail(pSocket);
m_cs.Unlock();
}
void CClientDlg::OnButton8() //1000个线程得到信号
{
m_event.SetEvent();//手动的信号量
}
测试的时候，首先启动1000个线程。然后按buttom8.就执行test();
test中，和以前的测试方法一样，发送256字节.server收到后，马上回传256字节。当我换成2000线程的时候，我的机器在点button8时，报mfc42.dll的错，我想估计是mfc的线程类有问题。但是用1000个线程测试的时候是正常的。连续测试10组，每次1000个线程没丢一个联接。
listen的第二个参数windows平台上最大允许值是5
设高了也是没有用的连接失败的原因是投递AcceptEx的不及时造成的
在投递的AcceptEx用完而且不投递新的AcceptEx的情况下
如果再有超过5个client试图连接的话
后面的connect就会失败