SmartThings Community

SmartApp Caching update


(vlad) #3

Fixed! I meant October - May 14th is the day of my wedding… :head_bandage:


(Tony - SmartThings Unpublished Contributor ) #4

As long as you don’t reverse that mistake, you’ll be fine.


(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #5

While using a Checksum to identify identical code and making the suggestion above is excellent; I hope this is only a “stop-gap” measure to the real solution: Allow full distribution self-publishing of SmartApps to the Community.

Oh wait… we already had that ability and it was revoked. SMH :confounded:.


(DavidK) #6

@vlad

Which Graph Shows This? What does this mean? Did you automatically upgrade people to the latest smart apps on their behalf?

What does “Red line represents canary nodes” mean?


(vlad) #7

First graph shows a drop in CPU usage because of the decrease in garbage collection frequency which translates into less time spent by the nodes in garbage collection. When a major garbage collection event occurs it is a “stop the world” scenario where all processing stops during that time apart from garbage collection. Since the number of classes that need to be loaded have decreased dramatically the GC doesn’t need to run as often or for as long. The second graph shows that our memory usage dropped to about half when loading these classes. Previously we were pretty much at the limit of classes that we could load so garbage collection would occur very frequently now since there is a lot more headroom with the decreased memory usage garbage collection does not occur nearly as often.

So for example say it’s 5:00 PM and a lot of people have executions scheduled as they come home - prior to the change every installation of CoRE or Nest Manager would load it’s own class into the JVM. This would result in a lot of duplicated classes being loaded and having to be unloaded for the next person’s execution to be loaded afterwards because a garbage collection needs to be performed to make room for the next execution. As the number of users/schedules increases then we end up spending more and more time loading/unloading classes to make room for them in the JVM. With this change the vast majority of users are using the latest code for these Apps so they all share the same class - so no (or a lot less) time has to be spent loading/unloading these SmartApps.

We have not automatically updated anyone’s SmartApps - the reason we saw a drastic reduction in CPU usage is because in the worst case scenario (everyone having different versions of a SmartApp) we would not have seen any reduction in CPU usage/GC times but because most people are already using the same version of the SmartApp (the latest one) the GC times dropped as all of those people share the same Class in the JVM when they executed. I do recommend updating to the latest code when you can though - as it is much more likely that the SmartApp that is being executed is already loaded into the JVM at that point. For small apps it’s not a big deal as it doesn’t take long to load the Class into the JVM but as the apps get larger, it takes significantly more time to parse/load the class (and then unload it after)

Canary nodes are generally used to verify JVM tuning parameters before rolling them out to all of the servers. Changes are tested in lower environments first but it is safer to update a couple of nodes when we can before rolling out the changes to all nodes in the cluster. In this case the canaries were running under the same settings as the rest of the cluster so it doesn’t mean much but I just wanted to call it out as there was a big red line in the graph. (Should’ve been clearer on that in my first post).


(Jeffrey) #8

I always enjoy hearing about these kind of updates and efficiencies and it shows we are moving to a much more scalable platform. The ironic thing about this is I would say the system has been a wreck for about a week now but hopefully more changes like this keep the big machine running smoothly. Keep up the good work guys.


(Marc) #9

Perhaps I am missing something here. Performance in the iOS mobile app has been awful this week. Is this just laying the groundwork for improvements and that is why we haven’t seen any improvements this week?

CoRE and Nest Manager are very slow. Even going into my “Smartapps” tab is extremely slow. I know you said they need to be updated, but not sure if those are being planned?


#10

Hope so too, because from my point of view the IDE, smartapps, mobile apps, etc., are currently running slower than my grandmother :unamused:


(vlad) #11

The issues you are describing are unrelated to this update, they are being cause by latency problems with one of the databases. While these changes provide some overall performance improvements - unfortunately they don’t help with database timeouts.


(Michael Hess) #12

So for those of us that are a bit thick, old style was basically a JVM gets spooled up for each instance of a SmartApp PER USER. Now only one gets spooled for each version but more than one users can use it at a time? So GC only occurs when no users are actively “touching” that JVM, vs before each users app JVM would be killed at the end of that users use of it?


(greg) #13

just joining the discussion today. Vlad, can i interpret your response to mean you are aware of unusual slowness in the IDE and are already working on a fix?

symptoms i observe are:

  • IDE taking > than 1 minute to save
  • simulator taking many minutes to move through app settings.

(vlad) #14

Not quite - there is only one JVM in play per Scheduler node. The actual executions are sandboxed within that JVM. That hasn’t changed. Think of it like this:
User A & B both have a community SmartApp. The code for the SmartApp is the exact same, meaning that the code gets compiled into the same Class. Previously we would create 2 Classes (One for each user) - each taking up its own memory. Now when user B executes (given that user A already did) when we look up the SmartApp to execute in the cache, we see that there is already a SmartApp with the same checksum in the cache (aka the code is the same) so instead of creating a new class for user B we just reuse the one that was created for user A. GC comes into the picture when we multiple this situation by thousands or tens of thousands of users and smartapps and we are at a memory limit. If User B tried to to execute and there wasn’t enough room in memory to create his SmartApp, User A’s Smartapp would have to be garbage collected first (major GC - stop the world collection because of how Class unloading works) to make room for User B’s SmartApp. Now - since we’ve de-duplicated a lot of SmartApps we’re not at the limit anymore and even if we were, chances are that the SmartApp is already in memory and we wouldn’t have to perform a GC anyway.


SmartApp Latency issues?
(Michael Hess) #15

Awesome, I can picture that clearly now. Sounds like a FAR more efficient method!


(vlad) #16

Yes - we are aware of latency issues and are actively working on resolving it.


(Brian) #17

@vlad you rock. Hope you know. Keeping us animals fed with tidbits like this just keeps us going. Thanks.


(Tim Slagle) #18

@vlad is my new favorite co-worker. He pushed out @Aaron for the lead.


(Aaron S) #19

I wish I could be angry, but it’s true (and it’s really not fair because @vlad is better looking too?!)


#20

Very good news!


(Darryl) #21

That @vlad is better looking? :slight_smile:


(Eric) #22

My ST app is still slow as heck. I have a few apps that are timing out also, getting the 20 second error… Specifically when trying to rebuild a core piston.