Technical Specifications

This section describes the technical aspects of the Code Collaborator server. This information in not generally needed for server administration.

The web server is Apache Tomcat v6.0.20. Code 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 Smart Bear.

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.

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" Control Panel. You can also use "net start ccollab-server" and "net stop ccollab-server" from the command-line.

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 an init.d system.

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'll never know it's there.

For permanent installations, and to support hundreds or thousands of users, we recommend the following minimum hardware:

•	Windows XP Server, Linux, or Solaris (If Windows, must be a server edition, not workstation edition)

We run our own scalability tests using this hardware. Our standard "smoke test" is 500 caffeinated users, most hitting Review Summary and Side-by-Side pages, a few in administrative and reporting pages. This represents far more activity than 500 real users.

We currently have zero open scalability issues for customers with over 1000 users with hardware at least as capacious as the set-up given above.

•	Use the latest version of the server and client. We're 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 "chat 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 5 seconds, but 15, 30, or even 60 seconds can work and reduce server load.

•

Make sure nothing else is running on the Code Collaborator server.
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's quite common (and appropriate) for Code Collaborator to share a server, but for larger installations or when you're trying to squeeze out more performance you should dedicate a server. And this means really dedicate, not just its own VMWare instance.

•

Increase the number of allowed database connections (instructions here).
Even if you're 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 don't appear until those waits start timing out.)

•	Increase the speed of the connection between the database and the server. If your database isn't on the same machine, can you get gigabit ethernet? Can you put the database on the same machine as our server?

•	Increase the number of server threads (instructions here). Just as with database connections, more server threads means less waiting for browser connections on a busy server.

•	Don't run inside a virtual environment. Environments such as VMWare can impose as much as a 40% speed hit (as shown in our own in-house tests). If you want maximum performance don't use extra layers between our server and the hardware.

•

Increase the max number of simultaneous connections in your browser.
Both IE and FireFox default to just two simultaneous connections to a server. You can increase this to 4 or more. This won't help if you have a very slow connection (e.g. a modem), because slow connections are probably already maxed out.

•	Make sure caching is enabled in your browser. Sometimes a browser's static cache is disabled; make sure it's enabled (at least for connections to our server). We have lots of styles, Javascript, and images that normally are cached.

In our tests, the server performs at 40% capacity when running under VMWare. Our tests were performed against VMWare Workstation v5.5 which itself was running under Windows XP.

Whenever you see performance or scalability numbers in this manual, you should mentally scale capacities by 40% when considering a VMWare or other virtualization environment. Your mileage may vary, and we're not experts in virtualization.

You can monitor our application like any other. Like many enterprise-ready Java applications, you can monitor using JMX.