You are currently reviewing an older revision of this page.
Most of these settings are used to fine-tune the performance of the GeoWebPublisher server. They are not available through the administration interface nor through the webservice administration interface.
It is recommended to use performance monitoring tools to assess the current usage of computer resources by GeoWebPublisher and to identify bottlenecks before changing these settings.
When making modifications to these settings, please keep a copy of your original configuration file (pubconfig.xml) so you can revert in case of problems. Using the wrong values for some options could negatively affect performance.
Note that each of the "Thread" settings control the number of threads the server allocates for that type of job. The simple fact of allocating a thread uses up some RAM and system resources.
Every time you change one of these settings, you will have to restart the services so they take effect.
Description
maxNumberofEngines
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 big amount of simultaneous connections but 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.
This section controls the WMS server configuration.
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 that threads has not served requests for < maxIdleTime > minutes.
Make this number higher if your server receives a high number of concurrent WMS requests and you want to augment the responsiveness. Make sure you have enough RAM in your machine.
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.
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.
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.
This section contains settings specific to the serving of map requests
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.
numberOfOracleSpatialConnectionThreads
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".
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.
This section contains settings for the Data preparation service.
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.
This section, which resides in the WFSConfig.xml file, contains settings that control the WFS server.
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.