Hacker News Reader

Comment by scottfr | Hacker News Reader

> First, I ran a small sample of 2000 requests to check the performance of new deploys. This was running at around 40 requests per second.

...

> When I ran my initial Fargate warmup, I got the following results. Around 10% of my requests were failing altogether!

....

> To remedy this, I decided to bump the specs on my deployments.

> The general goal for this bakeoff is to get a best-case outcome for each of these architectures, rather than an apples-to-apples comparison of cost vs performance.

> For Fargate, this meant deploying 50 instances of my container with pretty beefy settings — 8 GB of memory and 4 full CPU units per container instance.

View on HN

This is what caught my eye too. I'm not familiar with the guts of Fargate, but this seems like very poor performance?

I sort of suspect the error wasn’t just about resources, since it continued after given gobs of resources.

Author here. Yep, that was my suspicion as well so I didn't hold it against Fargate. I was more looking for a reasonable expectation of performance, so I just threw a ton of resources at it to rule out as much as possible.

One of the AWS container advocates mentioned it was likely something like the nofile ulimit: https://twitter.com/nathankpeck/status/1098992994131283968

Having run a service on Fargate in prod before I can almost guarantee that the errors he was seeing were 504s which are caused by the server code and the ALB not having their request-timeouts set to to the same value.

I agree. This tripped me up when I first started using a fargate service behind an ALB. Easy fix.

It’s my understanding that you want to set the timeout in the server code to be higher than the idle connection timeout in the ALB. With them set to the same value, timeout errors will look different depending on whether the application or the ALB dropped the connection.

I don't see how this could be a symptom of Fargate as such, but rather of ECS. I mean, all Fargate does is add management features to the VMs running the containers. So if there's a problem with the runtime behavior of the containers, it seems like that would be something in the ECS infrastructure.

Reply on news.ycombinator.com