|
This section describes the technical aspects of the CodeCollaborator server. This information is not generally needed for server administration.
The web server is Apache Tomcat v6.0.20. CodeCollaborator 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 CodeCollaborator is configured under Tomcat, see the Tomcat Configuration Reference.
Starting and Stopping the Server
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" Control Panel. You can also use "net start ccollab-server" and "net stop ccollab-server" from the command-line.
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 an init.d system.
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'll never know it's there.
For permanent installations, and to support hundreds or thousands of users, we recommend the following minimum hardware:
| • |
Dual XEON 3.5ghz processors |
| • |
10,000 RPM hard drives, preferably SCSI. |
| • |
100GB storage space (this number varies a lot based on usage patterns) |
| • |
Some kind of drive backup hardware (RAID 0 is fine) |
| • |
Windows, 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.
General tips for making the server run as fast as possible:
| • |
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 CodeCollaborator 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 CodeCollaborator to share a server, but for larger installations or when you're trying to squeeze out more performance you should dedicate a server. |
| • |
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. |
| • |
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. |
Monitoring
You can monitor our application like any other. Like many enterprise-ready Java applications, you can monitor using JMX.
|