Alexa response delayed when using reverse proxy

I’m new to Home Assistant but I got the Alexa smart home integration setup and working. I’m using HA in a docker container behind a reverse proxy and everything works well. But I noticed there is a delay between me saying a command and the response I get.
The commands are just a simple “turn on” or “turn off” and according to AWS lambda console, the duration for these requests can take up to 1.5 seconds in some cases.

I tried to track down the issue and tried different reverse proxies (cosmos-cloud, nginx proxy manager) but that didn’t solve anything. So I forwarded the port of HA directly and used that as endpoint for the lambda function. That solved my problem, the request time is only 1/5 of what it was when using a reverse proxy and the response feels almost instant.

While that solves my problem, I would rather have everything going through the reverse proxy for https and to avoid exposing HA directly to the outside network.

Don’t know what to say other than stateful packet inspection takes time?

2 Likes

So that delay is expected when using a reverse proxy and https?
It’s a really bad user experience with it but otherwise its less secure.

Is it standard practice to only go through http for lambda functions to get the fastest response possible?

I’d say… A delay is expected. As to the nature and impact I couldn’t begin to tell you if 5x is expected. I don’t know exactly what the most critical perf metric for this is but… I suspect CPU/GPU (decrypting and terminating your SSL sessions) and the review of groups of packets against threat. So I’m not at all suprised. Better iron should help.

Would you say having HA exposed without https is a security risk? I’m using a strong password and have MFA enabled.

What do you mean with “better iron should help”? Better CPU / GPU ?
I’m running HA on a thinkcentre M710q with an i3-6100T @ 3.2 GHz, 8 GB RAM but without a dedicated GPU.

A way to only accept http requests on certain paths would helpful. Then I could have everything on https except the requests from Alexa. Maybe I’ll have to look into something like Nginx or Apache to drop all http requests except the ones on the /alexa path.

ABSOLUTELY. Don’t do it.

So you’re telling me to just deal with the delay as there is no reasonable way to get it lower. And everyone using https that way has to have a bad user experience

I’m saying to deal with it you need a more powerful box. Physics and computer science are real things and at the end of the day you added more processing - that takes more time.

You’re asking why a Honda Accord won’t pull sub 5 seconds in a quarter mile. (not enough power)

When we build these things in production we add accelerator cards to handlebthe decryption of SSL in hardware because it absolutely hammers a box. You can get it down but it probably costs more money than you’re willing to spend. I’d bet more ram and a faster processor do result in better times here but without detailed perf analysis you won’t know.

1 Like

That was not the answer I was hoping for but the one I needed to hear probably.

I’ll try a few things without compromising security and see if that helps in any way.

Thank you

2 Likes

I kinda found a solution. I just increased the memory for the lambda function to 2 GB and it brought the request time down to about 200-300ms.
Still not 100% perfect but really close and much better than the more than 1 sec from before.
Further increasing the memory did not make any significant difference so I left it at 2 GB to not risk going over the free limit

1 Like