What is Diagnose mode all about?As you already know, a RidgeStar Ineractive Site is a real-time Site. Naturally, this produces a need to provide an appropriate "Response Time" to the Visitor. We call this Internal Response Time and we very carefully measure each and every use of a Page on the Site AND its internal response time. This is how we know if a particular Server is operating smoothly or if there's some sort of a "response time problem" that we should investigate. So, it might be pretty cool to see a page's actual Internal Response Time while the Site is operating, eh? We agree and that is precisely what Diagnose Mode provides. When responding to reports of response time difficulties, we usually measure our internal response time with the wall clock time that a Visitor or User is experiencing at his or her System (as measured by the Visitor's "wrist watch time"). Of course, the difference between the internal response time and the wall clock time is the general overhead associated with the Internet and the Visitor's Access Provider and, well, you get the idea (for a little more, see Reference: RidgeStar-Wire Time). Diagnose mode permits you to obtain the precise response time measurements that the RidgeStar Server is providing. We cannot (under Server control) measure your wrist watch time, but we can sure tell you how long your request sat here in our Server getting processed.
What happens when Diagnose is on?You could see multiple Diagnose messages if the RidgeStar Technician provided multiple timing checkpoints during the page's execution. However, every page has a Start and Copyright entry, which permits the Server to compute and display the Internal Response Time (which will be displayed when Diagnose mode is on). Look at the top and the bottom of this page to observe Diagnose mode results, which consist of a single message marking the point at which the measurement was taken and the elapsed time in thousandths of a second from the Server's perspective (this is what we call the "Internal Response Time"). You may find that some pages (like this one) that don't have to do much processing may never break the old 0.000 seconds barrier. This is just the server telling you that it's providing the page's result pretty dang fast... To see a non-zero value, we recommend viewing a more complex page, like Locations. Enjoy your exploration in Diagnose mode! | |||||||
|
Key | Marker | Query | Duration |
---|---|---|---|
1 | ridgestar\csa->GetGeolite #4348 | select *,inet_aton('18.219.209.144') as IPTranslated from GL2Blocks left join GL2Locations on dgbGeoname=dglKey where dgbIPStart<=inet_aton('18.219.209.144') and dgbIPEnd>=inet_aton('18.219.209.144') limit 1 | 0.074095 |
2 | ridgestar\csa->Refresh_PageText #8185 | select distinct dtpTag from Topics where dtpTag like 'Text %' | 0.000065 |
3 | ridgestar\csa->DB_Definition #1981 | select * from information_schema.COLUMNS where TABLE_NAME='Options' and TABLE_SCHEMA='rsr' | 0.000248 |
4 | ridgestar\csa->Refresh_Settings #8218 | select dopRule, dopRuleData, dopSort, dopArray, dopProperties from Options where dopSetting='1' and dopRule not like 'SQL_%' | 0.000085 |
5 | ridgestar\csa->Refresh_Shortcuts #8268 | select dshShortcut,dshTitle,dshURL,dshAdministrator,dshUser,dshVisitor from Shortcuts where (dshStartDate<=now() or isnull(dshStartDate)) and (dshEndDate>=now() or isnull(dshEndDate)) order by dshSequence | 0.000073 |