

# Performance and optimization
<a name="Performance"></a>

This section describes guidance and best practices for optimizing File Gateway performance.

**Topics**
+ [Basic performance guidance for S3 File Gateway](#performance-fgw)
+ [Performance guidance for gateways with multiple file shares](#performance-multiple-file-shares)
+ [Maximizing S3 File Gateway throughput](Performance-Throughput.md)
+ [Optimizing S3 File Gateway for SQL Server database backups](SQL-Backup-Best-Practices.md)

## Basic performance guidance for S3 File Gateway
<a name="performance-fgw"></a>

In this section, you can find guidance for provisioning hardware for your S3 File Gateway VM. The instance configurations that are listed in the table are examples, and are provided for reference.

For best performance, the cache disk size must be tuned to the size of the active working set. Using multiple local disks for the cache increases write performance by parallelizing access to data and leads to higher IOPS.

**Note**  
We don't recommend using ephemeral storage. For information about using ephemeral storage, see [Using ephemeral storage with EC2 gateways](ephemeral-disk-cache.md).  
For Amazon EC2 instances, if you have more than 5 million objects in your S3 bucket and you are using a General Purposes SSD volume, a minimum root EBS volume of 350 GiB is needed for acceptable performance of your gateway during start up. For information about how to increase your volume size, see [Modifying an EBS volume using elastic volumes (console)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/requesting-ebs-volume-modifications.html#modify-ebs-volume).  
The suggested size limit for individual directories in the file shares that you connect to File Gateway is 10,000 files per directory. You can use File Gateway with directories that have more than 10,000 files, but performance might be impacted.

In the following tables, *cache hit* read operations are reads from the file shares that are served from cache. *Cache miss* read operations are reads from the file shares that are served from Amazon S3.

The following tables show example S3 File Gateway configurations.

### S3 File Gateway performance on Linux clients
<a name="performance-fgw-linux-clients"></a>

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/filegateway/latest/files3/Performance.html)

### File Gateway performance on Windows clients
<a name="performance-fgw-windows-clients"></a>

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/filegateway/latest/files3/Performance.html)

**Note**  
Your performance might vary based on your host platform configuration and network bandwidth. Write throughput performance decreases with file size, with the highest achievable throughput for small files (less than 32MiB) being 16 files per second.

## Performance guidance for gateways with multiple file shares
<a name="performance-multiple-file-shares"></a>

Amazon S3 File Gateway supports attaching up to 50 file shares to a single Storage Gateway appliance. By adding multiple file shares per gateway, you can support more users and workloads while managing fewer gateways and virtual hardware resources. In addition to other factors, the number of file shares managed by a gateway can affect that gateway's performance. This section describes how gateway performance is expected to change depending on the number of attached file shares and recommends virtual hardware configurations to optimize performance for gateways that manage multiple shares.

In general, increasing the number of file shares managed by a single Storage Gateway can have the following consequences:
+ Increased time required to restart the gateway.
+ Increased utilization of virtual hardware resources such as vCPU and RAM.
+ Decreased performance for data and metadata operations if virtual hardware resources become saturated.

The following table lists recommended virtual hardware configurations for gateways that manage multiple file shares:


| File Shares Per Gateway | Recommended Gateway Capacity Setting | Recommended vCPU Cores | Recommended RAM | Recommended Root Disk Size | 
| --- | --- | --- | --- | --- | 
|  1-10  | Small |  4 (EC2 instance type **m4.xlarge** or greater)  |  16 GiB  |  80 GiB  | 
|  10-20  | Medium |  8 (EC2 instance type **m4.2xlarge** or greater)  |  32 GiB  |  160 GiB  | 
|  20\$1  | Large |  16 (EC2 instance type **m4.4xlarge** or greater)  |  64 GiB  |  240 GiB  | 

In addition to the virtual hardware configurations recommended above, we recommend the following best practices for configuring and maintaining Storage Gateway appliances that manage multiple file shares:
+ Consider that the relationship between the number of file shares and the demand placed on the gateway's virtual hardware is not necessarily linear. Some file shares might generate more throughput, and therefore more hardware demand than others. The recommendations in the preceding table are based on maximum hardware capacities and various file share throughput levels.
+ If you find that adding multiple file shares to a single gateway reduces performance, consider moving the most active file shares to other gateways. In particular, if a file share is used for a very-high-throughput application, consider creating a separate gateway for that file share.
+ We do not recommend configuring one gateway for multiple high-throughput applications and another for multiple low-throughput applications. Instead, try to spread high and low throughput file shares evenly across gateways to balance hardware saturation. To measure your file share throughput, use the `ReadBytes` and `WriteBytes` metrics. For more information, see [Understanding file share metrics](https://docs.aws.amazon.com/filegateway/latest/files3/monitoring-file-gateway.html#monitoring-file-gateway-resources).