用select做服务器，8G内存做到30万～50万客户同时在线

yulihua49

iw1210 发表于 2013-11-28 16:05
进程调度的开销是比线程大，但这些都可忽略不计，更何况计算机运行速度发展如此迅速。扩展能力和灵活方便 ...

线程调度时间7微秒，意味着什么？，就是每秒14万的调度次数，所以单队列，每秒15-16Wqps（就算有时不到7微秒，有的机器主频比我略高）是极限了，与核数无关，只与主频有关。
近年来，cpu主频几乎不提高了，就是增加核。所以这个值就是系统瓶颈。
我的交易管理器，单队列，最高能力每秒65000，大家可能认为不高。
因为每个交易要两发两收，所以，一个TPS＝2qps，就是13万qps。这说明什么？说明，交易转发器的其它工作都可以忽略不计，主要开销是在调度任务。
即使select，如果要支持多线程，它一次可以多个事件（epoll也行），就是7微秒内多个事件，但是如果把它们再通过一个队列分发给其它工作线程，还是躲不过这7微秒。
要么是通过多个队列分发。

当然，你那个方案没这个问题，那么多的进程，都是并行队列。

yulihua49

iw1210 发表于 2013-11-28 15:58
数据库连接能力是数据库的事了，没必要关心，何况数据库链接开到10000都没事 ...

实测，在一定范围内，数据库引擎的处理能力，随着并行连接数的上升而上升，超过一定值，随着连接数（并行数）的上升，吞吐量会明显下降。
用OLAP系统测试的，连续密集的事务。OLTP反而好一些，因为它的数据库连接，不总是忙的。
引擎在无序的互斥竞争中，效力低下。这种情况，我们宁可保持适度的连接数，让过多的请求在外边排队。

我们调节连接池的连接数，使系统保持最高的处理能力，效果是显著的。
这样，当用户数膨胀时，响应时间永远是线性增长，而不会指数增长。

myworkstation

回复 34# iw1210


    再怎么说，大量的进程调度都比合适的少量进程更消耗CPU，而且select的fds在操作过程中的设置以及内核中的遍历是必不可少的，其消耗必然高于epoll，你的程序之所以没什么问题可能和你的网络通信量有关系，如果都是繁忙的连接又如何？如果连接的冷热不均又如何？真正经对比的得把问题给量化，最后说一句：跑着没问题是一回事，跑的很好是一回事儿，能很好的去跑又是另一回事儿了。

iw1210

yulihua49 发表于 2013-11-29 20:17
实测，在一定范围内，数据库引擎的处理能力，随着并行连接数的上升而上升，超过一定值，随着连接数（并行 ...

不要把连接数和连接池搞混了。这是虚拟连接，不是物理连接。连接数和连接池是相辅的，连接池的物理连接数固定，虚拟连接数可以增加。所以不必顾虑连接数增加会导致数据库性能下降，数据库中提出连接池概念就是为解决连接数限制的问题。

iw1210

myworkstation 发表于 2013-11-30 22:19
回复 34# iw1210
再怎么说，大量的进程调度都比合适的少量进程更消耗CPU，而且select的fds在操作过程中的设置以及内核中的遍历是必不可少的，其消耗必然高于epoll，...

大量进程调度会是不是影响性能的主要原因，需要实际考证。
小范围查找就解决了大范围盲目遍历的问题，比如只有一个连接，这个连接在当然只在一组内，遍历也就1000，而不是一万或几十万。再说了，其实程序中到处都是小范围查找东西，epoll当然也不例外。

myworkstation

回复 55# iw1210


    但实际上你所有的连接都是会遍历的啊。每个进程通到CPU时间片的时候都会进行这个处理吧。

iw1210

myworkstation 发表于 2013-11-30 22:50
回复 55# iw1210
但实际上你所有的连接都是会遍历的啊。每个进程通到CPU时间片的时候都会进行这个处理吧。

哪一组有fd触发时才遍历，没有当然就等待。

myworkstation

回复 57# iw1210


    这是哪儿的说法？有触发才遍历？select不遍历怎么知道触发？

iw1210

myworkstation 发表于 2013-11-30 22:58
回复 57# iw1210
这是哪儿的说法？有触发才遍历？select不遍历怎么知道触发？

select阻塞等待怎么说的来

iw1210

yulihua49 发表于 2013-11-29 19:55
线程调度时间7微秒，意味着什么？，就是每秒14万的调度次数，所以单队列，每秒15-16Wqps（就算有时不到7微 ...

很好，需要这样的数据加强说服力，这个方案的各方面数据如何？能都算出来么？帮忙算算吧