Forums

Much enjoyed the "Traffic" performance graphs "Hits per month / day / hour /minute" on the Web page of my dashboard. So I wonder maybe you guys can add one additional graph (similar to Google Webmaster Tools ) ?

The average time spent on loading a page.

Average over a minute, hour, day and month ?

Many thanks

That's not really something we can do for you. The time spent on a page would require that there be some javascript running on your page to ping the server and let it know that the user is on the page. That's why you have to include a javascript snippet in your page for Google Analytics. Basically, if you want the features of Google Webmaster tools, you should use Google Webmaster tools.

hmmm, or did you mean the average time the server spends returning a page to the user? average response time? We might be able to dig that stat out from somewhere...

Glenn, Harry,

I am not interested on the time user spent on a page, but the time it took the server to return the page. The graphs on the web tab of the dashboard can give an idea about how "busy" the site is - but not on the actual site performance.

If one would like to monitor performance, then there are many metrics to consider. The "average response time" Harry mentioned - would be one of these metrics and I think quite a helpful one.

Thanks for the suggestion -- we'll take a look at whether we can add that.

Another thing we've been considering charting is the number of busy/idle workers your app has, so that you can see when it's busy and if it ever gets maxed out. Perhaps we could even email you at times when all of your workers have been active for a long time so that you'd know you needed to upgrade... What do you think?

Good idea, since all this monitoring data I am trying to gather, at the end of the day - I need to know if I have enough resources to provide an acceptable performance (ex: sub second response time in 95% of hits ?) to the site users. Or maybe ... I need to upgrade my account with you guys and increase the resources available.

Since the number of "workers" available vs. those that are completely busy is a good performance metric, if you can give us an idea about how busy were the workers (per minute / hour / day / month) - that would be helpful for us and maybe drive some business for you too. Thanks

I know this is a slightly stale post, but ...

Giles, awesome idea. I would love to know this to be able to determine if it is worth it to upgrade. I know it would likely lead me to spending more money ;-)

I know this is a slightly stale post, but ...

Giles, awesome idea. I would love to know this to be able to determine if it is worth it to upgrade. I know it would likely lead me to spending more money ;-)

Well, how can we refuse that :-) I'll add another upvote. It looks like we could certainly do idle/busy workers, and perhaps the average request queue (eg. if your workers are all busy, how many requests are still waiting for a worker to process them). All of that could probably give a pretty good idea of when it's time to upgrade.

Awesome.

Any idea on the timeline of this?

Giles, do you think we might get to see this soon?

We don't give development timelines, but we will let you know when it's ready.

Well, how can we refuse that :-) I'll add another upvote. It looks like we could certainly do idle/busy workers, and perhaps the average request queue (eg. if your workers are all busy, how many requests are still waiting for a worker to process them). All of that could probably give a pretty good idea of when it's time to upgrade.

Any news about this feature?

No, none yet.

Sorry to bring back an old topic, but I am finding myself trying to diagnose occasional performance issues.

Until (if ever) idle/busy workers is implemented, what would you say is the best way to tell if the number of workers is too low for some workload at some point in time?

I know we have access to the response time in the access logs, but would the numbers there reflect the time spent waiting for an available worker, or does it only starts counting once a worker has picked up the request?

Thank you in advance for any information on this matter.

The response time includes the time spent in the queue. So, if you see response times, in general, increase (excluding static files accesses because they have a difference queue), then that could be pointing to worker numbers.

Thank you for the confirmation glenn, that's what I wanted to know.

I use the following regex to parse pa access logs if that's of help to anyone:

re.compile(
    r"""(?P<ip>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}) - - \[(?P<datetime>\d{2}/[a-z]+/\d{4}:\d{2}:\d{2}:\d{2} ([+\-])\d{4})\] \"(?P<method>HEAD|GET|POST|PUT|PATCH|DELETE) (?P<url>.+) (HTTP/1\.1\") (?P<statuscode>\d{3}) (?P<bytessent>\d+) ([\"](?P<refferer>(-)|(.+))[_\"]) ([\"](?P<useragent>.+)[\"]) \".*\" .+=(?P<responsetime>.+)""",
    re.IGNORECASE
)

"datetime" will have format '%d/%b/%Y:%H:%M:%S %z'.

nice, thanks!