Local REST API is very slow (after recent FW update?)

:hot_face:I think after recent FW update. Many HomeSeer AKBond plugin users report the timeouts, and I can confirm myself.

Sometimes 10-15 seconds, also includes BPUP udp reply.

I increased sleep between sends to 500ms, and socket timeout to 10sec, still timeouts sometimes.

Have you or the users tried and documented any of the same delays in:

a) the Bond app
b) direct command line cURL / Postman / other API calls (to eliminate HomeSeer from the variables)

Don’t think myself or anyone else in the community has recently reported slowness of the amount you’re reporting.

Also, if you have a way to see which firmware version(s) your users (and you) are running, that will probably be good information for the Bond team.

Problem is - it doesn’t timeout from single command, but when I request all devices and groups, you can see that sometimes reply takes more than 2-5 sec, sometimes more than 10:

11/07/2023 0:00:45	AK Bond	Info	[1447] 'My Bridge': Execute(sync)'GET' {Response} [http://192.168.1.26/v2/groups]: The operation has timed out (tm 10018). Retry(2)
11/07/2023 0:00:45	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/groups): 10018 ms
11/07/2023 0:00:34	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/2e65abcb/state): 3423 ms
11/07/2023 0:00:31	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/332d1883168e91f6/state): 204 ms
11/07/2023 0:00:30	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/47cc0984/state): 161 ms
11/07/2023 0:00:29	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/79238147/state): 71 ms
11/07/2023 0:00:29	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/1756f1e7/state): 436 ms
11/07/2023 0:00:28	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/4a28142a/state): 254 ms
11/07/2023 0:00:27	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/332d1883168e91f6): 111 ms
11/07/2023 0:00:26	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/79238147): 57 ms
11/07/2023 0:00:26	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/4a28142a): 59 ms
11/07/2023 0:00:25	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/2e65abcb): 62 ms
11/07/2023 0:00:25	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/47cc0984): 71 ms
11/07/2023 0:00:24	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/1756f1e7): 107 ms
11/07/2023 0:00:23	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices): 94 ms
11/07/2023 0:00:23	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/bridge): 100 ms
10/07/2023 23:59:23	AK Bond	Trace	[1447] 'My Bridge': *** StartUpdateTimer: 60000 ms
10/07/2023 23:59:23	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/2e65abcb/state): 5416 ms
10/07/2023 23:59:17	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/332d1883168e91f6/state): 1888 ms
10/07/2023 23:59:14	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/47cc0984/state): 235 ms
10/07/2023 23:59:14	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/79238147/state): 1394 ms
10/07/2023 23:59:12	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/1756f1e7/state): 2875 ms
10/07/2023 23:59:08	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/4a28142a/state): 46 ms
10/07/2023 23:59:08	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/332d1883168e91f6): 57 ms
10/07/2023 23:59:07	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/79238147): 52 ms
10/07/2023 23:59:07	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/4a28142a): 54 ms
10/07/2023 23:59:06	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/2e65abcb): 66 ms
10/07/2023 23:59:05	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/47cc0984): 62 ms
10/07/2023 23:59:05	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices/1756f1e7): 61 ms
10/07/2023 23:59:04	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/devices): 62 ms
10/07/2023 23:59:04	AK Bond	Trace	[1447] 'My Bridge': Request Time(http://192.168.1.26/v2/bridge): 174 ms
10/07/2023 23:58:04	AK Bond	Trace	[1447] 'My Bridge': *** StartUpdateTimer: 60000 ms

And yes, I log the FW version, and it looks like it started after update “v3.13.6” (but not certain)

I also don’t know of any other reports of a slowdown in the API on recent FW releases.

I second @residualimages’s ask about the Bond Home app. If the app is also very slow on the same Bridge, that tells us something is wrong on the Bridge FW side. If the app runs normally, then it’s something on the HomeSeer side.

App doesn’t send many requests in a row - so it’s not the same.

[EDIT]

Also, I log the request time in ms (see above) - so really nothing can be wrong on HomeSeer side. WebClient just waits for the reply.

App doesn’t send many requests in a row

Actually, if you do a swipe to refresh on the My Devices screen, the app will re-request every endpoint on the Bridge. This may take several seconds as it needs to read every device, group, device state, property, command, etc.

Crucially, the app uses parallelism of only 2 or 3 workers per Bond. That is, there’s only 2 or 3 outstanding HTTP connection attempts to the Bridge at any time. Just using a single request without any parallelism achieves nearly the same performance actually.

You may run into problems if you use a high parallelism, where there can be many outstanding HTTP requests. The TCP/IP stack on the Bridge only keeps track of a limited number of connections attempts (I think up to 8), and only one is handled at a time. So, if you are sending more than 8 requests at once, your source TCP/IP stack is going to go into exponential backoff which can result in long waits and timeouts.

I’m not certain that this is the problem here, just coming up with a hypothesis.

1 Like