在我们的最后一次通讯我们讨论了如何开发一个应用程序是常见的做法在很少或没有关注如何实现应用程序将执行一次。我们还讨论了如何在大多数情况下,IT组织更改IT基础设施几乎没有知识什么变化会影响应用程序的性能。在这两个例子中IT组织希望接受的应用程序的性能。在这个通讯,我们将开始开发一个替代方法,仅仅希望接受的应用程序的性能。我们将把这种方法称为应用程序性能工程(猿)。
猿是它的正式定义角色、技能、活动、实践、工具和可交付成果应用于应用程序生命周期的每一阶段,确保应用程序将设计、实施和运营支持来满足非功能性性能需求。
在不那么正式的方式,模仿是事实的识别组织需要设计应用程序的性能测试,测量和在整个应用程序生命周期优化性能。因为猿可以是困难和使用稀缺的资源,我们不建议IT组织必定会模仿应用于数百它所支持的应用程序。我们所建议的是一个组织需要的少量应用程序猿适用于公司依靠其业务运行。
如上所述,猿需要发生在整个应用程序生命周期。例如,一个典型的应用程序生命周期的关键组件是需求收集。需求收集是猿带来什么关注的性能。至少这包括建立目标应用程序需要多长时间来完成特定的操作,比如一个用户事务或文件传输。
然而,一个复杂的应用程序通常是由多个模块组成,每一个都可以有不同的响应时间目标。例如,假设一个IT组织发展或评估收购一个统一通信的应用程序。IT组织可以建立绩效目标,指出,95%的即时消息将在15分钟内成功交付。
然而,这种类型的性能目标没有任何意义的声音统一通信的组件。认识到,IT组织可以建立绩效目标,指出,98%的语音通话会平均意见分(MOS) 4.2或更高版本。
当然,众所周知,由于随之而来的延迟,抖动和丢包,广域网对应用程序性能产生重大影响。这就提出了一个关键的问题,我们将在未来的通讯地址:IT有“一刀切”的性能目标。是,IT组织承诺相同的性能对象独立用户所在吗?
另外,IT组织将为用户提供一组性能目标驻留在美国和一组不同的性能目标以外的用户居住美国吗?
在下通讯我们将讨论猿之间的联系和sla。