Limiting query results and output


Summary The server application programming interface (API) includes a large number of ArcObjects components that developers can use to provide functionality in their applications. This puts responsibility on the developer to build applications that do not allow the user of that application to put either the Web server (in the case of a Web application or Web service) or the database server in a state that results in a denial of service to other users.

The two areas discussed in this topic are limiting the size of query results and limiting the size of output.

In this topic


Limiting the size of query results

The Geodatabase library includes objects that allow you to query data in a database using spatial filters, attribute filters, or a combination of both. At this level of the ArcObjects API, no limits or constraints are put on the nature of the query or the number of records that can be returned by the cursor resulting from executing the query. If, for example, a Web application executes a query that returns 1,000,000 rows and iterates through each row, this can (depending on the nature of the query) tie up the database server while the query is evaluated, then tie up the Web server as the application iterates through the 1,000,000 rows.
These types of queries should be avoided by not allowing users to perform ad hoc queries against the database. Design your application to control the types of queries that users can execute (or that are executed as a result of their interaction with the application). Also, set limits on the number of query results that the application will process for those cases where a large number of query results are returned from the database. You can do this by evaluating a fixed number of maximum rows from result cursors.

MapServer

There are some cases when using the coarse-grained methods on MapServer where queries can be executed, but the execution and evaluation of that query takes place in MapServer. For example, the QueryFeatureData method on IMapServer returns a fully populated record set containing the results of the query. To ensure that these record sets do not contain a number of rows too large for the system to handle, MapServer has built-in limits to evaluate the results of a query to a maximum record count.
This maximum is set as a property of the MapServer object called MaxRecordCount. By default, the MaxRecordCount is 500; however, this property can be modified by the administrator of the geographic information system (GIS) server by modifying the value of the MaxRecordCount XML tag in the MapServer configuration file.
This maximum record count will be applied to the results of the following methods on IMapServer:
  • QueryFeatureData
  • Find
  • Identify
MapServer also allows you to dynamically draw buffers around features by specifying SelectionBufferDistanceProperty on ILayerDescription that is greater than zero. If the selection is large, this can increase the resources required to draw a map. MapServer also has built-in limits to limit the number of features that can be buffered per layer. This maximum is set as a property of the MapServer object called MaxBufferCount. By default, the MaxBufferCount is 100; however, this property can be modified by the administrator of the GIS server by modifying the value of the MaxBufferCount XML tag in the MapServer configuration file.

GeocodeServer

GeocodeServer also has built-in limits that prevent requests from returning results that are too large. Specifically, the number of records returned by the FindAddressCandidates method is limited by the GeocodeServer MaxResultSize property. The default for this is 500; however, this property can be modified by the administrator of the GIS server by modifying the value of the MaxResultSize XML tag in the GeocodeServer configuration file.
GeocodeServer also has a built-in limit for the number of input records that can be passed into the GeocodeAddresses method. This maximum is set as a property of GeocodeServer called MaxBatchSize and can be modified by the administrator of the GIS server by modifying the value of the MaxBatchSize XML tag in the GeocodeServer configuration file.

Limiting the size of output

Another area where application developers need to be careful is when their applications write output to a server directory. Large files can take a large amount of disk space and a large amount of resources to produce. Developers have to limit the size of files they write with these considerations in mind.
The MapServer ExportMapImage method takes an ImageDescription object that includes the size of the image requested. To limit the size of images produced by ExportMapImage, MapServer has built-in limits for the size of images that ExportMapImage can produce.
This maximum is set as two properties of the MapServer object called MaxImageWidth and MaxImageHeight, specified in pixels. By default, these are set to 2048; however, these properties can be modified by the administrator of the GIS server by modifying the values of the MaxImageWidth and MaxImageHeight XML tags in the MapServer configuration file.


See Also:

ArcGIS Server application performance tuning
Pooling objects with server objects
Monitoring performance