讨论：高性能的服务器程序设计方案,该怎么处理
讨论：高性能的服务器程序设计方案
这两天看了一些资料．说windows上用iocp处理大量连接时是最高效的．
我还没有用过iocp，就我现在了解的有这几个要注意的地方：
1.在io线程内不能有阻塞的操作，要尽可能地立即返回．
2.io线程数最好是等于cpu的个数．
3.具体的逻辑处理最好另开线程或线程池来处理．
就我的理解，如果是这样的话，就肯定需要一个数据队列．io线程收到数据就放到数据队列中，然后立即返回．逻辑处理的线程就从这个数据队列取出数据来处理．
不知道我上面说的是不是对的？或者说这样处理是不是最高效的？
还有，像这种多个线程操作同一个队列的情况一般是要加锁的．加锁就免不了性能下降了．
我现在想到一个不加锁的方法，请各位帮我看看可行不：
内存：分配一块全局的内存，分成一小块一小块，假设分成10块，每块500字节：[0,1,2,3,4,5,6,7,8,9]
线程：1个io线程（用iocp），N个数据处理线程．
io线程收到数据并拼包，放入到索引的内存块中，
然后把索引postthreadmessage给数据处理线程（轮流post给N个数据处理线程的每一个,保存每一个数据处理线程得到同样多的数据包），
同时索引号增1,
当索引值到达内存块数的一半时，比如这里是索引到达4时，给每一个数据处理线程post一个消息，数据处理线程收到这个消息后，会给io线程回传一个信号，比如setevent．
当io线程的索引用到内存块的末尾9时，就检查是否还有数据处理线程正在处理0－4索引的内存块（前面到4时post的那个消息就是起这个作用），如果没有数据处理线程占用，就把索引号重新从0开始．如果还有数据处理线程占用，就一直等待．同理在索引值是9的时候也要post一个消息然后在4的时候检查...
这样就想当于两个缓冲区切换．除了在切换的时候要等待一下，其余的时候都不用考虑．而且如果块数足够多，切换时一般是不需要等待延时的．
还有个疑问，就是io线程拼包所用的时间可不可以接受？会不会太费时？如果把拼包的工作交给其它线程做好像也不好，因为像http这类服务，要根据socket区分每一个用户．
欢迎大家讨论一下^..^
------解决方案--------------------
服务器程序的网络I/O本身如iocp已经没有什么好讨论的了,微软已经将它与硬件配合,效率已经做到了极限.
真正要关心的是你的产品的整体架构,而不再是网络I/O本身诸如iocp等东西.
------解决方案--------------------
嗯工作线程，负责处理完成通知包，尽可能的把数据缓存起来。当然在这里就要分客户端socket来缓存。这就要求每个WSARecv，不要完全按照应用协议分包接收，应该是按照应用协议分包的10倍来投递请求。多少倍，看你单个协议包的大小来决定。因为网络IO本身就是相对内存IO是低速的，所以在这里拼包，得不偿失。
另外一个线程负责把缓存的包数据，处理拼包逻辑。因为此时是内存IO，肯定比工作线程去处理要快
------解决方案--------------------
需要结合自己的实现功能来看是否适合用IOCP来处理。
------解决方案--------------------
数据拷贝 用户 内核 转换 IO 操作 线程同步
这些是影响程序效率的根本 你应该在这几方面下工夫
对了 关于多线程 有专门的模式 解决你遇到的问题 比如线程专有存储
------解决方案--------------------
帮顶
------解决方案--------------------
MARK
------解决方案--------------------
up
------解决方案--------------------
JF
------解决方案--------------------
> 现在一般windows的基本模式就是 IOCP+线程池
------解决方案--------------------
IOCP ? 呵呵，有时间去看看
------解决方案--------------------
恩恩，看书就行
------解决方案--------------------
俺是菜鸟学习一下
------解决方案--------------------
祝福所有的****网友：幸福，平安！！
我爱****！
------解决方案--------------------
真不错，写的很详细，很有帮助
------解决方案--------------------
不错哦
------解决方案--------------------
关注,等待最佳结果
------解决方案--------------------
IOCP并不能说是最高效的模型，因为MS一切替你包办了。在大多数的时候它很高效，但是如果是这样的一个场景，它就无能为力了：
连接的客户端中有5%或10%以上的用户网络连接很差，比如每秒只能传50个字节。或者一个恶意客户端，比如我，故意和你建立一个连接，在一定范围内比如每3秒发一个节字。但我也不断线。
这样恶劣的IO通道会占用太多的协议栈的时间和连接端口。因为MS是不仅为你准备好栈的读写的状态，还把你要的数据读完或写完才通知你。
而采用EPOLL就可以很好地控制，因为内核只是告诉你栈的读写状态已经准备好了，具体的读和写你自己的操作，这样用户就有很大的控制权，比如我连续三次只读到很少的字节我就把这个连接转移到普通的阻塞通道上从而让出非阻塞通道让其它连接质量好的连接使用。
------解决方案--------------------
关注，学习了！
------解决方案--------------------
长见识了。。。呵呵
------解决方案--------------------
这两天看了一些资料．说windows上用iocp处理大量连接时是最高效的．
我还没有用过iocp，就我现在了解的有这几个要注意的地方：
1.在io线程内不能有阻塞的操作，要尽可能地立即返回．
2.io线程数最好是等于cpu的个数．
3.具体的逻辑处理最好另开线程或线程池来处理．
就我的理解，如果是这样的话，就肯定需要一个数据队列．io线程收到数据就放到数据队列中，然后立即返回．逻辑处理的线程就从这个数据队列取出数据来处理．
不知道我上面说的是不是对的？或者说这样处理是不是最高效的？
还有，像这种多个线程操作同一个队列的情况一般是要加锁的．加锁就免不了性能下降了．
我现在想到一个不加锁的方法，请各位帮我看看可行不：
内存：分配一块全局的内存，分成一小块一小块，假设分成10块，每块500字节：[0,1,2,3,4,5,6,7,8,9]
线程：1个io线程（用iocp），N个数据处理线程．
io线程收到数据并拼包，放入到索引的内存块中，
然后把索引postthreadmessage给数据处理线程（轮流post给N个数据处理线程的每一个,保存每一个数据处理线程得到同样多的数据包），
同时索引号增1,
当索引值到达内存块数的一半时，比如这里是索引到达4时，给每一个数据处理线程post一个消息，数据处理线程收到这个消息后，会给io线程回传一个信号，比如setevent．
当io线程的索引用到内存块的末尾9时，就检查是否还有数据处理线程正在处理0－4索引的内存块（前面到4时post的那个消息就是起这个作用），如果没有数据处理线程占用，就把索引号重新从0开始．如果还有数据处理线程占用，就一直等待．同理在索引值是9的时候也要post一个消息然后在4的时候检查...
这样就想当于两个缓冲区切换．除了在切换的时候要等待一下，其余的时候都不用考虑．而且如果块数足够多，切换时一般是不需要等待延时的．
还有个疑问，就是io线程拼包所用的时间可不可以接受？会不会太费时？如果把拼包的工作交给其它线程做好像也不好，因为像http这类服务，要根据socket区分每一个用户．
欢迎大家讨论一下^..^
------解决方案--------------------
服务器程序的网络I/O本身如iocp已经没有什么好讨论的了,微软已经将它与硬件配合,效率已经做到了极限.
真正要关心的是你的产品的整体架构,而不再是网络I/O本身诸如iocp等东西.
------解决方案--------------------
嗯工作线程，负责处理完成通知包，尽可能的把数据缓存起来。当然在这里就要分客户端socket来缓存。这就要求每个WSARecv，不要完全按照应用协议分包接收，应该是按照应用协议分包的10倍来投递请求。多少倍，看你单个协议包的大小来决定。因为网络IO本身就是相对内存IO是低速的，所以在这里拼包，得不偿失。
另外一个线程负责把缓存的包数据，处理拼包逻辑。因为此时是内存IO，肯定比工作线程去处理要快
------解决方案--------------------
需要结合自己的实现功能来看是否适合用IOCP来处理。
------解决方案--------------------
数据拷贝 用户 内核 转换 IO 操作 线程同步
这些是影响程序效率的根本 你应该在这几方面下工夫
对了 关于多线程 有专门的模式 解决你遇到的问题 比如线程专有存储
------解决方案--------------------
帮顶
------解决方案--------------------
MARK
------解决方案--------------------
up
------解决方案--------------------
JF
------解决方案--------------------
> 现在一般windows的基本模式就是 IOCP+线程池
------解决方案--------------------
IOCP ? 呵呵，有时间去看看
------解决方案--------------------
恩恩，看书就行
------解决方案--------------------
俺是菜鸟学习一下
------解决方案--------------------
祝福所有的****网友：幸福，平安！！
我爱****！
------解决方案--------------------
真不错，写的很详细，很有帮助
------解决方案--------------------
不错哦
------解决方案--------------------
关注,等待最佳结果
------解决方案--------------------
IOCP并不能说是最高效的模型，因为MS一切替你包办了。在大多数的时候它很高效，但是如果是这样的一个场景，它就无能为力了：
连接的客户端中有5%或10%以上的用户网络连接很差，比如每秒只能传50个字节。或者一个恶意客户端，比如我，故意和你建立一个连接，在一定范围内比如每3秒发一个节字。但我也不断线。
这样恶劣的IO通道会占用太多的协议栈的时间和连接端口。因为MS是不仅为你准备好栈的读写的状态，还把你要的数据读完或写完才通知你。
而采用EPOLL就可以很好地控制，因为内核只是告诉你栈的读写状态已经准备好了，具体的读和写你自己的操作，这样用户就有很大的控制权，比如我连续三次只读到很少的字节我就把这个连接转移到普通的阻塞通道上从而让出非阻塞通道让其它连接质量好的连接使用。
------解决方案--------------------
关注，学习了！
------解决方案--------------------
长见识了。。。呵呵
------解决方案--------------------