View source

From WikiContent

The action you have requested is limited to users in the group user.

You can view and copy the source of this page:

== Application Architecture Determines Application Performance == Application architecture determines application performance. That might seem rather obvious. But apparently it is not obvious to some people involved in the software development industry. Unenlightened personnel in information technology management, for example, may 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, taken in context, 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 midst of a highly inefficient architecture at the root of an application’s performance characteristics. 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. 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 each other via protocol stacks and links of non-zero 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. (RMH Edited 6/2/2008) By [[Randy.stafford|Randy Stafford]] This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3] Back to [[97 Things Every Software Architect Should Know]] home page

Return to O'Reilly Commons.