SCANTIME parameter - Revision history

DCameron: /* Description */

2017-05-24T10:44:13Z

Description

← Older revision		Revision as of 10:44, 24 May 2017
Line 80:		Line 80:
	''SirScan''.		''SirScan''.
	Since the heartbeat messages are regular RK type messages, they can be		Since the heartbeat messages are regular RK type messages, they can be
	viewed with AUDIT204 as well as ''SirScan''.		viewed with <var>[[AUDIT204#AUDIT204_utility\|AUDIT204]]</var> as well as ''SirScan''.

	This means that if one is using AUDIT204 for a previous run's journal,		This means that if one is using AUDIT204 for a previous run's journal,

DCameron: /* Description */

2017-05-24T10:31:48Z

Description

← Older revision		Revision as of 10:31, 24 May 2017
Line 18:		Line 18:
	These heartbeat messages are RK type audit messages, and they contain identifying		These heartbeat messages are RK type audit messages, and they contain identifying
	information about the thread such as userid, terminal ID, and IP address and		information about the thread such as userid, terminal ID, and IP address and
	port number for Janus server threads.		port number for <var>[[Janus_Web_Server\|Janus server]]</var> threads.

	SCANTIME indicates the maximum number of seconds between journal		SCANTIME indicates the maximum number of seconds between journal

DmeWiccan: Automatically generated page update

2013-08-27T16:43:42Z

Automatically generated page update

← Older revision		Revision as of 16:43, 27 August 2013
Line 1:		Line 1:
			{{Template:SCANTIME parameter subtitle}}
	==Summary==		==Summary==
	<dl>		<dl>

DmeWiccan: 1 revision

2012-06-22T19:25:03Z

1 revision

New page

==Summary==
<dl>
<dt>Default value
<dd>0
<dt>Parameter type
<dd>System
<dt>Where set
<dd>User 0 CCAIN parameters
<dt>Related products
<dd>[[SirScan]]
<dt>Introduced
<dd>Before <var class="product">Sirius Mods</var> 6.7
</dl>
==Description==
This parameter indicates the maximum amount of time between ''SirScan'' “heartbeat”
messages, and it must have a value between 0 and 3600, inclusive.
These heartbeat messages are RK type audit messages, and they contain identifying
information about the thread such as userid, terminal ID, and IP address and
port number for Janus server threads.

SCANTIME indicates the maximum number of seconds between journal
messages for a thread before a heartbeat message is issued.
If a message is about to be sent to the journal for a thread, and it has
been more than SCANTIME seconds since the last heartbeat message, then
the heartbeat message is first sent to the journal.
This means that if a journal message is found for a thread, the userid
and other identifying information can '''always''' be found by
looking backwards in the journal no more than SCANTIME seconds.

The default value for SCANTIME of 0 means that heartbeat messages
are not logged.
If SCANTIME is set to a positive value up to its maximum value of 3600,
the ''SirScan'' heartbeat messages will be logged to the journal.

If SCANTIME is set to a non-zero value, the SIRSCAN subsystem
detects this and, on the scan specification screen, gives users the
option of reading an extra SCANTIME seconds on every interval collected
from the journal.
The extra SCANTIME seconds read are before the start of the requested
interval.
While the data from the extra SCANTIME seconds worth of journal entries
is not formatted, it is scanned for the heartbeat messages, and any
information in those messages is saved for each thread.
In this way, all messages for all threads after the start of the requested
interval can be deterministically associated with a userid, terminal ID,
and IP address and Janus port for Janus server requests.

The cost of getting this deterministic behavior is the overhead of
scanning an extra SCANTIME seconds worth of journal.
If scanning is being done in auto-refresh mode, each refresh (attempt to
move past the current bottom) will cause an extra SCANTIME seconds to
be scanned.
This means that the setting of SCANTIME involves a trade-off between
the number of heartbeat messages logged to the journal and the overhead
of scanning an extra SCANTIME seconds of journal on every ''SirScan''
browse request.
The bigger the value of SCANTIME, the fewer heartbeat messages will
be logged, but the more journal records would need to be scanned on each
''SirScan'' browse request.
A small value of SCANTIME will, of course, have the opposite effect.

Since journal messages tend to be bunched (when a thread gets
one audit message logged it is likely to get several around the same
time), there is probably not a significantly higher cost to a relatively
small SCANTIME, like 10 or even 5, than to a much larger one, like 60.
On the other hand, the amount of extra work performed by ''SirScan'' associated
with the extra SCANTIME second scan for each browse request will be roughly
proportional to the size of SCANTIME.
All this would suggest using a fairly small SCANTIME: a value of 10 might
be a good starting point.

If you are setting SCANTIME for the first time in an Online, it is prudent
to anticipate a 3% increase in journal usage, though the actual increase
will almost undoubtedly be much less than that (probably less than
even 1%).

'''Note:'''
The heartbeat message can even be useful outside of
''SirScan''.
Since the heartbeat messages are regular RK type messages, they can be
viewed with AUDIT204 as well as ''SirScan''.

This means that if one is using AUDIT204 for a previous run's journal,
and you want to find entries for a particular userid in a particular
time interval, you can simply request from AUDIT204 all records for all
users in the desired interval plus SCANTIME seconds before.
By doing so, you can be certain that any messages formatted by AUDIT204
will be preceded by a message identifying the user associated with that
message.

If a site is not authorized for ''SirScan'', this parameter will have no effect.
[[Category:System parameters]]
[[Category:Parameters]]

JAL at 00:12, 1 October 2010

2010-10-01T00:12:17Z

New page

<dl>
<dt>Default value
<dd>0
<dt>Parameter type
<dd>System
<dt>Where set
<dd>User 0 CCAIN parameters
<dt>Related products
<dd>[[SirScan]]
<dt>Introduced
<dd>Before [[Sirius Mods]] 6.7
</dl>
This parameter indicates the maximum amount of time between ''SirScan'' “heartbeat”
messages, and it must have a value between 0 and 3600, inclusive.
These heartbeat messages are RK type audit messages, and they contain identifying
information about the thread such as userid, terminal ID, and IP address and
port number for Janus server threads.

SCANTIME indicates the maximum number of seconds between journal
messages for a thread before a heartbeat message is issued.
If a message is about to be sent to the journal for a thread, and it has
been more than SCANTIME seconds since the last heartbeat message, then
the heartbeat message is first sent to the journal.
This means that if a journal message is found for a thread, the userid
and other identifying information can '''always''' be found by
looking backwards in the journal no more than SCANTIME seconds.

The default value for SCANTIME of 0 means that heartbeat messages
are not logged.
If SCANTIME is set to a positive value up to its maximum value of 3600,
the ''SirScan'' heartbeat messages will be logged to the journal.

If SCANTIME is set to a non-zero value, the SIRSCAN subsystem
detects this and, on the scan specification screen, gives users the
option of reading an extra SCANTIME seconds on every interval collected
from the journal.
The extra SCANTIME seconds read are before the start of the requested
interval.
While the data from the extra SCANTIME seconds worth of journal entries
is not formatted, it is scanned for the heartbeat messages, and any
information in those messages is saved for each thread.
In this way, all messages for all threads after the start of the requested
interval can be deterministically associated with a userid, terminal ID,
and IP address and Janus port for Janus server requests.

The cost of getting this deterministic behavior is the overhead of
scanning an extra SCANTIME seconds worth of journal.
If scanning is being done in auto-refresh mode, each refresh (attempt to
move past the current bottom) will cause an extra SCANTIME seconds to
be scanned.
This means that the setting of SCANTIME involves a trade-off between
the number of heartbeat messages logged to the journal and the overhead
of scanning an extra SCANTIME seconds of journal on every ''SirScan''
browse request.
The bigger the value of SCANTIME, the fewer heartbeat messages will
be logged, but the more journal records would need to be scanned on each
''SirScan'' browse request.
A small value of SCANTIME will, of course, have the opposite effect.

Since journal messages tend to be bunched (when a thread gets
one audit message logged it is likely to get several around the same
time), there is probably not a significantly higher cost to a relatively
small SCANTIME, like 10 or even 5, than to a much larger one, like 60.
On the other hand, the amount of extra work performed by ''SirScan'' associated
with the extra SCANTIME second scan for each browse request will be roughly
proportional to the size of SCANTIME.
All this would suggest using a fairly small SCANTIME: a value of 10 might
be a good starting point.

If you are setting SCANTIME for the first time in an Online, it is prudent
to anticipate a 3% increase in journal usage, though the actual increase
will almost undoubtedly be much less than that (probably less than
even 1%).

'''Note:'''
The heartbeat message can even be useful outside of
''SirScan''.
Since the heartbeat messages are regular RK type messages, they can be
viewed with AUDIT204 as well as ''SirScan''.

This means that if one is using AUDIT204 for a previous run's journal,
and you want to find entries for a particular userid in a particular
time interval, you can simply request from AUDIT204 all records for all
users in the desired interval plus SCANTIME seconds before.
By doing so, you can be certain that any messages formatted by AUDIT204
will be preceded by a message identifying the user associated with that
message.

If a site is not authorized for ''SirScan'', this parameter will have no effect.
[[Category:System Parameters]]
[[Category:Parameters]]