It is stable. We haven't noticed. It works fine.

We had a few performance problems in the past reading the trace files. We had a bit of a bottleneck on the server side where all the trace files would come together. Although the server should be fast enough, and we didn't experience any bottlenecks on CPU or IOPS; everything was looking fine; CPU was at about 30 percent, and the disks were far from being busy. But the trace files were not being processed fast enough or there were more coming in than processed.

It became more and more of an issue and, at a certain point, we had no other choice than to delete trace files. We lost of a lot of information because the more trace files we had in the folder, the worse the speed, or the performance for processing trace files, became. It got slower and slower. That was a real problem we experienced a lot of times. That improved since the release of a certain version number. It isn't an issue anymore.

We're running it on a machine with eight logical CPU cores, no physical CPU cores. We are auditing about 60 SQL service instances, and it works fine. We are absolutely pleased by the performance at the moment.

There haven't been many stability issues. A couple of versions back, it would crash on the install. I would add an agent, go the central Repository, add the new server in, and it would crash just after the checks. I haven't seen that recently but I also haven't done many installs lately. I'm not sure if it's still an issue but I think it has gotten better.

The solution is stable.

I submitted a ticket (last year) about archiving/grooming of old records because the GUI functionality was not working. Per their recommendation, I ended up using a command line to do it.

It seems to be very stable.