BPC RiskManager - Configure HTTPSrvr Library
NOTE: This step is optional and ONLY relevant if you are using the HTTPSrvr broker. The default setup of BPC RiskManager initialises the SocketServer as the broker. The HTTPSrvr is optional.
The HTTPSrvr library is a packet broker, just like its cousin, the SocketServer. The SocketServer and the HTTPSrvr are the two methods that a RiskManager client can use to talk to the RiskManager DataServer. They can both operate at the same time on the one server.
As its name implies, the HTTPSrvr supports HTTP/HTTPS communications via an IIS web server. The IIS web server must be on the same server as the application server to which it talks. Its job is to listen on the server for incoming client connections and invoke a session on the application server for that client connection. It holds the client and server connections while a packet stream is being exchanged, resending if required. It distributes packets to the appropriate application server session.
Just like the SocketServer, it can be started and used without further configuration. There are a few configuration options available that may be important to you. In particular, if you will be running with more than 32 simultaneous connections, you will need to perform some configuration. The HTTPSrvr defaults to 32 simultaneous sessions. This roughly (but not entirely) matches the number of users. There are, however, times when additional sessions may be established from a client, so it is wise to leave about 5 to 10 sessions minimum headroom, and about 10% to 15% maximum.
Once installed and configured under IIS (see Install Socket Server as a Service And HTTPSrvr as an ISAPI library), the HTTPSrvr options are configured in the RiskManagerDataServer on the application server.
- On the application server computer, start the RiskManagerDataServer from the start menu. Because we are going to set registry settings, remember to start it as "run as administrator" on Vista or higher OS (right click on the RiskManager DataServer application in the start menu and choose the "run as administrator" option from the menu if it is available) or the settings will not be saved to the correct profile.
- A green disk will appear in the system tray. Double click on that disk to open the configuration screen.
- Select the HTTP/HTTPS tab. You will see a panel similar to the illustration.
- The options available are:
- Disable Compression. - The default for this is enabled. There should be no reason to disable this (except during debugging). Compression in HTTP/HTTPS comms is important as it significantly improves the system performance by significantly reducing the network transmission time at the expense of slightly increased server load. Our advice is to leave it alone. If disabled, you will also have to disable it on the clients.
- Maximum simultaneous connections - The default is 32. If you are expecting more than about 23-25 simultaneous connections increase this to the maximum number of connections you think are likely + 15%. There is no theoretical upper limit, but the background server load will increase the higher this number is raised as the garbage collector will have to work a harder, and more memory will be consumed. Normally we suggest pushing it up to about 100 the first time you decide you will need to exceed 32 users, and then increments of 32.
- Recycle time - This is the amount of time the garbage collector waits to clean the session pool, and hence the lag for cleaning used sessions slots. The default is 6 minutes, but 2 minutes is possibly better. We run our servers on 2 minutes. Anything below that starts to load the server for little or no improvement. Certain types of comms failures may require the garbage cleaner to have swept the sessions before connection can be re-established, so while 6 minutes puts almost no noticeable load on your server, it can be a little long under failure prone HTTP connections.
- The log file directory - This is ONLY used when logging is enabled. We recommend setting it up for when it is required but not actually using it unless we advise you to. The directory must be writable by the id under which the HTTPSrvr is run on IIS.
- Communication Problem Resolution - This section is ONLY for trouble shooting. Do NOT enable this. You would generally only enable this if BPC support requested you to. Logging in this case is not about tracking access, and alerts it is about dumping communications packets to the drive. It is just like running a sniffer permanently on your network. It is very, very heavy on the server as it essentially dumps everything that is being sent between all clients and the server.
- Remember to press "Save Settings" if you made any changes.
- Finish your configuration session by choosing "End Process" and "OK"
- On IIS, stop and start the worker process that hosts the HTTPSrvr.dll to force it to read the new settings
- Connect from a remote client using HTTP to verify that the HTTPSrvr is operating.