Ruby on Rails Performance Optimization

Ruby on Rails (also called Rails) is a Ruby Framework for Internet applications that support databases, what are the core features of Ruby on Rails and the articles into the world of Ruby on Rails reported before BKJIA?" This article focuses on how to optimize the performance of Ruby on Rails.

BKJIA recommended topics: Ruby on Rails development tutorial

At present, there are very few people in the Rails community who have experience operating Rails websites with high traffic to talk about the topic "performance" in detail. In China, Rails Applications are stuck in the learning and trial stages, and the real investment in business operations is basically not found. Therefore, it is too early to talk about this topic. Therefore, right should be a summative Article of the individual, and it will not be discussed in detail. It will be helpful to everyone.

I. Hardware

1. CPU

Compared with JVM and PHP, the Ruby parser is inefficient and may lead to many context switches, therefore, increasing the bus bandwidth and transmission speed between the CPU and memory will greatly improve the performance of Ruby applications. Among the mainstream x86_64 CPUs, AMD Opteron has a built-in memory controller on the CPU chip, which can effectively increase the data exchange speed between CPU and memory and improve the context switch capability. Therefore, AMD Opteron is much better than Intel Xeon EM64T.

2. Physical memory

Ruby runs in process mode. The concurrent response capability of Rails Applications depends on the number of Ruby processes. For the simplest Rails application, the physical memory occupied by a Ruby process is generally only 30-40 MB. However, for a Rails application that is truly complex and frequently accessed by databases and has a large amount of data, the physical memory occupied by the Ruby process is at least 100 MB, usually more than 200 MB, or even 300 MB. With 10 Ruby processes, the maximum physical memory usage is 3 GB, so the minimum physical memory is 4 GB.

Ii. Operating System

1. Linux distro

For AMD x86_64 CPUs, SLES has more optimizations than RHEL.

2. 32-bit or 64-bit

The 64-bit operating system should be used to make full use of the x86_64 CPU performance, and many Kernel Parameters in x86_64 Linux are also large, at the cost of requiring more physical memory. Therefore, the memory is more favorable.

3. File System

Rails generates session files on the hard disk for each browser session. It is common for a busy website to have tens of thousands or even tens of thousands of session files under the temporary file directory. Reiserfs provides much better performance than ext3 for accessing tens of thousands of small files under such directories.

Iii. Web Server

The mainstream options are Apache 2.2, lighttpd, and litespeed. Apache 2.2 can be ruled out first. lighttpd and litespeed are both good, But I will choose the open-source free lighttpd. The optimization parameters of lighttpd are not described here.

Iv. Ruby deployment

1. Ruby GC

You can use the GC patch provided by Railsbench to optimize Ruby memory usage, reduce GC frequency, and increase throughput. The cost is that the physical memory usage of Ruby processes doubles. Therefore, the more physical memory, the better. 4G is not enough. 8G, 16G is definitely not too much.

2. FCGI or mongrel

Ruby processes can run in FCGI mode, communicate with Web Servers through FastCGI protocol, or run in HTTP Server mode (Mongrel), and communicate with Web Servers through HTTP protocol, there is no difference in the performance between the two methods. FCGI means communication between a single machine through Unix Socket and Web Server is more efficient than using TCP Port.

3. How many Ruby processes are started?

There is no rule on the ratio of the number of Ruby processes to the number of connections on the web server. If there is more than one connection, the performance will be reduced. It depends on the practice and the usage of CPU and memory resources.

5. Applications

1. Avoid using component

2. Use symbol for the hash key

3. For ORM, the database table design principle is that the granularity should be smaller, and common fields and infrequently used fields should be separated to different tables as much as possible, separate large fields that seriously affect performance into separate tables

4. If the object cache is not used, the include method of the query can pre-load the correlated object to avoid the n + 1 problem.

Vi. Cache

1. Rails page cache, Action cache, and fragment Cache

The cache method provided by Rails can effectively reduce the load on the application server, but the cache granularity is too coarse, the adaptation scope is narrow, and the processing of cache expiration is cumbersome.

2. Object Cache

Rails Applications can be horizontally scaled. The performance bottleneck is often database access. Using the CachedModel object cache can effectively reduce the database load, but CachedModel is not as powerful as Hibernate second-level cache, non-primary key queries cannot be cached for reading, non-primary key queries cannot be cached for filling, and there is a conflict with file-column. You need to overwrite the save method of the model object and so on. In addition, when the object cache is used, the query method include should be removed to avoid the association query's inability to use the cache.

3. query Cache

For time-consuming statistics queries, if real-time query is not required, you can use memcache-client to cache the query results to memcached.

VII. Session Storage Method

Because of the efficiency of the Linux File System and the memory used by the operating system for disk cache, the hard disk file is used by default to save the session, which does not bring performance bottlenecks. memcached does not improve the I/O performance much. To optimize session hard disk reading, you can use RAMDISK in addition to memcached.