AWS中的Artifactory高可用性(HA)使用S3用于可伸缩存储或Amazon的弹性文件系统(EFS)可以为NFS文件存储实现。为EFS实现进行设计时必须考虑EFS如何工作的某些方面。

本文档解释了爆发吞吐量和预置吞吐量模式之间的差异，目的是使用EFS和Artifactory HA实现最佳性能。有关Amazon EFS的详细信息，请参见什么是Amazon弹性文件系统?

Amazon EFS性能概述

爆发吞吐量模式(默认模式)

Amazon EFS上的吞吐量随着文件系统的增长而增长。文件系统可以以其基准速率持续驱动吞吐量。此外，Amazon EFS被设计为在一段时间内突发到高吞吐量水平。

有关EFS性能的完整文档，请参见Amazon EFS中的吞吐量扩展．

Amazon EFS使用信用系统来确定文件系统何时会崩溃。随着时间的推移，每个文件系统都以由文件系统大小决定的基准率获得积分，并在读取或写入数据时使用积分。当文件系统处于非活动状态或使吞吐量低于基线速率时，文件系统就会累积burst credit。

如果文件系统没有可用的突发积分，则I/O吞吐量是基线速率，直到突发积分补充。基线速率可能严重影响Artifactory性能。因此，最好的做法是完全避免或很少需要突发信用，而是能够通过基线吞吐量分配提供所需的全部吞吐量。您可以通过使用监控余额亚马逊EFS的亚马逊CloudWatch指标．

预置吞吐量模式

如果您发现由于小容量文件系统或吞吐量需求峰值，爆裂吞吐量模式的性能受到限制，那么您可以选择供应吞吐量模式。预置吞吐量提供了设置吞吐量级别的能力，该吞吐量级别将在使用文件系统时保持恒定和一致的高水平，与文件系统的大小无关。对于需要高吞吐量但文件系统相对较小的客户来说，这种模式非常理想，对于Artifactory用户来说这种情况并不少见。您可以在上找到有关预配置吞吐量使用情况和定价的详细信息AWS的网站．

如何确定哪种吞吐量模式最适合您的工作负载?

为了获得最佳结果，您必须考虑您的工作负载是什么，以及满足该性能所需的容量。这样说吧:使用突发吞吐量模式，文件系统中的容量越大，基准吞吐量和突发吞吐量就越高。

许多JFrog Artifactory服务器在存储中扩展到TiB范围，这对于用例来说通常是足够的性能。然而，对于较小的文件存储，基线吞吐量相当低:1 GiB的数据为50 KiB/s，并且在此基础上，每GiB线性扩展。如果您的工作负载所需要的吞吐量超过了上面描述的基线和突发模型所提供的吞吐量，那么您应该考虑配置吞吐量模式。

使用本地EBS缓存

您可以在Artifactory节点实例上使用本地EBS缓存。此选项减少了EFS文件存储上的工作负载，以及在burst吞吐量模式下使用突发信用余额。将Artifactory配置为在每个节点上的EBS中使用缓存。这些本地缓存将工件存储在每个单独的节点上，并将它们直接提供给客户机，而不是从EFS中提取它们。每个节点可能有重复的缓存条目(因为任何节点都可以为任何请求服务)，但这大大减少了对EFS的访问。重要的是要考虑到，如果使用S3作为二进制存储，也可以使用相同的机制来提高性能。这种方法可以让您更频繁地利用爆发能力，但仍然应该仅在基线吞吐量处于合理值时使用。特别要记住，在实现缓存时，它必须首先以EFS的速度流到缓存中，然后发送出去，因此如果EFS由于耗尽突发信用余额而运行得非常慢，这可能会导致客户端超时。如果您发现您遇到了信用余额的突发限制，或者遇到了客户端超时，那么您应该切换到Provisioned Throughput模式，以增加EFS的可用吞吐量。

例如，如果一个文件在没有本地缓存的情况下被下载了1000次，EFS的下载活动将是1000 *文件大小。但是，启用本地缓存后，它可能最终只有2 *文件大小。如果您不想在创建新实例时重新填充EBS缓存，建议将其持久化(非临时)。有关配置缓存的详细信息，请参见在binarstore .xml文件中配置文件存储的注意事项．

吞吐量不足/超过突发信贷余额的症状

存储设计不足的症状包括ping延迟(api/system/ping)和非常缓慢的下载/上传过程。延迟可能在Artifactory日志中显示为超时错误或由客户端超时断开引起的连接中断。

5.0之前的人工版本在S3存储上实现

如果使用S3存储实现5.0之前的Artifactory HA版本，则需要在共享NFS挂载上实现一个集群范围的写缓存(称为最终缓存)。Jfrog推荐使用预置吞吐量模式下的EFS缓存，因为它通常具有低存储和高使用率，这与EFS预置吞吐量模式设计支持的工作负载类型一致。对于Artifactory 5.0及更高版本，S3实现的缓存应该是EBS本地磁盘缓存。