gRPC cpp同步与异步服务器性能
我理解同步服务器和异步服务器之间的区别，但是我想知道，如果有这两种情况，哪一种更适合异步服务器还是同步服务器？
>
同步：写入调用将被阻塞，直到消息准备好从内部完成队列通过线路发送。异步：写入调用立即返回，我们需要等待完成队列。在同步服务器中，如果我们添加队列，该队列基本上为evry写入调用和其他线程填充，并将其耗尽并执行stream.write然后性能将相同？
同步：gRPC内部创建线程池，线程数等于CPU数异步：线程取决于实现。所以如果对于每个客户端，如果我们创建单独的线程和完成队列，同步和异步的性能会一样吗？
共有1个答案
理论上很难比较性能。根据经验，如果您的选择是让gRPC以其设计的方式在内部处理并发调用，还是自己用同步API管理gRPC调用并发，那么gRPC内部很可能会比您自己管理的性能更好。这个建议可能有例外，这取决于许多变量。。。例如，如果服务器正在做一些非常快速和廉价的事情，并且消息很小，那么同步API可能就可以了。
最后，基准是你的朋友。
gRPC绩效建议：https://grpc.io/docs/guides/performance/#c
gRPC官方基准（正在制定）：https://performance-dot-grpc-testing.appspot.com/explore?dashboard=5180705743044608.作为这些基准的基础的测试可能会为您的设计选择提供信息。
-
异步Tcp客户端 异步Http客户端 异步Redis客户端 异步Mysql客户端 异步Log日志 异步文件读写 异常Exception
-
问题内容： 由于Servlet 3.0 支持异步处理。使用始终异步处理会更好吗？或者在什么情况下同步处理更好？ 问题答案： 异步Servlet带来的最大好处是HTTP push ，在该服务器中，服务器可以在选择时向客户端发送信息，而不是在客户端请求时将信息发送回客户端。在异步Servlet之前，这将需要长时间运行的HTTP连接，每个HTTP连接都会束缚服务器线程，这是非常低效的。这个新模型使服务器
-
主要内容：同步时钟,实例,实例,异步时钟关键词： 同步，异步 由第 3 章可知，当触发器输入端的数据和触发器的时钟不相关时，很容易导致电路时序不满足。本章主要解决模块间可导致时序 violation 的异步问题。 关于异步与同步的定义，许多地方都有介绍，细节上也有所差异。本章主要的关注点是解决异步问题的方法，而不关心为什么会出现异步时钟，也不关心异步电路的具体结构，仅从异步时钟的时序结果去分析解决问题。 同步时钟 数字设计中，一般认为，
-
异步Log日志 use AsyncLog; yield AsyncLog::info('hello world'); yield AsyncLog::debug('test debug', ['foo' => 'bar']); yield AsyncLog::notice('hello world',[], 'group.com'); yield Async
-
多个同步服务器 Since you have full control of express instance lifecycle, it's not a problem to create a few multiple simultaneous servers (e.g. both HTTP & HTTPS). Example: 因为你已经可以完全控制express实例的生命周期了，所以创建多个
-
我有一个问题，试图找出最好的方法来完成一个简单的应用程序遵循Android最佳实践。下面是场景： 1）我有一个活动，用户输入一些东西，然后发送到后台服务 我不确定处理这种“事件”的标准方法是什么。您是否必须使用广播监听器和订户或它太多为这个简单的目的？