If you enable buffering for the SQL event provider, the provider buffers event information according to the specified buffer mode before inserting the event information into the database in a batch.

By default, the SqlWebEventProvider provider is not configured to use buffering, and each time an event is raised, its information is immediately inserted into the database. You can override this default setting by enabling buffering in the providers element of the Web.config file where the SQL provider is specified; you do so by setting the buffer attribute of the add element to true. If you configure your own SQL provider (that is, you do not use SqlWebEventProvider), and if you do not specify a value for the buffer attribute, then the default is true.

You can customize buffering behavior by selecting a predefined buffering mode. Alternatively, you can add custom elements to the bufferModes collection. Each element defines properties such as the size of the buffer and the frequency for flushing the buffer. You can then configure the provider to use one of the buffer modes you have defined.

The example that follows shows the configuration settings for the SQL event provider with buffering enabled.

Note

The Analysis bufferModes element is already configured in the root Web.config file and does not need to be declared again in an application-level Web.config file. The SqlWebEventProvider providers element is also configured in the root Web.config file, but the buffer attribute is set to false and the bufferMode attribute is set to Notification. Therefore the providers element shown in the example needs to be declared in an application-level Web.config file, and you must use a clear or remove element to remove the higher-level configuration for the SqlWebEventProvider provider.

In the example, the SQL event provider is configured to use the Analysis buffer mode when buffering is enabled, which is defined in the bufferModes element. In this mode, the provider flushes the event information every 5 minutes. It flushes up to 100 events per notification, and buffers up to 1000 events in case of a sudden rise in the frequency of events. The provider guarantees not to send events more often then once every minute.

В

Copy Code

<healthMonitoring> <providers> <clear/> <add ConnectionStringName="LocalSqlServer" maxEventDetailsLength="1073741823" buffer="true" bufferMode="Analysis" name="SqlWebEventProvider" type="System.Web.Management.SqlWebEventProvider,System.Web, Version=2.0.0.0,Culture=neutral,PublicKeyToken=b03f5f7f11d50a3a" /> </providers> <bufferModes> <add name="Analysis" maxBufferSize="1000" maxFlushSize="100" urgentFlushThreshold="100" regularFlushInterval="00:05:00" urgentFlushInterval="00:01:00" maxBufferThreads="1" /> </bufferModes> </healthMonitoring>

If you enable buffering for the mail event providers, the providers buffer events before sending e-mail messages as event notifications. If you configure an email event provider and do not specify a value for the buffer attribute of the add element for the mail event provider, the default is true. You can disable buffering by setting the buffer attribute to false.

You can customize buffering behavior by selecting a predefined buffering mode. Alternatively, you can add custom elements to the bufferModes collection. Each element defines properties such as the size of the buffer and the frequency for flushing the buffer. You can then configure the provider to use one of the buffer modes you have defined. It is recommended that you use the CriticalNotification mode.

The following example shows the configuration settings for the email event providers with buffering disabled for the SimpleMailWebEventProvider and enabled for the TemplatedMailWebEventProvider. The TemplatedMailWebEventProvider provider is configured to use the CriticalNotification buffer mode, which is already configured in the root Web.config file. In CriticalNotification mode, the provider attempts to flush all event information as soon as events are received, but the flush attempt will not succeed more frequently than every minute to avoid putting an undue load on the e-mail server. The messages are of manageable size (at most the information for 20 events).

If the health monitoring system receives more event information than the maximum allowed, the oldest events will start being dropped when new events are generated. The health monitoring system tries to avoid dropping events by flushing more frequently when the buffer is getting full, but it will not attempt to send out any information for events if they have been dropped (other than a notification in the next flush that events were dropped). Newer events will be delayed at most five minutes if the provider is under heavy load, assuming they are not dropped because of a full buffer.

В

Copy Code

<healthMonitoring> <providers> <!-- mail provider with attributes that are always relevant --> <add name="SimpleMailWebEventProvider" type="System.Web.Management.SimpleMailWebEventProvider" to="SystemAdministrator@contoso.com" from="HealthMonitoring@contoso.com" buffer="false" /> <!-- mail provider with attributes that are relevant only when buffering is enabled --> <add name="SampleTemplatedMailWebEventProvider" type="System.Web.Management.TemplatedMailWebEventProvider" to="SystemAdministrator@contoso.com" from="HealthMonitoring@contoso.com" buffer="true" bufferMode="Critical Notification" template="Template.aspx" /> </providers> <bufferModes> <add name="Critical Notification" maxBufferSize="100" maxFlushSize="20" urgentFlushThreshold="1" regularFlushInterval="Infinite" urgentFlushInterval="00:01:00" maxBufferThreads="1" /> </bufferModes> </healthMonitoring>

For the example to work, you must configure an SMTP server in the configuration file using an element such as the following. For more information, see mailSettings Element (Network Settings).

В	Copy Code
<system.net> <mailSettings> <smtp deliveryMethod="Network"> <network defaultCredentials="true" host="127.0.0.1" port="25" username="username" password="password" /> </smtp> </mailSettings> </system.net>

Note
There are security risks associated with storing clear-text passwords in a configuration file. If you keep credentials in the configuration file, you should encrypt the contents of the <mailSettings> configuration element using protected configuration. For more information, see Encrypting Configuration Information Using Protected Configuration.

You can set the following attributes of the add Element for bufferMode for healthMonitoring (ASP.NET Settings Schema) element in the bufferModes element to specify buffer behavior:

• regularFlushIntervalВ В В The regular event information flush interval.

• urgentFlushThresholdВ В В A value specifying the number of events whose information should be buffered before the buffer is flushed.

The following settings specify the guarantees made by the provider to the event receiver.

• maxBufferSizeВ В В A number specifying the maximum number of events whose information the buffer will hold. If the number of events in the buffer would exceed this value, older events are dropped.

• maxFlushSizeВ В В The maximum number of events whose information the provider will flush at a time.

• urgentFlushIntervalВ В В The minimum time that the provider will wait before performing another urgent flush. If the time represented by the urgentFlushInterval property has not passed since the last flush but the buffer is full, information from older events will be discarded from the buffer by the newer information. The provider keeps track of how many events were discarded, and includes a warning in the next event information that is sent.

Reference

Concepts