让应用程序运行得更快

当我们继续通过破坏应用及其所依赖的网络来分解数据中心时，有一句商业格言仍然适用：速度为王。 绩效仍然是业务层面关注的问题，它影响着从销售到生产力等各个方面，有时会蚕食利润。

DZone 上最近的一篇文章《2016 年 Web应用的速度有多快》深入探讨了性能方面的一些细节，指出“对于典型的 Web应用，4.2％ 的交易被放弃”。 这是基于“50亿次用户与500种不同的基于网络的应用的互动”。

当然，这如何转化为美元并影响利润或生产力取决于商业模式。 这可能意味着数百万甚至数十亿美元的损失，或者因通话时间增加而导致的客户愤怒。

无论如何，性能对于开发人员和运营来说仍然是一个重要的考虑因素。 我所说的运营是指所有运营——基础设施、网络、存储和安全。 我们最新的application交付状况调查继续支持所有 IT 角色认为性能至关重要的态度。 为了获得更好的安全性而放弃它的可能性最小（只有 9% 的人会做出这样的交易），14% 的受访者认为这是多云实施面临的一个重大挑战。

尽管如此，只有 38% 的受访者表示他们现在使用应用加速服务，只有 22% 的受访者计划在明年实施。 令人惊讶的是，40％ 的人表示他们没有部署或使用应用加速的计划。

这可能是因为对于“应用加速”的含义的认识有些模糊。 这也不是因为“云”，而是因为它多年来不断发展和转变，从 QoS 到基于浏览器的增量刷新和缓存，再到所谓的应用前端 (AFE)，而这些应用程序前端实际上是具有非常注重性能的功能的专用代理。

大多数时候，当我们想到“应用加速”时，我们会想到压缩和缓存、最小化和图像优化。 我们不认为协议优化是当今充斥在商业和用户期望中的“我们需要 Warp 9，Scotty”整个心态的一部分。 但我们应该。

哦，我们发现协议卸载现在被广泛使用。 2015 年期间，客户端 SSL 卸载（管理用户安全 HTTP 的一方）的使用率从不到 80% 增加到接近 100%。 鉴于“Let's Encrypt！”和“SSL Everywhere”等举措对安全通信的关注度不断提高，这并不奇怪。 SSL/TLS 会影响性能（而且不是以一种好的方式），尤其是在负载增加时。 卸载到有能力的代理是有意义的，我们看到组织正是这样做的，以抵消确保一切安全对性能的影响。

但我们在后端，也就是服务器端并没有看到类似的增长。 使用 TCP 多路复用来提高性能（并同时增加资源容量）在过去的一年里并没有太大变化。 接近一半（约 46% 持续）的组织正在使用这种默默无闻的优化技术。

如果你考虑到许多同样的组织目前正经历着容器热潮，那么这就会很可怕。

为什么可怕？ 让我来告诉你为什么...虽然虚拟化完全有可能使组织能够微调每个实例的 TCP 堆栈以确保每个应用程序的最高性能，但容器的出现威胁了该模型。 这是因为容器共享单个网络堆栈。 对一个容器中部署的一个应用程序进行调整并不能保证同一主机上不同容器中不同应用程序的最佳配置。

因为基于 TCP 的优化（例如 TCP 多路复用）在协议层运行，所以它们就像蜜獾一样。 他们不关心应用程序是在容器中还是虚拟机中，或者裸露在网络平台上。 无论应用程序如何部署或在何处部署，他们都会尽力优化该连接并提高性能。 此类服务仅关心协议，并利用客户端与服务器端的分离来进一步确保客户端针对客户端进行优化，服务器端针对应用进行优化。这意味着性能提升两倍。

请不要误会我的意思，传统的应用加速服务和技术非常棒，正如您从上面的彩色图表中看到的那样，组织利用所有这些服务和技术来提高其应用的性能。 但还有很多事情可以做，而且如前文提到的绩效数据所表明的，还有很多事情要做。

查看你的代理（你可能只是用于负载均衡的代理）并确定它是否可以比你当前使用的代理为你的应用程序性能做更多的事情是一个好主意。

了解 F5 如何让应用程序运行得更快、更智能、更安全。