Web应用程序性能问题的根本原因可以分为两类：

• 您的应用程序性能不佳。 应用程序开发人员通常可以通过调整性能和进行代码更正来解决此问题。
• 由于Internet问题，您的应用程序运行不佳。 由于不可预测的Internet基础结构，这种情况通常超出任何一家公司的控制范围。

无论您的应用程序是由于内部还是外部原因而运行不佳，响应时间都很慢都会影响用户，这可能导致采用率降低和对应用程序的满意度降低。

图1.互联网是一个复杂的多路径网络网络

图1表示Internet不是单个网络，而是通过对等点连接的12,000多个网络。 从数据中心到用户的路径可以穿越多个网络和对等点。 很多时候，路径可能很拥挤，并且可能发生事故，自然灾害或业务纠纷，可能导致传输延迟。

解决性能不佳的Web应用程序的一种方法是通过添加更多服务器，带宽甚至可能用于卸载的更多数据中心来扩展容量。 但是，这种方法不具有成本效益，也不能充分解决Internet不可预测的性能。 此外，建立更多的基础架构意味着在流量较低时，您可能会过度配置，而在流量确实较高时，您可能仍会遇到瓶颈。

本文介绍了使用Akamai的EdgePlatform（在70个国家/地区部署了70,000多个服务器的广泛网络）和1000多个网络的最佳实践，以实时监视Internet，收集有关流量，拥塞和故障点的信息，以消除长途路线和避免出现麻烦点，以确保快速可靠地交付您的Web内容。

最佳实践：使用Akamai Web应用程序加速器交付动态Web内容

为了帮助解决Internet上的拥塞和漏洞问题，Akamai开发了Akamai EdgePlatform，该产品提供了针对各种情况而设计的产品，以减轻Internet在交付网站，内容和应用程序方面的缺点。 特别是，我们使用Akamai Web应用程序加速器，该加速器旨在通过以下方式加速动态Web内容的交付：

• 避免互联网流量拥塞：由于互联网流量，原始服务器和Akamai Edger服务器之间的直接路由可能会被堵塞。 通过使用SureRoute for Performance，您可以通过确定更理想的备用路由来克服此问题。
• 优化TCP配置：Akamai能够优化TCP连接窗口，调整TCP超时并最大程度地使用持久性连接，以最大程度地提高Akamai边缘服务器和原始服务器之间的吞吐量。
• 缓存内容：可以缓存大多数静态内容，例如图像，视频和zip文件。 通过将这些对象缓存在距离最终用户更近的边缘服务器上，Akamai可以减少往返次数以从原始服务器检索静态内容。
• 预取内容：Akamai提供了智能的预取功能，因此它可以以最快的响应时间将HTML页面中的所有嵌入式内容交付给最终用户。 当最终用户的浏览器请求嵌入的内容时，它已经在附近边缘服务器的内存中等待用户，因为Akamai在实际的浏览器请求之前已请求了该内容。
• 加快内容传输时间：Akamai可以先使用gzip在边缘服务器上压缩内容，然后再将其发送到客户端。 这减少了传输内容所需的时间。 大于10KB的对象可受益于Last Mile Acceleration。

Web应用程序加速器的设计包括两个主要任务：

1. 配置系统以识别边缘服务器。
2. 设计可应用于您的SaaS应用程序的缓存规则和策略。

任务1：配置为识别边缘服务器

第一项任务是配置您的系统，使其能够识别Akamai边缘服务器。 图2显示了整体架构。

图2.配置系统以识别边缘服务器

当用户请求对象时，该请求首先被定向到Akamai边缘服务器。 如果内容可从边缘服务器获得，则将从缓存中将其返回给用户。 如果内容不可用，Akamai将返回到原始服务器（即我们的数据中心）并请求内容，然后将其缓存在Akamai边缘服务器网络中，然后将内容返回给用户。

要执行此任务，需要一位主题专家，他可以了解您的系统拓扑，例如Akamai将与之对话的服务器的IP地址和主机名，您的应用程序的URL（是否安全），域名等。可以与Akamai专家一起设置系统。

任务2：设计缓存规则

第二项任务与设计可应用于您的SaaS应用程序的缓存规则和策略有关。 要实现此任务，您需要了解网站的内容：目录结构，内容类型以及内容的生成方式。 本节涵盖了几个缓存主题。

基于文件扩展名和路径的缓存规则

最简单的缓存规则基于标准文件扩展名。 默认情况下，具有以下扩展名的文件会自动缓存：

aif aiff au avi bin bmp cab carb cct cdf class css doc dcr dtd
exeflv gcf gff gif grv hdml hqx ico ini jpeg jpg js mov mp3 nc pct
pdfpng ppc pws swa swf txt vbs w32 wav wbmp wml wmlc wmls
wmlsc xsd zip

假定这些文本，图像，样式表和音频文件是静态的，因此可以缓存。 通过将它们放在边缘服务器缓存中可以提高性能。 默认的缓存时间是一天。 特别是对于我们在JavaScript扮演重要角色的富互联网应用程序，Akamai可以为我们缓存大量对象并显着提高整体性能。

根据应用程序的要求，您可以轻松添加更多文件扩展名或从此列表中删除它们。 例如，特定文件路径（例如/doc/*.html）上的某些HTML或XML文件也可能是静态的，因此也可以缓存。

您还可以基于请求参数或其他应用程序元数据定义用于缓存动态内容的缓存规则。 通常，仅对资源使用URL可能不足以作为缓存密钥。 您需要添加一些额外的Cookie来构成复合缓存键。 cookie可用于从租户中识别特定的租户或用户。 这使边缘服务器可以维护内容的用户/租户特定副本，并从缓存中提供正确的副本。 这是一项更高级的功能，需要仔细设计和测试。

测试缓存规则的工具和技术

为确保您定义的缓存规则按预期工作，请使用HTTP调试工具（例如Fiddler）作为透明代理，以便您可以查看所发出的每个请求并验证响应以查看缓存是否正常工作。

通用方法是请求可缓存对象，然后使用Fiddler的会话检查器检查请求中的标头。 您还需要在Fiddler中添加一条规则，以便它在请求中启用Akamai特定的Pragma标头（例如X-Check-Cacheable，X-Cache）。

第一次请求可缓存对象

例如，我们的一个缓存规则表明我们将缓存JavaScript。 因此，我们可以请求一个文件，例如test.js。 由于这是您第一次发出请求，因此应该期望在“响应头”面板中看到以下属性：

X-Check-Cacheable: YES
X-Cache: TCP_MISS from a96-17-171-7 (AkamaiGHost/6.3.0-7086845)

第一个属性验证了我们确实在缓存扩展名为.jsJavaScript文件。 第二个属性指示尽管该对象是可缓存的，但在Akamai缓存中找不到test.js文件，因此它是从我们的数据中心交付的。

第二次请求可缓存对象

现在，向同一文件test.js发出另一个请求。 由于这是第二次请求同一对象，因此您应该期望在“响应标头”面板中看到以下属性：

X-Cache: TCP_HIT from a96-17-171-7 (AkamaiGHost/6.3.0-7086845)

值TCP_HIT表示Akamai边缘服务器正在从缓存中返回文件，不需要回到我们的数据中心来获取相同的文件。

什么是缓存中毒？

边缘服务器缓存中毒是一种意外情况，它会向缓存提供数据，但不代表正在缓存的资源。 由于边缘服务器缓存的资源在下一个请求中返回，因此确保缓存的数据代表该资源的正确内容非常重要。

以下是一种可能会用无效数据“毒化”边缘服务器缓存的方案。

假设最终用户尚未通过身份验证，并请求一个受保护的资源，例如foo.gif。 假设foo.gif尚未在缓存中。 Akamai边缘服务器将请求发送到我们的数据中心。

我们的后端应用程序服务器前有一个WebSeal服务器。 当用户请求受保护的资源但尚未通过身份验证（或他们的身份验证会话已过期）时，初始请求不会到达后端服务器。 而是WebSeal服务器返回HTML登录页面（以便用户可以登录），该页面具有HTTP响应代码200代替请求的资源。

Akamai现在会收到登录页面。 由于响应代码为200，因此Akamai假定请求成功，并将响应保存到缓存中。 Akamai缓存现在被错误的对象所毒害。 下次用户请求foo.gif时，响应将从Akamai缓存返回登录页面。

防止中毒Akamai缓存的最佳做法

有两种最佳做法可防止中毒缓存：

• 在响应标头中正确标识服务器。
• 确保您的应用程序返回正确的状态代码。

在响应标头中正确标识服务器。 通过定义配置可以避免这种情况，这样它就不会缓存直接从执行重定向的WebSeal反向代理服务器提供的任何内容。

Akamai软件可以通过查看响应头中的“服务器”属性来检查服务器的类型。 例如，如果响应来自WebSeal反向代理服务器，则服务器标头的值为Server: WebSEAL/6.1.0.0 。 如果响应来自我们的后端应用程序服务器之一，例如WebSphere sMash，则服务器标头的值为Server: IBM WebSphere sMash/1.1.1 。

确保您的应用程序返回正确的状态代码。 未能从您的应用程序发送正确的状态代码似乎没有什么害处，但是当尝试启用到边缘服务器时，这可能是一个真正的问题。 仅当响应成功且返回的数据为预期的数据时，请确保发送回HTTP 200响应。 如果响应代码为200，则边缘服务器将自动缓存所有可缓存的内容。

通常，优良作法是实施HTTP状态代码并为Web解决方案创建特定于应用程序的特定错误页面。

清除缓存

有时有必要刷新Akamai边缘服务器中缓存的内容，而不必等待边缘服务器配置中指定的过期时间。 例如，您可能需要对JavaScript中的错误进行快速修补或更新现有图像。 或者，您可能希望使用应用程序的较新版本刷新整个应用程序。

Akamai提供了一个灵活的Content Control Utility，您可以使用它来执行此任务。 您可以简单地进入Akamai Edge Control门户，并使用面板指定要刷新的URL。 内容刷新后，Akamai会通过电子邮件通知您。 您还可以使用其SOAP API以编程方式刷新内容。

结论

本文介绍了将Akamai与IBM Cloud中运行的应用程序集成时的经验教训。 总体而言，图中Akamai缓存的性能提高了50％以上。

尽管本文主要侧重于通过缓存提高性能，但Akamai提供了其他功能，我们可以利用这些功能为SaaS应用程序启用故障转移和负载分配。 这是一项独特功能，因为云提供商可能不支持用于负载平衡的专用硬件。 故障转移和负载分配集成提高了我们SaaS应用程序的整体可用性和性能。 我们将在以后的文章中讨论这个主题。

致谢

我们的团队喜欢与Akamai团队合作。 他们不仅知识渊博，而且很有趣。 作者要感谢Akamai的Patrick Boucher，IBM的Tom Mikalsen和Bhadri Madapusi对本文的帮助。

翻译自: https://www.ibm.com/developerworks/cloud/library/cl-cloudappcomfeatures/index.html