Combres.ChangeMonitor.MonitorDynamicChanges - Performance

May 3, 2010 at 12:24 PM
Hi! We started to experience really slow performance in our application. When profiling it we were surprised to find that the time consumed by Combres.ChangeMonitor.MonitorDynamicChanges is 127 000 ms (one request). We have to be doing something wrong, settings? Any hints of how to address this? Regards Erik
May 3, 2010 at 12:56 PM

Hi, MonitorDynamicChanges() is executed by a separate worker thread to detect changes: the method keeps running and doesn't return, so the longer your app has started, the longer you'll see the method time in the profiler.  So the 127s (or more) shouldn't be the thing you have to worry about. 

One issue that I can think of about this method is that if localChangeMonitorInterval and remoteChangeMonitorInterval are set to small values, then the thread will occupy one CPU and thus may slow down the app.  Depending on the number of resources in your app and the available cores in your web server you should play around with these two settings to make sure the monitoring thread is not a problem. The higher the values, the less chance the thread will occupy the CPU although changes take longer to be noticed.

That said, I have looked at the code of MonitorDynamicChanges() and thought that I might be able to improve it to better utilize CPU while still doing what it's supposed to do.

May 4, 2010 at 6:44 AM

Thanks alot for taking your time.

I downloaded the source code and could see that the MonitorDynamicChanges wasn't the problem. It just looked that way until I checked the code and which threads was executed.. sorry fpr that..

One thought though, can I configure combres so that it doesn't check for changes and no background thread is started? Our release / deploy strategy will never make us update one resource only...

Thanks for an excellent piece of software btw!

May 4, 2010 at 8:48 AM
You're welcome. I'm glad you like the software. If you don't want change monitoring, just specify 0 in both localChangeMonitorInterval and remoteChangeMonitorInterval. The thread will still be running (because you can always change the 2 interval values any time in which case the thread needs to pickup), although now it mostly sleeps, sometimes wakes up to check for localChangeMonitorInterval and remoteChangeMonitorInterval and if it doesn't see any change, it just sleeps again. So, the CPU usage would be extremely low in this case.