05 Application Architecture Determines Application Performance
架构决定性能
Randy Stafford
兰迪斯塔福德
APPLICATION ARCHITECTURE DETERMINES application performance. That might seem rather obvious, but real-world experience shows that it's not. For example, software architects frequently believe that simply switching from one brand of software infrastructure to another will be sufficient to solve an application's performance challenges. Such beliefs may be based on a vendor's benchmark trumpeting, say, 25% better performance than the closest competition's. But if the vendor's product performs an operation in three milliseconds while the competition's product takes four milliseconds, the 25% or one-millisecond advantage matters little in the context of a highly inefficient architecture at the root of an application's performance characteristics.
架构决定应用的性能，这似乎是尽人皆知的道理， 但是现实情况并非如此。常常有些架构师认为简单更换底层软件架构（Software Infrastructure）就足以解决应用的性能问题。这很可能是轻信了“经测试性能超出竞争对手25%”一类的商业噱头。假设某产品完成特定操作费 时3毫秒，竞争对手须要4毫秒。这1毫秒（25%的优势）对一个性能效率极低的架构而言几乎无关紧要。
In addition to IT managers and vendor benchmarking teams, other groups of people—vendor support departments and authors of application performance management literature—recommend simply "tuning" the software infrastructure, by fiddling with memory allocations, connection pool sizes, thread pool sizes, and the like. But if the deployment of an application is insufficiently architected for the expected load, or if the application's functional architecture is too inefficient in its utilization of computing resources, then no amount of "tuning" will bring about the desired performance and scalability characteristics. Instead, a re-architecting of internal logic or deployment strategy, or both, will be required.
撇开IT经理和厂商的测试团队，另一 些人（比如产品技术支持部门和研究应用性能优化的技术文章作者）则建议直接通过“调优”（Tuning）架构来解决问题，例如改变内存的分配方法、调整连 接池或线程池的大小，等等。然而如果应用的部署方案满足不了预期的负载（load），或者应用的功能架构对计算资源的利用太不充分，那么无论怎样“调优” 都无法带来理想的性能和可伸缩（scalability）特性。这时必须重新设计架构的内在逻辑和部署策略。
In the end, all vendor products and application architectures are constrained by the same fundamental principles of distributed computing and underlying physics: applications, and the products they use, run as processes on computers of limited capacity, communicating with one another via protocol stacks and links of nonzero latency. Therefore people need to appreciate that application architecture is the primary determinant of application performance and scalability. Those quality attributes cannot be miraculously improved with some silver-bullet switch of software brands, or infrastructure "tuning."Instead, improvements in those areas require the hard work of carefully considered (re-)architecting.
归根结底，任何产品和架构都必须遵循分布式计算和物理学的基本原理：运行应用和产品的计算机性能有 限；通过物理连接和逻辑协议实现的通信必然有延时。因此，我们应该意识到架构才是影响应用性能和可伸缩性的决定因素。性能参数是无法简单地通过更换软件， 或者“调优”底层软件架构来改善的，我们必须在架构的设计（或重新设计）上付出更多艰苦的努力才行。
架构决定性能
Randy Stafford
兰迪斯塔福德
APPLICATION ARCHITECTURE DETERMINES application performance. That might seem rather obvious, but real-world experience shows that it's not. For example, software architects frequently believe that simply switching from one brand of software infrastructure to another will be sufficient to solve an application's performance challenges. Such beliefs may be based on a vendor's benchmark trumpeting, say, 25% better performance than the closest competition's. But if the vendor's product performs an operation in three milliseconds while the competition's product takes four milliseconds, the 25% or one-millisecond advantage matters little in the context of a highly inefficient architecture at the root of an application's performance characteristics.
架构决定应用的性能，这似乎是尽人皆知的道理， 但是现实情况并非如此。常常有些架构师认为简单更换底层软件架构（Software Infrastructure）就足以解决应用的性能问题。这很可能是轻信了“经测试性能超出竞争对手25%”一类的商业噱头。假设某产品完成特定操作费 时3毫秒，竞争对手须要4毫秒。这1毫秒（25%的优势）对一个性能效率极低的架构而言几乎无关紧要。
In addition to IT managers and vendor benchmarking teams, other groups of people—vendor support departments and authors of application performance management literature—recommend simply "tuning" the software infrastructure, by fiddling with memory allocations, connection pool sizes, thread pool sizes, and the like. But if the deployment of an application is insufficiently architected for the expected load, or if the application's functional architecture is too inefficient in its utilization of computing resources, then no amount of "tuning" will bring about the desired performance and scalability characteristics. Instead, a re-architecting of internal logic or deployment strategy, or both, will be required.
撇开IT经理和厂商的测试团队，另一 些人（比如产品技术支持部门和研究应用性能优化的技术文章作者）则建议直接通过“调优”（Tuning）架构来解决问题，例如改变内存的分配方法、调整连 接池或线程池的大小，等等。然而如果应用的部署方案满足不了预期的负载（load），或者应用的功能架构对计算资源的利用太不充分，那么无论怎样“调优” 都无法带来理想的性能和可伸缩（scalability）特性。这时必须重新设计架构的内在逻辑和部署策略。
In the end, all vendor products and application architectures are constrained by the same fundamental principles of distributed computing and underlying physics: applications, and the products they use, run as processes on computers of limited capacity, communicating with one another via protocol stacks and links of nonzero latency. Therefore people need to appreciate that application architecture is the primary determinant of application performance and scalability. Those quality attributes cannot be miraculously improved with some silver-bullet switch of software brands, or infrastructure "tuning."Instead, improvements in those areas require the hard work of carefully considered (re-)architecting.
归根结底，任何产品和架构都必须遵循分布式计算和物理学的基本原理：运行应用和产品的计算机性能有 限；通过物理连接和逻辑协议实现的通信必然有延时。因此，我们应该意识到架构才是影响应用性能和可伸缩性的决定因素。性能参数是无法简单地通过更换软件， 或者“调优”底层软件架构来改善的，我们必须在架构的设计（或重新设计）上付出更多艰苦的努力才行。
浙公网安备 33010602011771号