About resource hierarchy in web.config files

Author: Sergey Sorokin

Published: 2010-11-12 19:55:00

Last update: 2013-08-31 11:13:16

Tags: security
hmi
scada
web
csworks
web.config
historical data
data point
MaxWebConfigFileSizeInKB

Slug: About-resource-hierarchy-in-webconfig-files

CSWorks stores resource hierarchy in web.config files, so:

• LiveData Web Service can find LiveData Service instance that collects data from some specific data source;
• Alarm Web Service can find Alarm Service that handles some specific alarm group;
• History Reader Web Service can find database that holds historical data for a specific data point.

Let’s take History Reader Web Service for example. The following piece of web.config tells web service that data history for data point “7cc32718-0da0-42b3-ae55-0acbb3593671" (also known as "Tank1") is stored in the database “partition1”:

<historyTopology>
  <historyPartitions>
    <historyPartition name="partition1" primaryDbTarget="…" secondaryDbTarget="…">
      <areas>
        <area id="…" name="By Equipment/Location">
          <areas>
            <area id="…" name="Tanks">
              <areas>
                <area id="…" name="West Side">
                  <dataPoints>
                    <dataPoint id="{7cc32718-0da0-42b3-ae55-0acbb3593671}" description="Tank1"/>

One potential problem is that some solutions can record thousands of historical data points, and all of them must be referenced in a single web.config file, and by default, ASP.NET limits the size of web.config file by 256kb. Consider the following setup.

Run a script that generates 10,000 historical datapoint references (you can download it here) and insert them into <historyPartition name="partition1"…> node of the web.config of History Reader Web Service. Web.config now has size around 1mb (see screenshot below). Run any client application that uses this web service (CSWorks TrendDemo for example) and get a web service error that doesn’t leave any trace: no exceptions in ASP.Net worker process, no error in the Event Log.

Now tell ASP.NET that it should accept bigger web.config files. Create DWORD registry value HKLM\Software\Microsoft\InetStp\Configuration\MaxWebConfigFileSizeInKB and set its value to, say 1024kb (see screenshot below).


Now restart the client application and start accessing those 10,000 historical data points. The screenshot below shows:

• registry editor with MaxWebConfigFileSizeInKB value;
• web.config file size;
• a fragment of web.config that references historical data points that belong to area “#0199”;
• a fragment of CSWorks Trend Control that allows to choose any historical data point from area “#0199” and add it to the chart.

There are few other potential problems with large amount of data in web.config files. First, Silverlight Tree Control has problems with displaying more than a few thousand nodes simultaneously. Second, CSWorks History Reader Web Service handles data point hierarchy more efficiently if every area doesn’t contain more than a few hundred data points.

The recommendation is obvious: when planning historical data point areas hierarchy, do not put more than a few hundred data points in a single area, avoid “plain” hierarchies with thousands of data points in the same area. The script used in this demo (you can download it here) generates 200 areas each containing 50 historical data points.

This discussion also applies to LiveData and Alarm web services, although the problem of large web.config files is not that relevant for live data and alarming: only extremely large CSWorks solutions use more than thousand data sources and more than thousand alarm groups.