成都软件开发这个决策必须由证据驱动，而不是偏好。幸运的是，有实际的方法来测量你的应用程序花费时间的地方，并将这些测量结果与将带来最佳结果的并发模型对齐。
第一步是确定是什么使系统变慢。瓶颈通常分为两类：I/O限制或CPU限制。像Python的cProfile、统计分析器或应用性能监控（APM）服务这样的分析工具可以量化应用程序在等待I/O和执行操作之间所花费的时间百分比。关键是要收集揭示你所面临瓶颈的数据。
%时间等待I/O与%时间在CPU上
使用APM工具来观察你的应用程序有多少时间是在等待外部资源而不是进行计算。如果70%的时间被I/O阻塞，那么你的系统是I/O受限的。如果70%的时间都在进行计算的紧密循环，那么你的系统是CPU受限的。
顶级外部延迟
确定输入/输出延迟来自哪里。数据库查询是否始终需要200毫秒？外部API返回是否需要800毫秒？缓存在负载下是否表现不佳？收集每个外部依赖的延迟分布有助于您了解哪些等待最重要。通常，长时间的等待表明多线程是一个机会。
每个节点的CPU饱和度
即使你的分析器显示了在计算上花费的时间，测量每个服务器的CPU实际使用情况仍然是很重要的。如果在纯Python代码的峰值负载期间，你的节点的CPU持续处于90-100%的使用率，由于GIL，线程将不会提高吞吐量。然而，线程仍然可以为依赖于在计算过程中释放GIL的原生扩展（如NumPy）的工作负载带来好处。相比之下，如果CPU利用率在30%左右，而延迟却在增加，你很可能是受到了I/O的限制。
一旦你收集了数据，你就可以确定多线程或multiprocessing是更好的解决方案。
大量的时间等待在外部系统上，延迟集中在数据库查询或网络调用上，平均CPU利用率较低。
在这种情况下，多线程是合适的工具。线程将允许您的应用程序在一些线程等待时继续处理其他任务。这将提高您的吞吐量，而不会消耗大量的额外内存或CPU。
在没有等待I/O的情况下，有很高比例的时间在执行代码，CPU利用率始终很高，并且在多核机器上运行测试时性能有所提高。
这是一个适合多进程处理的案例。将工作负载分布在各个核心上可以提高并行性并缩短执行时间。
构建一个小型的概念验证，其中使用线程和进程实现相同的操作。原型应具有相同的操作并管理真实的workload。
测量吞吐量、延迟、资源使用情况和资源成本。特别是跟踪p95或p99延迟和CPU满足度，因为这些指标直接反映了用户体验和基础设施效率。每个系统在以下测试中的表现如何：
在受控负载下，每种方法每秒可以处理多少请求或每分钟可以处理多少任务？
多线程是否能显著减少等待时间？
进程是否减少关键路径上的CPU执行时间？
每种方法的成本是多少？虽然流程可以更快地交付结果，但如果它们消耗了过多的内存空间，云账单可能会超过性能收益。
目标是为您的环境找到最佳模型。解决方案不仅应更快，还应提供可预测的性能，以实现投资回报并允许您进行扩展。
公司的背景和目标最终将决定正确的做法。
如果您的客户体验依赖于响应速度，那么I/O等待时间比纯粹的计算更为重要。应优先选择能够减少可见延迟的基于线程的模型。如果产品依赖于大量的计算，那么增加的计算能力通常会证明对更多处理能力的投资是合理的。
但是解决方案的成本必须考虑。性能的适度提升可能无法证明基础设施支出的增加是合理的。基于证据做出这一决定是至关重要的，这样可以让你围绕战略展开讨论，而不是理论争论。
文章均为京上云专业成都软件开发公司，专注于成都软件开发服务原创，转载请注明来自https://www.j1feel.com/news/5798.html
