The need.
Declarative nature of Lablz Web Apps requires better debugging tool. We currently trace into error.log and this file gets huge and hard to read. In the past we added indispensable Dev zone menu to see only the log for the last HTTP request, sql log for the last HTTP request and stats for queries that hit or missed the cache. But we need better a much way to assess the performance, discover slow and inefficient queries, analyze cache effectiveness, discover exceptions and debug the DAV to SQL mapping.
performance as a standard data source
We have recently cleaned up the Profiling tool which shows WebDAV queries grouped by class. We redesigned Profiling tool from being a custom made HTML generator to producing normal DavResources and utilize the standard resource list painter. This cleaned up the presentation and the code so much that it gave us the idea of fully transforming the unstructured source of data (error.log) into a structured data source using Lablz core DavServlet plugin architecture. Thus MonitorDavServlet was born. New monitoring tool will add the ability to analyze XHR (Ajax) requests, ability to see previous N
HTTP requests, drill down to an individual WebDAV query level and even the ability to re-execute the last WebDAV query collecting the resulting SQL log.
QA, support and other uses
What is amazing is that as performance data becomes structured data the other possibilities instantly open up. These are a couple we thought up:
testing framework can use monitoring stats to discover bugs automatically. Initial ideas: execute all bookmarks on every host and compare the number of SQL queries, number of cache hist and misses with the baseline. Also compare the execution time to timely discover performance regression.
instant problem indicators. We will place a couple of icons in a visible place (near Home menu or as a badge icon on top of it) to indicate an error which might otherwise be invisible, a presence of a slow query and other exceptions.
automatically collect current state of the system at the bug submission time. This can be done by producing .csv backup of monitoring resources and attached to the Bug resource in Lablz CRM. This can be further automated much like Ubuntu bug submission tool which collects system info on behalf of the user. The developer can then load these .csv files into his system for analysis.
Most of the initial development has been done and Dev Zone menu already contains a link to Monitoring. Please review and submit your comments and ideas.
Implementation notes:
we begin collecting monitoring info on the first request to /monitor location. That means the stats will start accumulating only after your first click on Monitoring link in the Dev zone.
we collect info on an HTTP session. This means you will see only your own requests.
data on the last 10 requests are kept in memory, no extra disk operations are performed
It's great to see the stats this way now; so much>>
It's great to see the stats this way now; so much easier see if and what's slow.
Is it possible to store errors that hit the log as well? Having them classified and logged would allow a daily digest of errors to be reported.
Is it possible to see other session collections? >>
Is it possible to see other session collections? You could use this to improve performance and more easily trace a users steps without needing the user to show the monitor.