Description

Sets the maximum number of Microstation/Bentley Map engines that can run simultaneously. These are separate ustation.exe processes that are started by the GWP services.

These are used for the publication of basic dgn files, but also (and most importantly) for the generation of borders in the advanced print mode.

Unless you have a site that does a lot of dgn publishing, you should not change this setting.

Number of threads that parse incoming requests. These are responsible for reading the request, parsing it, doing basic logging and licensing, checking the response cache and dispatching to the right processing queue.

You can try setting this higher if your server receives a large number of simultaneous connections while cpu/disk usage and throughput stay low.

Number of threads affected to sending the response data back to clients. Each thread sends data to a client until the connection blocks, at which point it starts processing another response. Therefore, the same thread can answer multiple clients. Multiple threads means the server can make multiple simultaneous writes on tcp sockets.

You can set this higher if you are serving a higher number of concurrent users and your network connection has a high bandwidth.

Number of threads that redirect requests to the imaging server. This affects the maximum number of concurrent raster requests that the server can process.

We do not recommend changing this value.

Number of threads that receive data from HTTP POST requests, before the requests can be sent for further processing. Many operations use POST requests, including but not restricted to: RenditionID to/from Feature keys mappings, Locate operations, thematic resymbolization, redline posting.

 

You can set this higher if your server receives many such requests and throughput seems low / server does not seem busy.

Number of threads / engines serving requests in the WMS format. GWP starts a PubLiteEngineServer.exe process for each thread when necessary. Each of these can potentially use a fair amount of memory and cpu resources.

PubLiteEngineServer.exe processes are stopped when a thread has not served requests for < maxIdleTime > minutes.

Increase this value if your server receives a high number of concurrent WMS requests and you wish to augment responsiveness. Ensure that the amount of RAM available to the machine is appropriate for the increased load. 

Number of minutes of inactivity before we terminate the PubLiteEngineServer.exe process. This regains memory but loses all the cached data that otherwise speeds up the next requests for the same map.

Used to enable or disable the mechanism that limits the amount of RAM used by each PubLiteEngine (or WMS engine if you prefer). See maxMemoryCacheSize below.

Maximum number of Megabytes of memory allocated to cache map data in each PubLiteEngineServer.exe process. The more memory is allocated, the more chances that the next request can be served without loading any data.

 

The effect of this change is multiplied by the number of MapLiteThreads that you run. Make sure you have enough available memory.

Number of seconds that the WMS request is allowed to run. Past that time we return an error to the client, assuming that the PubLiteEngineServer.exe process has encountered an error.

Make this setting higher if you are publishing very complex maps as WMS and are encountering false errors.

Number of requests that a thread will serve before recycling its PubLiteEngineServer.exe process.

We do not recommend changing this value.

Maximum dimensions for WMS GetMap requests. Requests for bigger sizes will get an error. This is to stop badly formed requests from crashing the server by using too much memory.

Number of threads that serve IDPR data requests. These requests are for IDPR layer opening, IDPR tile download and also for thematic resymbolization of IDPR layers.

These typically don’t use much CPU resources, they are more disk-intensive. However, thematic resymbolization of IDPR layers is more CPU-intensive.

Make this setting higher if you serve a high number of IDPR layers to a high number of clients simultaneously and your server has available I/O bandwidth.

Number of threads that serve base map requests. Almost every map-related request goes through these threads before being redirected to the correct engine depending on the requested layer.

The default setting is normally enough as these requests don’t require much cpu resources.

Number of threads that serve requests for Oracle Spatial graphical sources. They are responsible for connecting to the database, fetching the required data and generating the response data. Each thread will use a separate connection to the database server.

Set this higher if you are serving mainly Oracle Spatial layers and have many concurrent requests. Make sure you are not using too many connections to your database servers.

 

NOTE: Because of a problem in the initial V8i release (8.11.5.17), this value must stay at 1 in that version.

 

NOTE: This setting is being deprecated in GeoWebPublisher SelectSeries 3 in favor of "numberOfSpatialConnectionThreads".

Number of threads that serve requests for Oracle Spatial and SQLServer Spatial graphical sources. They are responsible for connecting to the database, fetching the required data and generating the response data. Each thread will use a separate connection to the database server.

Set this higher if you are serving mainly Oracle Spatial / SQLServer spatial layers and have many concurrent requests. Make sure you are not using too many connections to your database servers.

 

NOTE: This setting is new in GeoWebPublisher V8i SelectSeries 3.

Number of threads that serve requests for ODBC Spatial graphical sources. Each thread will use a separate connection to the database.

Set this higher if you are serving a lot of ODBC/Spatial layers. Make sure you don’t use too many simultaneous database connections.

TCP port that is used to communicate with the Data Preparation service. Only local connections will be made to this port, it does not need to be accessible from outside the server itself.

Number of milliseconds that the Data preparation service will wait before starting to process jobs. This is mainly used to let the machine finish its boot sequence when the service is configured to start automatically.

Number of milliseconds that the Data preparation service will wait before starting an IDPR conversion once one of the source files changes. This is so we don’t start processing while other source files for the same IDPR job are also being changed.

Number of milliseconds that the Data preparation service will wait before connecting to a ProjectWise datasource and update the local files.

Setting this lower will update local files quicker when they are updated in the datasource but at the expense of more network traffic.

Sets the maximum number of Microstation/Bentley Map engines that can run simultaneously. These are used to serve schema and feature requests for XFM graphical sources. Each engine corresponds to one ustation.exe process. Depending on the number and complexity of the xfm files, these can take a significant amount of memory.

Number of threads that can simultaneously serve client requests.

Set this higher if you serve a high number of concurrent requests but remember that each of these consumes resources. Also note that if all your requests are for XFM features, you should also see the maxNumberOfEngines setting.

Number of requests that will be served by a Microstation/Map engine before we recycle the engine.

Maximum number of reference files that will be attached simultaneously in the Microstation/Map engine. For XFM sources that have more sources the GetFeature request will be processed in multiple “passes”. This is used to limit the amount of memory that will be used.

Number of milliseconds that a Microstation/Map engine is allowed to wait in idle state before it is stopped.

Maximum time (in milliseconds) that an XFM request is allowed to run inside a Microstation/Map engine before we stop it. This is used to detect limit conditions.

Raise this value if you have a dataset that is too complex to be processed inside the current limit.