3 ms·
> They said in most cases it doesn’t make a big difference… unless you use the REST API. So in the end it was a coding problem, because you forgot to add Keep-
by alexfi 9y ago
> They said in most cases it doesn’t make a big difference… unless you use the REST API.
So in the end it was a coding problem, because you forgot to add Keep-Alive = true? If you use the provided SDK's it should be no problem then right?
- Buge 9y agoI don't think Keep-Alive = true would be enough. The article also mentions TLS session tickets would be necessary. And it's hard to call this a coding problem if the requirements of the API never specified that session tickets and keep alive were necessary.
- alexfi 9y agoYeah it's no coding problem on purpose, but sth you could actually fix. But it's not good manner to not mention it from Firebase.
- mining 9y agoIt's absolutely good manners for Firebase to tell you "If you fix this thing, your costs will go down."
- izacus 9y ago> It's absolutely good manners for Firebase to tell you "If you fix this thing, your costs will go down." I wonder how many HN startup founders go around telling their customers on how to pay less.
- weddpros 9y agoWith keep-alive you may not even need TLS session tickets (if the keep alive timeout is long enough). keep-alive keeps the HTTP/TLS socket open. TLS session tickets allow to close and "cheaply" reopen TLS session on a new socket for a new HTTP connection. Using both keep-alive and TLS session tickets is optimal.