With Amazon EFS, you can monitor network throughput, I/O for read, write, and metadata operations, client connections, and burst credit balances for your file systems. If performance falls outside your established baseline, you might need to change the size of your file system or the number of connected clients to optimize the file system for your workload.
To establish a baseline, you should, at a minimum, monitor the following items:
* Your file system's network throughput. * The number of client connections to a file system. * The number of bytes for each file system operation, including data read, data write, and metadata operations.
You can use the following automated monitoring tools to watch Amazon EFS and report when something is wrong:
* Amazon CloudWatch Alarms * Amazon CloudWatch Logs * Amazon CloudWatch Events * AWS CloudTrail Log Monitoring
For your use case I suggest monitoring Amazon EFS with Amazon CloudWatch. For more details on how to use Cloudwatch to monitor EFS refer to below article,
Amazon EFS delivers more than 10 gibibytes per second (GiBps) of throughput over 500,000 IOPS, and sub-millisecond or low single digit millisecond latencies. The following documentation provide an overview of Amazon EFS performance, and describe how your file system configuration impacts key performance dimensions. We also provide some important tips and recommendations for optimizing the performance of your file system.
To improve read performance :
The easiest way to increase read performance would be to implement a cache on the instance, such that read requests to the EFS would be served from the local disk used by the instance. This would improve performance as there would be no network or metadata access induced latency, which improves the performance of the read requests. This would also reduce the I/O sent to the EFS, which is useful for general performance EFS. Such a cache is known as a file system cache, or FS-cache, and a common example of FS-cache is cachefilesd. However, note that the downside to using a cache is that the cache must be checked first before the EFS, so this cache would not help if the application is constantly accessing new files from the EFS.
To improve write performance
The only way to improve the write performance would be to implement your writes in parallel. This can be done using multiple EC2 instances (i.e. multiple clients) or using utilities such as GNU parallel, msrsync, or fpsync.
For more EFS performance tips refer to below article,
If you would like to further deep dive into the root cause of the performance issue then I request you to raise a case with AWS ECS support as the support engineer would be able to look into the account ECS/EFS performance metrics for further analysis.
EFS vs EBS mult-attachAccepted Answerasked 3 years ago
EFS metrics not showing and EC2 cannot write on EFSasked 3 months ago
EFS high metadata IOasked 6 months ago
How to mount EFS on ECS with IAM username of who started EC2 instance ?asked a year ago
What is the total number of EFS volumes that can be created in a VPC?asked 9 months ago
EFS price based on giga bytes:asked 2 years ago
EFS performance/cost optimizationasked 8 months ago
EFS throughput mounted on many instancesAccepted Answerasked 3 months ago
EC2 Task EFS mount issueasked a year ago
EFS Throughput not exceeding 1MBasked 10 months ago