Hacker News Reader

Comment by codeduck | Hacker News Reader

It's terrible. Very slow when we tried to use it. There are ways to work around this, and ways to tune the performance, but honestly it was not worth it for our use case and instead we found a way to make EBS work.

EFS is a great way to get a lot of iowait on your cpu graphs. Would not recommend it for anything that had to be fast.

View on HN

AWS just last week upped the read throughput speed on EFS pretty significantly (4x). That probably won't solve all of your speed problems and its still not as fast as EBS, but it might be worth giving it another try if your workload isn't write-heavy.

https://aws.amazon.com/about-aws/whats-new/2020/04/amazon-el...

I have to agree with this- I found it challenging to tune EFS to get the claimed performance. The most important details of any system like this are: provision a very large filesystem, use large files, use lots of concurrent access (threads or machines).

There is a whole market of small companies that make high performance filers that do what many people want but they also have limits (high cost/byte).

> we found a way to make EBS work.

Can you say more about what you did with EBS? It seems like it would be necessary to make some compromises in availability and disaster recovery because any given EBS volume is restricted to the availability zone where it was created.

We were hosting third party software in an EKS cluster and needed a way to share state between components of this system. We tried EFS initially but it actually killed the EKS cluster with iowait under load. We found a way to divert most of the systems requirements to local emptydir volumes, leaving only infrequently accessed media files on EFS

Would you recommend it for a CMS like system (Drupal) that's backed by a CDN?

(One of the product managers on the Amazon EFS team here). Drupal is a common application that customers use with EFS, both in combination with a CDN and without. The following are two important considerations when running Drupal on an NFS service like EFS:

i) You should configure the OPcache so that it does not revalidate its cache on every request. Cache validation uses stat() in a serial loop on potentially hundreds of files, where each stat() would add O(ms) to the request.

ii) We recommend you store log files locally. NFS does not define an atomic O_APPEND operation, so appends require a file lock to prevent interleaving with appends from other clients. I've seen PHP application do 100s of file locks to a log file per request, each adding O(ms) to the total request latency. This is what you'd like to avoid.

Reply on news.ycombinator.com