This section describes the technical aspects of the Collaborator server. This information is not generally needed for server administration.
Server Technology
The web server is Apache Tomcat 9.0.60. Collaborator itself is a collection of standard J2EE servlets, packaged in the standard WAR format that can be used inside any J2EE servlet container. Tomcat is the only servlet container specifically supported by SmartBear.
Tomcat is a sophisticated, scalable stand-alone web server with support for HTTPS, LDAP authentication, advanced HTTP protocol options, database pools, load-balancing, and more.
For more information about how Collaborator is configured under Tomcat, see Tomcat Configuration Reference.
Start and Stop Server
In Windows
The server is a Windows Service. This means you can start, stop, and restart the server just like any other service. The typical way is through the Services in Windows control panel. You can also use the net start ccollab-server
and net stop ccollab-server
commands in the command line.
If you encounter the Error 1: Incorrect function
error when starting the server, or the server fails to start with no error, possible solutions are:
-
Free up memory for the service by removing
-Xmx
or-Xms
in the ccollab-server.vmoptions file. -
Confirm the valid Java version and environment by running the
java -version
command in your Java bin directory.
In Unix
The server is a shell script in the installation directory, called ccollab-server. You can use the usual start
and stop
directives, which also means the script can be used directly in the init.d script.
Data Storage
Collaborator stores almost all data in the database initially set up for it. It also uses file content storage – a local folder that keeps copies of uploaded files.
Recommended Hardware
For trials, you can use any hardware available. We have lots of customers who have done pilots on "servers" such as laptops and regular workstations. For small groups (30 users or less) doing small reviews, the server is not demanding on CPU, memory, disk access, or database access; if you run the server on a workstation, you will never know it is there.
For permanent installations, and to support hundreds or thousands of users, please see our hardware recommendations in the System Requirements section.
We run our own scalability tests using similar hardware. Our standard smoke test is 500 caffeinated users, most hitting Review Screen and Side-by-Side page, a few in administrative and reporting pages. This represents far more activity than 500 real users.
Performance Tuning
General tips for making the server run as fast as possible:
-
Use the latest version of the server and client.
We are constantly improving speed bottlenecks as they are reported. Upgrade to the latest version, or scan the version history to see if any speed improvements were made.
-
Increase the Refresh interval setting. This will make the chat pane update more slowly but can reduce stress on the server by many times. The default value is 30 seconds, but 45 or even 60 seconds can work and reduce server load.
-
Make sure nothing else is running on the Collaborator server machine.
Often another server or process running on the same machine as our server will take up CPU cycles or slam the hard drive. For small installations it is quite common (and appropriate) for Collaborator to share a server, but for larger installations or when you are trying to squeeze out more performance you should dedicate a server.
-
Increase the number of allowed database connections (you can find instructions here).
Even if you are not getting errors on the web page about running out of connections, the web server threads might still be waiting for database connections to become available. Error messages do not appear until those waits start timing out.
-
Increase the speed of the connection between the database server and the Collaborator server.
Collaborator makes many small database queries, so decreasing network latency should improve performance. We recommend that Collaborator and the database server be connected via gigabit Ethernet.
-
Increase the number of server threads (you can find instructions here).
Just as with database connections, more server threads means less waiting for browser connections on a busy server.
-
Increase the max number of simultaneous connections in your browser.
Both Internet Explorer and Firefox default to just two simultaneous connections to a server. You can increase this to 4 or more. This will not help if you have a very slow connection (for example, a modem), because slow connections are probably already maxed out.
-
Make sure caching is enabled in your browser.
Sometimes a static cache of a browser can be disabled; make sure it is enabled (at least for connections to our server). We have lots of styles, Javascript, and images that normally are cached.
-
Tune the memory settings for Collaborator server (you can find instructions here).
More memory will often improve performance, but large documents in particular require a great deal of it, and often also require to change your garbage collector settings. If your users perform document reviews frequently, visit this section.
Monitoring
You can monitor our application like any other. Like many enterprise-ready Java applications, you can monitor the condition of the server using JMX.
See Also
Troubleshooting
System Requirements
Platform-Specific Notes
General Settings