同步与异步编程
在设计服务器时，我们正在考虑两种方法：
异步（基于选择）方法，以便后端 rpc 可以在单个线程中并行化。
一种同步方法，其中每个后端 rpc 在线程池中的另一个线程中处理。
需要权衡：1 具有更好的性能，2 具有较低的代码复杂性。 现在，对于多核和 64 位机器来说，1 真的很重要吗？
When designing a server, we are considering two approaches:
A asynchronous (select based) approach so the backend rpc can be parallelized in a single thread.
A synchronous approach where each backend rpc is processed in another thread from the thread pool.
There are trade offs: 1 has better performance and 2 has less code complexity.
Does 1 really matter now with machine going multi-core and 64 bits?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我建议阅读有关 ACE 的这些书籍
获得有关模式的想法，使您能够创建高效的服务器。
I would recommend to read these books on ACE
to get ideas about patterns allowing you to create an efficient server.
我认为应该是相反的，异步 select() 方法使代码更简单，因为不涉及线程同步。
您需要做的就是将套接字句柄列表传递给 select() 函数。 它会阻塞并且仅当一个或多个套接字句柄发生某些事情时才返回。 与使用线程池相反，在线程池中，您必须有一个作业调度队列，线程池中的所有线程都可以从中获取作业。
异步 select() 方法的缺点是它不会随着处理器核心的数量而扩展，因为所有内容都在一个线程中执行。
I think it should be opposite, async select() approach makes the code simpler because there are no thread sync involved.
All you need to do is to pass a list of socket handles into the select() function. It will block and only return when something happened in one or more of the socket handle. As oppose to using a thread pool where you will have to have a job dispatch queue where all threads in the thread pool grab jobs from.
The down side of async select() approach is that it won't scale with the number of processor-core because everything was executed in one thread.
如果不了解有关服务器要求的更多详细信息，就很难判断哪种方法可以为您提供更好的性能和/或降低代码复杂性。
有趣的是，在现实生活中的服务器设计中，性能和简单性通常是相辅相成的（但想出简单的设计是很困难的）。 select/poll 本身并不会自动为您提供更好的性能。 而且线程池绝对不会降低你的代码复杂度。
回答你的问题：1仍然很重要。 异步设计不能很好地扩展多进程机器，但只有当您的服务器在一个进程上运行时，这才是正确的。 如果您的服务器被设计为在多进程机器上生成多个进程怎么办？ 不同的进程可以在不同的用户帐户下运行，并具有不同的安全设置。 虚拟机怎么样？ 每个进程一个线程并不意味着您不能利用多核机器。
然而，我真的不记得上次看到基于 async select() 的真实服务器设计是什么时候了。 也许在我上大学时的教科书上，但没有任何真正的生产系统。
Without knowing more detail about your server requirements, it is hard to tell which approach may give you better performance and/or reduce code complexity.
The funny thing is, performance and simplicity usually go together in real life server design (but coming up with the simplistic design is hard). select/poll by itself does not automatically give you better performance. And thread pool definitely does not reduce your code complexity.
To answer your question: 1 still matter. Async design does not scale well multi-proc machine but that's only true if your server run on one process. What if your server is designed to spawn multiple process on a multi-proc machine? Different process can be run under different user account and have different security setting. How about virtual machines? One thread per process doesn't mean you can't take advantage of multi-core machines.
However, i really can't remember the last time i saw a real server design based on async select(). Maybe in text books back when i was in college but not any real production system.
这是相关阅读（它是一种少数派报告）：
http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren.pdf
这也是一个很好的资源：
http://www.kegel.com/c10k.html
请记住，您可以在某种程度上结合这两种方法，以最大限度地发挥多核架构的效用。 假设您的服务器（“这里是 Krumpets！”；）是可分区的——这意味着您可以在同一台机器上运行它的多个实例——使用 select 编写服务器，然后为每个 cpu 核心运行一个服务器实例。
This is a relevant read (its a sort of minority report):
http://www.usenix.org/events/hotos03/tech/full_papers/vonbehren/vonbehren.pdf
This is also a good resource:
http://www.kegel.com/c10k.html
Keep in mind you can combine the two approaches, in a way, to maximize utility of multi-core architectures. Assuming that your server ("Krumpets here!" ;) is partionable -- meaning you can run multiple instances of it on the same machine -- write the server using select, and then run one instance of the server per cpu core.