Roxen.git
/
server
/
translations
/
eng
/
roxen_config.xml
version
»
Context lines:
10
20
40
80
file
none
3
Roxen.git/server/translations/eng/roxen_config.xml:246:
<tr><td>$utc-date</td> <td>UTC date formatted like '<code>2001-01-17</code>'.</td></tr> <tr><td>$utc-time</td> <td>UTC time formatted like '<code>13:00:00</code>'.</td></tr> <tr><td>$bin-date</td> <td>Unix time as a 32 bit integer in network byte order.</td></tr> <tr><td>$resource</td> <td>Resource identifier. For events, this is either a path to a file (if it begins with '<code>/</code>') or some other kind of
-
resource
indentifier
(otherwise).</td></tr>
+
resource
identifier
(otherwise).
It is '-' for events that doesn't
+
act on any specific resource.
</td></tr>
<tr><td>$server-uptime</td> <td>Server uptime in seconds.</td></tr> <tr><td>$server-cputime</td> <td>Server cpu (user+system) time in milliseconds.</td></tr> <tr><td>$server-usertime</td> <td>Server cpu user time in milliseconds.</td></tr> <tr><td>$server-systime</td> <td>Server cpu system time in milliseconds.</td></tr> </tbody></table>
Roxen.git/server/translations/eng/roxen_config.xml:393:
<tr><td>$protcache-cost</td> <td>The lookup depth in the HTTP protocol module low-level cache.</td></tr> </tbody></table> <h3>Event logging</h3> <p>The known event logging facilities and modules are described below.</p> <dl>
+
+
<dt>Facility: roxen</dt>
+
<dd><p>This is logging for systems in the Roxen WebServer core.
+
For logging that is not related to any specific configuration, the
+
configuration for the Administration Interface is used.</p>
+
+
<p>The known events are:</p>
+
+
<table><tbody valign='top'>
+
<tr><td>ram-cache-gc</td>
+
<td>Logged after the RAM cache GC has run. $handle-time and
+
$handle-cputime are set to the time the GC took (see
+
descriptions above for details).</td></tr>
+
<tr><td>ram-cache-rebase</td>
+
<td>Logged when the RAM cache has performed a rebias of the
+
priority queue values. Is a problem only if it starts to
+
happen too often.</td></tr>
+
</tbody></table></dd>
+
<dt>Facility: sbfs</dt> <dd><p>A SiteBuilder file system.</p> <p>The actions <code>commit</code>, <code>purge</code>, <code>mkdir</code>, <code>set-dir-md</code>, and <code>rmdir</code> are logged for file system changes except those in edit areas.</p> <p>The action <code>crawl-file</code> is logged for files that are crawled by the persistent cache crawler.</p>
Roxen.git/server/translations/eng/roxen_config.xml:3492:
<str id="1040"> <o>Note: This schedule is also used to schedule backups for Roxen's internal databases.</o> <t></t> </str> <str id="1041"> <o>Are you sure you want to restore the default value?</o> <t></t> </str>
+
+
<str id="1043">
+
<o>Cache: Memory cache size</o>
+
<t></t>
+
</str>
+
+
<str id="1044">
+
<o><p>Maximum size in MByte for all RAM caches taken together. This limit
+
covers the caches visible in the <a
+
href='/actions/?action=cachestatus.pike&class=status'>Cache status</a>
+
page.</p>
+
+
<p>Note that there are many more things in the Roxen WebServer that
+
take space, including some caches that are not handled by the common
+
RAM cache. Also, there is various indirect memory overhead that is not
+
directly accounted for by the size calculations. All these taken
+
together means that the figure configured here cannot be mapped
+
straightly to the size of the Roxen process as reported by the OS. The
+
optimal setting here is the one that in general keeps the Roxen
+
process at a size that avoids swapping and leaves enough memory for
+
buffers and other processes that need to run at the same time (e.g.
+
the Roxen instance of the MySQL server).</p></o>
+
<t></t>
+
</str>
+
+
<str id="1045">
+
<o>Cache: Memory cache GC interval</o>
+
<t></t>
+
</str>
+
+
<str id="1046">
+
<o><p>Interval in seconds between RAM cache garbage collector runs. This
+
GC removes entries from the RAM caches that have timed out or are
+
stale for other reasons, thereby making more room for new entries. The
+
configured cache size limits are enforced when entries are added, so
+
this GC is not required to keep the cache sizes down.</p>
+
+
<p>Running this GC too seldom causes some RAM caches to contain many
+
invalid cache entries, which could push out valid cache entries.
+
Running it too often causes unnecessary server load.</p></o>
+
<t></t>
+
</str>