At this point, it is worth reviewing the specification of a server platform that will host a production Rails environment. For small business applications, it is initially practical to run the Rails application, a web server, and database, all on the same computer. There are a number of steps that can be taken to improve performance as use of the application increases. However, for most purposes, when putting your first application into production, the single server solution is a good starting point.
As mentioned in Chapter 3: Laying the Foundations, the main consideration for a Rails server is plenty of RAM. Rails and databases are memory intensive. Each Rails instance typically uses 25 to 35Mb of RAM. While this may not be a lot for a dedicated server, it can be significant on a shared server. For example, Rory only has a single server that also acts as a file and print server, web server, and the company email server. This arrangement is typical of many small businesses. On a shared server, the additional memory used for each Rails instance, and the database behind the application can easily take the used memory beyond the size of the physical memory. At this point, the operating system will more aggressively use the hard disk as memory cache and the performance of the server will plummet as a result.
A modern computer with a single CPU will deliver Rails-generated web pages in a timely fashion over a local area network. Differences of CPU speed of one or two steps are unlikely to make a significant impact on performance. When specifying a server, use the budget that may have been used to upgrade the processor a couple of steps to upgrade the memory instead.
However, a Rails application can hog a CPU occasionally. For example, in Rory's application, the process of importing data from a CSV file is likely to take a few seconds during which Ruby will push the CPU to maximum usage and therefore negatively impact the other applications also running on the server. In this situation, multiple processors can allow other processes to carry on while Ruby loads one of the CPUs. Therefore, while not necessary, having a server with multiple CPUs is advantageous. Of the two, having a server with two moderate performance CPUs
is preferable to having a server with a single very fast processor. In these days, of multi-core processors, having a dual core processor provides similar benefits to having two separate CPUs.
Rails applications are relatively small as they mainly comprise simple text files. For example, an intranet application that provides multiple functions and services to a small business can typically comprise 1400 files spread over 700 folders and yet take up less than 10Mb of disk space. Of course, the data stored in the database takes up much more disk space, but for many small applications MySQL takes up less than 1Gb of the disk space, including the data files. In these days, when it is getting difficult to buy a hard disk with a capacity of less than 100Gb, disk space used by a Rails application is rarely an issue.
However, access speed to the disks can be an area where performance can be improved especially in boosting the performance of the database. The simplest and best way to increase disk access speeds is to use an array of disks instead of a single hard disk. A RAID 1 system (pair of mirrored disks) will provide enhanced read speeds (as well as improved fault tolerance), though slower write speeds, when compared to a single disk. RAID 5 systems (at least three disks) provide faster read and write speeds, with performance improving as more disks are added to the array. That is, a seven disk array will be faster than an array of three identical disks on the same controller.
The increase in performance and additional fault tolerance (both RAID 1 and 5 systems are designed to handle the loss of one of the disks in the array), make RAID 1 or 5 an attractive option for any business server, including those hosting a Rails production environment.
Rails applications are designed to work over the Internet, where bandwidth is typically two orders of magnitude less than that available on a business' local area network (LAN). For example, currently most users would consider 10Mb/s a fast Internet connection, but a small business can easily buy a small 1Gb/s LAN switch for less than $40. So, a Rails application will not be throttled by a standard 100Mb/s dedicated network connection. However, the key word is dedicated. In a shared server environment, there may be another service that is hogging the network connection. For example, a user may be downloading a large file from the server. A faster network connection will lessen the impact of providing multiple services simultaneously, to multiple users over a single interface. Therefore, if you have a
100Mb/s network, providing a 1Gb/s connection from your server into the core of the network it is likely to improve the service performance. This will require a 1Gb/s NIC in your server and a 1Gb/s port in your core LAN switch.
If our application becomes as popular as I am sure we all hope they will, our users will start to rely on them. One consequence of this is that if there is a failure, there must be a way to recover the system quickly and with the least loss of data. Therefore, regular backup is essential. Two databases in particular need to be backed up: your main database, and your Subversion repository. Traditionally, tape systems have been used for backup, but recently network attached storage (NAS), often in the form of dedicated disk arrays, have become a popular alternative. An in-depth discussion on the pros and cons of the different backup solutions is beyond the scope of this book. Suffice to say that the key point is that we invest in a reliable backup system, and use that system to regularly backup our user's data and our Rails code.