Bentley Communities
Bentley Communities
  • Site
  • User
  • Site
  • Search
  • User
Geospatial Services
  • Product Communities
  • Geospatial
  • Geospatial Services
  • Cancel
Geospatial Services
Geospatial Services - Wiki GWP1005 Bentley Geo Web Publisher Advanced Configuration Settings
    • Sign In
    • Geospatial Services - Wiki
    • +ProjectWise Geospatial Management
    • +ProjectWise Spatial

     
     Questions about this article, topic, or product? Click here. 

    GWP1005 Bentley Geo Web Publisher Advanced Configuration Settings

    PubConfig.xml settings not exposed in the Administration application

    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.

    General section

    Setting
    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.
    numberofParsers
    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.
    NumberOfResponseSenders
    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.
    NumberOfImagingThreads
    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.
    NumberOfPOSTThreads
    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.
      

    mapLiteEngineSetting section

    This section controls the WMS server configuration.
    numberOfMapLiteThreads
    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. 
    maxIdleTime
    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.
    enableMaxMemory
    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.
    maxMemoryCacheSize
    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.
    timeout
    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.
    maxRequestsBeforeReset
    Number of requests that a thread will serve before recycling its PubLiteEngineServer.exe process.
     
    We do not recommend changing this value.
    maxWidth and maxHeight
    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.

    mapEngineSetting section

    This section contains settings specific to the serving of map requests
    numberOfiDprThreads
    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.
    numberOfMapInterpretationThreads
    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.
    numberOfODBCSpatialConnectionThreads
    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.
      

    mapLiveEngineSetting section

    This section contains settings for the Data preparation service.
    remotePort
    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.
    bootWaitTime
    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.
    waitTimeBeforeProcessChange
    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.
    waitTimeBeforeUpdatePwSource
    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.
      

    WFSSettings section

    This section, which resides in the WFSConfig.xml file, contains settings that control the WFS server.
    maxNumberOfEngines
    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.
    maxNumberOfWorkerThreads
    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.
    maxNumberOfEngineRequests
    Number of requests that will be served by a Microstation/Map engine before we recycle the engine.
    maxNumberOfDgnReferences
    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.
    engineTimeout
    Number of milliseconds that a Microstation/Map engine is allowed to wait in idle state before it is stopped.
    engineRequestTimeout
    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.
    • pubconfig.xml
    • Configuration
    • Share
    • History
    • More
    • Cancel
    • Martin Roy Created by Bentley Colleague Martin Roy
    • When: Fri, Jan 16 2009 9:17 AM
    • Nelson Hobdell Last revision by Bentley Colleague Nelson Hobdell
    • When: Thu, Feb 9 2017 8:31 AM
    • Revisions: 16
    • Comments: 0
    Recommended
    Related
    Communities
    • Home
    • Getting Started
    • Community Central
    • Products
    • Support
    • Secure File Upload
    • Feedback
    Support and Services
    • Home
    • Product Support
    • Downloads
    • Subscription Services Portal
    Training and Learning
    • Home
    • About Bentley Institute
    • My Learning History
    • Reference Books
    Social Media
    •    LinkedIn
    •    Facebook
    •    Twitter
    •    YouTube
    •    RSS Feed
    •    Email

    © 2023 Bentley Systems, Incorporated  |  Contact Us  |  Privacy |  Terms of Use  |  Cookies