The overall Tamino performance is influenced by a number of components, such as CPU, virtual memory, physical memory (RAM), physical disk space, and network communications. Each of these may lead to performance bottlenecks. Increasing hardware performance with more CPU power and better I/O throughput should of course also improve response time. But before spending the money, you should find out where time consumption is highest: in the Tamino server, in the web server, on the network, or in the application.
In general, upgrading your hardware to improve performance is a step that you should only consider when you have achieved all of the possible performance gains using the methods described in the previous sections of this document.
On Windows, use the Performance Monitor, which is part of the Administrative Tools. Access it by choosing from the Windows Control Panel. You can retrieve information on CPU usage, disk I/O, and memory usage.
Before you can use the Performance Monitor for I/O measurements, enable
the IO counting by issuing the command
diskperf at the command prompt. Note that this
enables I/O monitoring after the next restart of your machine. DISKPERF
[-Y[E] | -N] [\\computername] -Y[E] enables the disk performance
counters when the system is restarted. E enables the disk
performance counters used for measuring performance of the physical drives in a
striped disk set when the system is restarted. Specify -Y without
the E to restore the normal disk performance counters.
-N disables the disk performance counters when the system is
restarted. \\computername is the name of the computer you want to
see or set disk performance counter use.
It is quite simple: If the CPU's workload is 100 %, you cannot get more speed out of your system. Additional CPUs can increase the throughput, unless the system is I/O bound. For small databases, almost everything can be kept in memory, according to the value of the buffer pool parameter of the database. In this case, an additional CPU is recommended if multiple users are working at the same time.
On a Windows platform, you should watch for the following on your Performance Monitor:
When monitoring the CPU, check that the amount of CPU time spent in kernel mode is below 10 %. This is the counter % Privileged time of the Processor object. The instance to monitor is either _Total for a multiprocessor system, or 0 for a single CPU system.
If Tamino runs on multi-CPU machines (Symmetric Multi-Processing, SMP), automatic load balancing is carried out between CPUs. There is no load balancing between different machines, though.
Increasing the swapfile makes sense if Tamino fails with memory exception. Keep in mind that this may lead to swapping.
Usually a disk controller can handle a specific amount of I/O operations or memory that can be transferred to or from the disk. If your system is I/O bound, it may help to add additional physical disks to the system in order to get a higher degree of parallelism. In order to do so, you have to distribute the Tamino data spaces over multiple disks. If you use multiple physical disks for your database and your system is I/O bound, it may be possible to increase the throughput by using multiple disk controllers. Some disk controllers support multiple channels, too. For recovery reasons, the data and index containers must be on a different physical disk than the log and backup data spaces. Additionally, it is recommended to put the index, the data container, and the journal space on separate disks. Using RAID (Redundant Array of Inexpensive [or Independent] Disks) can improve the overall I/O performance. A general recommendation in terms of high availability and performance is to have the log container on a RAID 1 (mirrored) disk and the data and index container on a RAID 5 disk.
On a Windows platform, the things to watch for on the Performance Monitor are:
When the disk time is significant (about 50 %), you might want to increase the size of the buffer pool. If this does not help due to many update operations on the database, check which disks are the most active. Consider the following to distribute I/O load to different physical disks:
Move database containers to locations stored on physically different disk drives.
If you are using a server version, you might want to create disk volumes spanning multiple disks.
If you have to serve a high load on your machine, you may run out of sockets due to the TCP_WAIT_TIMEOUT. This applies to the TCP_WAIT_TIMEOUT and the number of available sockets.
On Solaris, the command to show the time wait parameter is:
$ /usr/sbin/ndd /dev/tcp
tcp_time_wait_interval
The command to set the parameter is:
$sudo /usr/sbin/ndd -set /dev/tcp tcp_time_wait_interval
30000
The requirements for a multi-user environment are:
The server hardware should be powerful as possible: large RAM, many fast CPUs, powerful I/O system, etc. The more users you have, the more CPU power is necessary. Try to have fewer but faster CPUs to reduce locking conflicts.
Each single command (query or insert) should run as fast as possible. For information, see the sectionVery Fast Queries. Also, make use of cursors to keep the result set that is transferred from the server to an application small. However, keep locks and cursor only as long as you need them, so that they do not constrain the requests other users have.
The application process should not produce data of its own, e.g. protocol files, or at least as little data as possible. If data is produced, each application process should write them into separate data areas, for example directories or disks.
