Hacker News Reader

Comment by alexeldeib | Hacker News Reader

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

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.

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.

Reply on news.ycombinator.com