What do you need to run Journyx Timesheet?
Journyx Timesheet is a 100% web based software solution that can be accessed from any client's operating system that runs on a modern web browser, such as current versions of Internet Explorer, Firefox or Safari.
Operating system server
The platforms that can host Timesheet are:
- Windows 2000/2003 en Windows XP/Vista
- Solaris versions 7 en SPARC architectuur
- Linux: Redhat 6.2-7.3 & other Linux (glibc 2.1)
- Linux: Redhat 8 & other Linux (glibc 2.2)
- Linux: Redhat 9 & other Linux (glibc 2.3)
- FreeBSD vanaf v4.6
- AIX vanaf v4.3.3
Note: Microsoft has officially ended support for Windows 2000 Server and is no longer creating security patches for it. Therefore, Journyx strongly recommends all Windows customers transition to Windows 2003 Server at their earliest convenience. Timesheet will continue to function on Windows 2000 Server as long as the Windows installation remains secure, but once the security of the box is compromised (due to the lack of Windows security updates from Microsoft) Timesheet may be compromised and could be unrecoverable.
Web and Application Servers
Journyx Timesheet employs Apache as the default Unix/Linux web server. Windows platforms employ IIS by default.
Journyx offers the following configurations, which should be considered as suggestive of the type of hardware that could be used for Journyx Timesheet installations. The specific hardware configurations below are not necessarily tested nor endorsed by Journyx, Inc., but are broad guidelines for planning.
It must be noted that individual requirements with regards to performance and scalability must be validated by qualification testing and tuning which model the expected production usage. Large variations from recommended hardware may be necessary depending upon factors such as burst loading, load types (e.g. proportions and timing of reporting, time entry, import/export synchronization) and user behavior.
Journyx recommends that installations for 150 users or more use two machines, one for the database server and one for the application server so both machines should be considered in capacity planning.
Single machine installations, generally considered acceptable for installations with 50 users or less are not covered specifically, but acceptable performance with configurations specified for less than 150 users is a reasonable starting point.
A Note On Network Connectivity
User interaction with the server is governed by normal networking methodology and is beyond the scope of this document, but requirements are similar to any web based application where sufficient bandwidth is necessary to support the expected user load on the web server. Installations with expected high network usage for user connectivity may need multiple network connections and high speed networks.
A minimum of a 100Base-T connection between the application and database servers for installations of 150 or more users is required. In congested networks a dedicated network connection between the database server and application servers is highly recommended.
| Operating System | Web Server Software | Machine Architecture |
| Windows 2000/2003/XP | Internet Information Service (IIS) | Intel |
| Linux | Apache | Intel |
| Linux | Apache of IBM HTTP Server | POWER of POWER-PC IBM eserver pSeries |
| Solaris | Apache of IBM HTTP Server | SPARC |
| AIX | Apache of IBM HTTP Server | POWER of POWER-PC IBM eserver pSeries |
| FreeBSD | Apache | Intel |
Databases
Journyx Timesheet ships with a default database.
The default for Journyx Timesheet for UNIX is postgreSQL v7.3. The Windows version of Journyx Timesheet ships with MSDE as its default; however, integration is available with other ODBC compliant databases, including DB/2, Oracle and SQL.
More information about using external databases can be found by clicking on the following links:
| Operating System | Database software | Machine Architecture |
| Windows 2000/2003/XP | SQLServer, DB2 or Oracle | Intel |
| Linux | DB2, Oracle or PostgreSQL | Intel |
| Linux | DB2, Oracle or PostgreSQL | POWER of POWER-PC IBM eserver pSeries |
| Solaris | DB2, Oracle of PostgreSQL | SPARC |
| AIX | DB2, Oracle of PostgreSQL | POWER of POWER-PC IBM eserver pSeries |
| FreeBSD | PostgreSQL | Intel |
Required space for the Timesheet database
Each time record consumes approximately 650 bytes of permanent storage, though complex business needs can drastically increase this value. For this reason, we recommend at least 1 GB of RAM and 40 GB of permanent storage. Additional storage may be necessary depending on the number of users and the back-end components.
The initial size of a brand new and empty Timesheet database is very small - a few hundred kilobytes at most. Over time, however, as records are added the database will grow. But how much? The information on this page is designed to help you answer that question for yourself because each installation of Timesheet is different.
There are essentially two components that make up the total disk space usage of a Timesheet database. The first component is general configuration overhead, which is comprised of the actual user and project records, entry codes, and other configuration records. The overhead for these tend to be very small or even negligible compared to the other component and will grow fairly slowly once the basic configuration is established. On most sites this general overhead is less than 10 MB.
The majority of disk space required by Timesheet is dedicated to ongoing time records and related information. The exact usage depends, of course, on your configuration choices and other factors, but we present here the information needed to get a rough idea.
The total usage of a site can be approximated with the following formula:
General Overhead + (Time Record Overhead * Active Users * Days)
Time Record Overhead consists of: ((T * R) + (T * H * E))
Where:
* T = Average Number of Time entries per user per day
* H = Number of extra fields marked 'Historic'
* R = Average time record size (approx. 2 KB per record)
* E = Average extra field size (approx. 0.5 KB per record)
Historic means that the value of an extra field, such as the Pay Rate of a Project, is recorded at the point in time when the time record is made. Therefore, if the pay rate for that project changes at some point, you still have the historic pay rate at the time the record was made. Some sites do not need this feature while others use it extensively.
Example: Assume a case in which you have 100 active users on your site, and each one of those users creates on average 5 separate time entries per day. Let's also suppose that you have 4 historic extra fields for time records.
(5 * 2) + (5 * 4 * 0,5) = 20 KB per user per day.
Therefore in this example the site would need approximately: (20 KB * 100 users * 365 days) = 712 megabytes per year. These calculations should be used as a rough guide only. Or, as they say in Detroit, "your mileage may vary."