Rest interface very slow loading items

After doing some elimination, I’ve narrowed it down to the following items linked to my Alexa control binding for my four echos so I’m going to raise the question in that thread to see if we can figure out what’s going on

AmazonPlayListId (adds about 300ms each)
PlayAlarmSound (adds about 400ms each)
PlayMusicProvider (adds about 800ms each)

How big is the data stored in those String Items?

Are these the only Items with a tag?

Not much data at all. AmazonPlaylistId and PlayAlarmSound are both empty (PlayAlarmSound also returns 15 options but none with long values or labels) and PlayMusicProvider only has a short string (“TUNEIN” for my test echo) with 5 options but again none with values or labels that are very long (the longest is “I_HEART_RADIO” for example)

None have a tag (if you mean [“tag”] in their definitions)

Here are the actual item definitions for reference, the item definitions for the other three echos are identical and all have the same delays when called individually


String Echo_Kitchen_AmazonMusicPlayListId         "Echo Kitchen Amazon Music Playlist Id (Write Only)"  (Alexa_Kitchen) {channel="amazonechocontrol:echo:echoAP:SerialNumber:amazonMusicPlayListId"}

String Echo_Kitchen_PlayAlarmSound                "Echo Kitchen Play Alarm Sound"                       (Alexa_Kitchen) {channel="amazonechocontrol:echo:echoAP:SerialNumber:playAlarmSound"}

String Echo_Kitchen_PlayMusicProvider             "Echo Kitchen Play Music Provider"                    (Alexa_Kitchen) {channel="amazonechocontrol:echo:echoAP:SerialNumber:musicProviderId"}

OK, I’m out of ideas. I’ve no idea why these Items would be any different from any others unless somehow they need to ask the binding for the value first. But I’m all but certain that isn’t how it works. It should just grab the current state of the Item as it exists in the Item registry at that time.

I think that’s exactly what it is. I turned on debug logging for that binding and every time I made a REST call to one of those three items three log entries for calls to amazon.com popped into the log. Thankfully I wasn’t using those channels yet so for the time being i’ll leave them commented out.

Thanks for this, after some debugging of my slow REST interface, this turned out to be the cause here as well. Running on 2.3.0 release, 6-700 items. ~100 msec for rest/items over HTTP, but when all alexa items activated I got 2-6 seconds, measured using 'time curl '.

Just as you, not all items in my alexa.items were problematic, so I have been able to keep those I use (mainly TTS).

Did you post something in another thread more specific to the alexa binding on this issue?

I posted about it a few times actually in the main thread for the Alexa control plugin but my posts kept getting buried in other conversations going on in that thread. Eventually michi responded that he’s not aware of any solution to the problem unfortunately, in this comment

@Kai, can the DynamicStateProvider be the reason for the slowdown of the REST Interface? Is there somerhing what I can fix in the binding? Maybe a cache?

So is this specifically about the EchoControl binding? I.e. if it is started, the REST API is slow and when the bundle is stopped, it is fast?
If so, yes: The DynamicStateProvider could be the culprit, if it does expensive operations. Any improvement of its implementation (such as doing caching) should make it faster.

It‘s not expensive in the sense of CPU usage, but it makes REST calls to the Amazon server which takes some time

Well, external HTTP requests are the worst thing you can do in a synchronous call - that definitely needs to be cached! Maybethis is helpful for such purposes.

Hi,

i’m currently also having problems with this. Has there been any progress on this?

Cheers

Sam

Hi All

Ive just found this post, and I have the exact same issue.

Thanks zolakk for posting, I commented out those items and my REST items speed reduced from 7seconds to 139ms.

The HabPanel dashboard is incredibly snappy now!!!

This definitely needs looking at.

Hi zolakk do you still have this performance issue with Alexa Echo binding and slow load in REST? ive got the same issue.

Yeah, still having that problem and now running release 2.4 with the official 2.4 binding. I’ve just accepted that it won’t work and took those items out altogether at this point, unfortunately.

Im running 2.4 release with the latest binding, I took those items out but its still slow (3500ms)

How were you able to determine the exact items causing the issue as im happy to comment them

It’s these two:
musicProviderId (adds about 800ms each)
amazonMusicPlayListId (adds about 300ms each)

I just commented out one item at a time and watched how it impacted the ‘items’ loading time in my browser developer window until I narrowed it down to those

Yes, ive already commented them out and its still slow. But how did you determine it was those? Clearly its slow for me on OTHER items so i need to work out which ones. Hoping you can share how you troubleshooted determinining those to be the cause

Sorry, I edited my response with what my current slow items are while you were replying. The three I listed before were for an old version of the binding