Buffering ASP.NET Health Monitoring Events
You can configure the SQL and mail health monitoring event providers (, , and ) to use event buffering. This helps reduce the impact on application performance of sending frequent e-mail messages or performing frequent SQL server insertions. Buffering health monitoring events also protects the SMTP server and SQL Server from heavy loads due to high event volume.
SQL Event Provider Buffering
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.
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.
<healthMonitoring> <providers> <clear/> <add ConnectionStringName="LocalSqlServer" maxEventDetailsLength="1073741823" buffer="true" bufferMode="Analysis" name="SqlWebEventProvider" type="System.Web.Management.SqlWebEventProvider,System.Web, Version=188.8.131.52,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>
Email Event Provider Buffering
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
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.
<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.
<system.net> <mailSettings> <smtp deliveryMethod="Network"> <network defaultCredentials="true" host="127.0.0.1" port="25" username="username" password="password" /> </smtp> </mailSettings> </system.net>
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 .
Buffer Mode Settings
You can set the following attributes of theelement in the 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.