[CalendarServer-changes] [9975] CalendarServer/trunk/doc/Admin/ExtendedLogItems.rst

source_changes at macosforge.org source_changes at macosforge.org
Tue Oct 23 14:00:23 PDT 2012


Revision: 9975
          http://trac.calendarserver.org//changeset/9975
Author:   dre at apple.com
Date:     2012-10-23 14:00:23 -0700 (Tue, 23 Oct 2012)
Log Message:
-----------
Updated for with new items, changed meaning of 'i'

Modified Paths:
--------------
    CalendarServer/trunk/doc/Admin/ExtendedLogItems.rst

Modified: CalendarServer/trunk/doc/Admin/ExtendedLogItems.rst
===================================================================
--- CalendarServer/trunk/doc/Admin/ExtendedLogItems.rst	2012-10-23 20:20:36 UTC (rev 9974)
+++ CalendarServer/trunk/doc/Admin/ExtendedLogItems.rst	2012-10-23 21:00:23 UTC (rev 9975)
@@ -21,7 +21,7 @@
 
   ``i``
 
-    the port number of the server instance emitting the log
+    the index number of the server instance emitting the log; corresponds to the slave number shown in process title.
 
   ``t``
 
@@ -71,17 +71,27 @@
 
     the value of the X-Forwarded-For header, if present
 
-In the following example, we see a ``CalDAV:calendar-multiget``
-``REPORT`` for 32 resources in a user's calendar, which was handled by
-instance ``8459`` in 183.0ms, with one outstanding request (the one
-being logged):
+  ``fb-cached``
 
+    When doing free-busy queries, this is the number of calendars queried for which free-busy info was already cached
+
+  ``fb-uncached``
+
+    When doing free-busy queries, this is the number of calendars queried for which free-busy info was NOT already cached
+
+  ``cl``
+
+    Content length, in bytes
+
+In the following example, we see a free-busy ``POST``
+requesting availability for two users, which was handled by
+instance ``1`` in 782.6i ms. This instance was only processing one request at the time this was logged (or=1). Of the two calendars targeted by the free-busy query, one already had free-busy info cached, while the other was not cached. (fb-cached=1, fb-uncached=1)
+
 ::
 
-  17.108.160.37 - scastillo [15/Sep/2009:20:10:23 +0000] "REPORT(CalDAV:calendar-multiget) /calendars/__uids__/B8CE9430-965B-11DE-B626-EC2E9DB52B69/calendar/ HTTP/1.1" 207 149285 "-" "DAVKit/4.0 (729); CalendarStore/4.0 (965); iCal/4.0 (1362); Mac OS X/10.6.1 (10B504)" i=8459 t=183.0 or=1 rcount=32
+  10.1.5.43 - user5 [23/Oct/2012:13:42:56 -0700] "POST /calendars/__uids__/B2302CB9-D28F-4CB4-B3D9-0AF0FEDB8110/outbox/ HTTP/1.1" 200 1490 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50)" i=1 or=1 t=782.6 fb-uncached=1 fb-cached=1 recipients=2 cl=577
 
 
-
 **Fine-grained request time logging**
 
 If the configuration key EnableExtendedTimingAccessLog is set to true, additional key-value pairs will be logged with each request. The overall request time "t" is broken into four phases, and the elapsed time for each phase is logged. The new keys representing the four request phases are:
@@ -107,4 +117,4 @@
 
 ::
 
-  17.209.103.42 - wsanchez [24/Jul/2012:17:51:29 +0000] "REPORT(CalDAV:calendar-multiget) /calendars/__uids__/F114CA1D-295F-42A5-A5BD-D1A1B19FC049/60E68E32-4C87-4E63-9BF2-12A25E8F2623/ HTTP/1.1" 207 114349 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50d)" i=7 or=1 t=764.7 t-req-proc=4.8 t-resp-gen=754.5 t-resp-wr=5.1 t-log=0.2 rcount=2
\ No newline at end of file
+  17.209.103.42 - wsanchez [24/Jul/2012:17:51:29 +0000] "REPORT(CalDAV:calendar-multiget) /calendars/__uids__/F114CA1D-295F-42A5-A5BD-D1A1B19FC049/60E68E32-4C87-4E63-9BF2-12A25E8F2623/ HTTP/1.1" 207 114349 "-" "CalendarStore/5.0.2 (1166); iCal/5.0.2 (1571); Mac OS X/10.7.3 (11D50d)" i=7 or=1 t=764.7 t-req-proc=4.8 t-resp-gen=754.5 t-resp-wr=5.1 t-log=0.2 rcount=2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20121023/61342189/attachment-0001.html>


More information about the calendarserver-changes mailing list