I think he only said that cause your message was timestamped 4am, but I think that’s our server here, so 7am eastern… not too unreasonable!
Anyhow, down to business…
The statistics facilities in FSQL are a bit dispersed right now, and we’re trying to consolidate and enhance them. As for the values you posted, the most important/telling are the Avg. Group Execution Cost, the Delay, and the Queue Length.
Group cost: on average how long a group is taking to execute. Good indicator of how the database is acting, because the database queries are by far the biggest cost in executing a group. Any value under 100ms here is good, 5ms is extremely good. HOWEVER, this number can be thrown off by a lot of groups that run on triggers and aren’t triggered often- they get “executed” each cycle, but do very little work.
Execution Delay: on average how long a group has to wait from the time it’s due to execute to when it actually occurs. 15ms is about the normal overhead. Values above that, like on the order of 500ms-1sec+ indicate that either things are running slowly or there are too many groups running at the same time, so they end up waiting for their chance.
Queue Length: Very related to execution delay, it’s how many groups are waiting to be executed. That is, they’ve come up due to run, and now they’re waiting to be executed ASAP. This should basically always be 0. You might randomly catch it at 1. But if it’s more than that, it means things are backed up.
The biggest thing that causes backups is to have many many groups running relatively quickly. (.5 sec, 1 sec). The groups get into a scheduled queue, and when they’re due to run, they get put in an exec queue. If everything’s running at 1 sec, but the collective groups in the queue take longer than that to execute, those numbers up there are likely to change.
Now, I happen to know that in your particular project almost every group has a trigger, and that it doesn’t occur particularly frequently (I wouldn’t consider 5sec frequent). Therefore, the groups are doing very little work, and long story short your project is very efficient.
Hope this sheds a bit of light, like I said, we’re always trying to improve our statistics/troubleshoot facilities, and I think the next main release (4.2) will help this a bit.