My Web Crossing server has been performing poorly. I see a file named "client.log" in my webx binaries directory. What does this mean?
Answer:
This is a classic problem when running Web Crossing as a CGI. It means that there are inadequate resources on your machine, and
the best way around them is to stop running as a CGI.
Every line in Client.log is a failed attempt to connect to Web Crossing because the server didn't have enough socket resources
available.
Background: On Unix, Web Crossing runs as a daemon. There are actually four processes - webx-run is a "super daemon" that just
checks every two minutes to see if webx-go is still running, and restarts it if it crashed. webx-go is the actual application, and it has two child webx-go processes that do DNS related operations.
When a user accesses the shell script .../cgi-bin/WebX, that script launches a new instance of webx-cgi and passes it the location of
webx-go. webx-cgi opens a socket connection to webx-go, passes the request, waits for the response, gives it back to the web server, and exits.
*** So for one user interaction there are two process launched (the script and the webx-cgi instance) and a socket connection. This is why CGI is expensive. **
Client.log is written by webx-cgi when it is unable to open a socket connection to webx-go. We can't write it to the regular webx.log file or logNN because those are written by webx-go and the whole problem is that webx-cgi can't communicate with webx-go.
*** The most common cause is that the number of sockets per process permitted by the OS has been exceeded. We believe the
maximum limit on Solaris, for example, is 1024 sockets per process, therefore no more than 1024 users can possibly access Web Crossing simultaneously. Other system processes (such as Apache) also require sockets and the limit may be set to a lower level on this machine, so the actual limit may be much less. Adjusting this limit is system dependent. Check with your system administrator or others familiar with your OS to see what is possible and how it may be accomplished.
An easy way to avoid this is to run web crossing in "Direct Web Service" mode. See "Direct Web service (HTTP)" in your sysop
documentation.
Other options include running in Master/Slave mode with a hardware load balancer to distribute the incoming requests amongst nodes in a Web Crossing cluster.