※ 引述《[email protected] (Terry)》之铭言： > ※ 引述《[email protected] (foolish)》之铭言： > : a client, a thread是蛮浪费的。 > : 如果thread切换的频率不高，client也不多倒是可以考虑。 > : 不然时间都花在context-switch上面了。 > 不然可行性是如何做呢? 不a client , a thread 哦, 怕时间都花在context-switch上面 如何做呢? 俺只是藉着之前分享的文章讲了一些作者说明的困境， 而我也觉得小有认同罢了:) <% About one year ago, a client of the company where I work asked us to develop a router for telephony protocols (i.e., protocols used for communication between a SMS center and external applications). Among the requirements was that a single router should be able to support at least 3,000 simultaneous connections. It was clear that we could not use the traditional thread-pooling approach. Most thread libraries do not scale well, because the time required for context switching increases significantly with the number of active threads. With a few hundred active threads, most CPU time is wasted in context switching, with very little time remaining for doing real work. As an alternative to thread pooling, we decided to use I/O multiplexing. In this approach, a single thread is used to handle an arbitrary number of sockets. This allows servers to keep their thread count low, even when operating on thousands of sockets, thereby improving scalability and performance significantly. Unfortunately, there is a price to pay: an architecture based on I/O multiplexing is significantly harder to understand and to implement correctly than one based on thread pooling. %> -- ※ Origin: SayYA 资讯站 <bbs.sayya.org> ◆ From: pc210-59-94-161.nutn.edu.tw