Timer event fires irregurarly
I'm trying to create a simple performance logging function in my script tests. What I want to do is to set a timer that will call this logging function regularly during the entire program run, and eac...
Forum Discussion
I must say that your replies are extremely helpful :) I've read quite a lot about WMI and also confirmed that all the data I need to gather is accessible through WMI objects (and I also know the name of the ones I need).
I have now started to look into the different ways to go:
My conclusions regarding the above so far are the following:
I've done some more testing with timer accuracy in my scripts and have come to the conclusion that they don't really become any more accurate with longer intervals either (tested 60 and 120 second intervals on 50 minute runs). So I have excluded timers as a part of the WMI implementation. The alternative solution I've found is to log on events in the tested application. This is something that has been requested from my implementation and it seems like a nice solution.
The only problem here is that if the application runs without having any user interactions I guess no subscribed events will be fired and caught by TC, which will create large "blanks" in the log during i.e. data processing sessions where the application may be busy for several hours.
My conclusion at this moment is that WMI objects are the preferred way to go if I can find any way go get a reliable way of performing some occasional periodical testing for those times that doesn't have events that can cause logging. Timers doesn't seem to work for my testing at all - their accuracy is really terrible :)
Maybe it's possible to subscribe/listen to some more "rare"/"unusual" events that fire very often, but usually aren't of interest, and use them as a replacement for timer events? I guess .NET applications have hundreds of various kinds of events being fired every second, but only a fraction of them are of interest to me as a tester. But if I would take interest in some of these, they could provide me with regular logging pauses.
It may be worth pointing out that I don't really need super accuracte timings on my monitoring - I just want to be able to always make sure that I monitor data once in a while. But my tests with timers show that they are unreliable and therefore I need some way of getting periodic monitoring measurements.
I have now started to look into the different ways to go:
- Use perfmon in a GUI scripted manner
- Use perfmon via logman from the command line
- Use WMI to gather data inside the script, without the use of any external application.
My conclusions regarding the above so far are the following:
- It's easy but pretty unsafe to use the perfmon GUI, since the script is sensitive to unexpected and unfocused windows, components being disabled etc. The settings are quite complex to set ut since you either have to create script routines for that or work on the XML templates.
- It's both easier and safer to use logman to launch perfmon, since there's no graphical interference when performaing starting and stopping actions. I guess the settings are just as complex to manage as the previous - guess it'll be have to be done in the same way.
- WMI objects are equally easy to use as logman - just run it from the script. The major issue lies in the fact that the WMI objects seems to need to updated explicitly and periodically in order to get monitoring data. The two previous alternatives leave that task to the perfmon process.
I've done some more testing with timer accuracy in my scripts and have come to the conclusion that they don't really become any more accurate with longer intervals either (tested 60 and 120 second intervals on 50 minute runs). So I have excluded timers as a part of the WMI implementation. The alternative solution I've found is to log on events in the tested application. This is something that has been requested from my implementation and it seems like a nice solution.
The only problem here is that if the application runs without having any user interactions I guess no subscribed events will be fired and caught by TC, which will create large "blanks" in the log during i.e. data processing sessions where the application may be busy for several hours.
My conclusion at this moment is that WMI objects are the preferred way to go if I can find any way go get a reliable way of performing some occasional periodical testing for those times that doesn't have events that can cause logging. Timers doesn't seem to work for my testing at all - their accuracy is really terrible :)
Maybe it's possible to subscribe/listen to some more "rare"/"unusual" events that fire very often, but usually aren't of interest, and use them as a replacement for timer events? I guess .NET applications have hundreds of various kinds of events being fired every second, but only a fraction of them are of interest to me as a tester. But if I would take interest in some of these, they could provide me with regular logging pauses.
It may be worth pointing out that I don't really need super accuracte timings on my monitoring - I just want to be able to always make sure that I monitor data once in a while. But my tests with timers show that they are unreliable and therefore I need some way of getting periodic monitoring measurements.
