Ruby on Rails Application Performance optimization path

This is a summary of our experience in running the Javaeye website for nearly half a year. There are very few people in the entire rails community who are running a large number of rails Web site experience to discuss this topic in detail. As for the domestic, the rails application all stays in the study and the attempt stage, the real investment business Operation's basic cannot find, therefore discusses this topic is too early, quite has cast pearls the feeling. So the right to be a personal summary of the article, it will not be very detailed to start talking about, can enlighten everyone.

First, hardware

1, CPU

The ruby parser is inefficient compared to the jvm,php parser and may result in more context switch, so increasing the bus bandwidth and transfer speed between the CPU and memory will have a greater performance boost for Ruby applications. In the current mainstream x86_64 CPU, AMD Opteron in CPU chip built-in memory controller, can effectively improve CPU and memory data exchange speed, improve context switch ability. So using AMD Opteron is much better than Intel Xeon EM64T performance.

2. Physical memory

Ruby is running as a process, and the concurrent responsiveness of rails applications depends largely on the number of ruby processes. One of the simplest rails applications, where a ruby process consumes less physical memory than 30-40MB, but for truly complex rails applications with frequent database access and large amounts of data, the Ruby process has a steady physical memory footprint of at least 100 MB, often reaching more than 200 MB , even 300MB. To open 10 ruby process calculations, the upper limit of physical memory usage is 3GB, so 4GB physical memory is minimal.

Second, operating system

1, Linux distro

For AMD x86_64 CPUs, SLEs is more optimized than Rhel.

2, 32-bit version or 64-bit version

The 64-bit version of the operating system should be used to give full play to the performance of the x86_64 CPU, and x86_64 Linux Many kernel parameters are much larger, at the cost of requiring more physical memory. So the more memory.

3. File system

Rails will generate session files on the hard disk for each of the browser sessions, a busy Web site, and the temporary files directory with tens of thousands or even tens of thousands of of them, is a common phenomenon. For access to tens of thousands of small files under this directory, the ReiserFS is much better than the ext3 performance.

Third, Web Server

The mainstream choice is apache2.2,lighttpd,litespeed. apache2.2 can be eliminated first, lighttpd and Litespeed are good, but I will choose Open source free lighttpd. As for the lighttpd of the various optimization parameters are not discussed here.

Iv. Deployment of Ruby

1. Ruby GC

You can use the GC patch provided by Railsbench to optimize ruby memory usage, reduce GC frequency, and increase throughput, at the cost of doubling the physical memory footprint of the ruby process. So the more physical memory the better, 4G is not enough, 8g,16g absolutely not too much.

2, fcgi or mongrel

The ruby process can be run in a fcgi way to FASTCGI protocol and Web server traffic, or it can be run as HTTP server (that is, mongrel), with HTTP protocols and Web server traffic, and there is no difference in performance. Fcgi Way, on the single machine above through the UNIX socket and Web server communication, more efficient than the TCP port to go.

3. How many ruby processes to open

The ratio of ruby processes to the number of connection in the Web server is not in order, and much less will degrade performance, to be explored by practice, and to refer to the use of CPU and memory resources.