3 ms·
This is what caught my eye too. I'm not familiar with the guts of Fargate, but this seems like very poor performance?
by alexeldeib 8y ago
This is what caught my eye too. I'm not familiar with the guts of Fargate, but this seems like very poor performance?
- CWuestefeld 8y agoI 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.
- reilly3000 8y agoI sort of suspect the error wasn’t just about resources, since it continued after given gobs of resources.
- abd12 8y agoAuthor 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 https://twitter.com/nathankpeck/status/1098992994131283968
- vanrysss 8y agoHaving 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.
- zleman 8y agoI agree. This tripped me up when I first started using a fargate service behind an ALB. Easy fix.
- lukeck 8y agoIt’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.