Ruby on Rails Real case Three

The best way to prove the scalability of rails is to look at an application that actually scales effectively. Here we look at the performance problems encountered by three real-world applications and how they solve these problems.

37signals Development of Basecamp

Rails was born in the Basecamp project. This is a web-based project management tool that requires monthly payment by its users. The Basecamp server provides thousands of users with the functional services required for project management.

The biggest challenge in optimizing performance for Basecamp is the difficulty of using caching: Everyone comes from different companies, has different permissions, and therefore sees different data. (But on the good side, only those who have a registered account can access Basecamp, so don't worry about it being introduced by Slashdot and bringing in a ton of unauthorized users.) ）

Basecamp handles about 400,000 dynamic requests a day (from the moment you see the login page, until you browse the project dashboard, all the requests are included). In the case of no caching, the load is considerable. There are currently two web/application servers to process these requests, each with two to strong 2.4GHz CPUs and 2GB of memory, running 15 fastcgi processes and 50-100 Apache 1.3.x processes. The load on the server is usually between 0.5 and 1.5.

The MySQL database server is independent, but the other two 37signals applications (Ta-da list and backpack) also use this database. The number of records in the database is at level 100,000, and the largest table has about 500,000 records. While servicing three applications, the load on the database server is typically between 0.1 and 0.3-the database is not a basecamp bottleneck, which is good news. If the current two servers are overwhelmed, the problem can be solved simply by adding a new server, and we did.

Robot Co-op development of the things

The things is a site for tracking life goals. You can write your goals here, such as "I want to learn Japanese", write blogs around this goal, and read about other people who have the same goals. Part of this application requires authentication, and more is publicly available, allowing unauthorized users to access it. There are often drastic changes in the amount of public content access, but it's okay to cache them.

The cached storage strategy employs memcached--to improve performance, and the site uses memcached heavily. Because the user's session data is saved in memcached, any server can process requests from any user at any time without requiring any session synchronization measures. For expensive database queries, the results are also serialized in the form of a Actionrecord object into the memcached, with the appropriate timestamp.

After three months on line, the things handles about 200,000 dynamic requests a day. It uses two web/application servers, as well as a dedicated database server, with two 3GHz Xeon CPUs and 2GB of memory in three machines. The Apache 1.3.x server and 25 fastcgi processes are running on two web/application servers respectively. Server load is less than 0.3,cpu idle time often around 80%.

Mortgage processing engine

Rapid reporting their "identity and revenue verification Engine" on the rails system. 80% of America's top 1000 mortgage guarantors use the engine to deal with 2 million mortgage applications a month.

At first, Rapid reporting wanted to test whether rails was up to the job, so they tested the application from 10 cluster machines and launched 3,000 requests per second. Real-world applications probably need to process 300 requests per second and execute a series of business logic. In addition, the handling of the mortgage business must follow the Graeme-Brilleux regulations (GLBA), so many places need to check licensing, generate Audit index.

Applications use PostgreSQL as a database, lighttpd as a Web server, each application server runs approximately 10 fastcgi processes, and load balancing with IP tunneling technology on a single virtual server (see http:// www.linuxvirtualserver.org/VS-IPTunneling.html) <!--[if!supportfootnotes]-->. With this deployment, you can add and subtract fastcgi processes at any time without restarting the Web server. This enables automation of process management by monitoring the load with a daemon and allocating more fastcgi processes when the load reaches its peak.

This is a real business application. These things may sound boring, but knowing them may determine whether you can get a client's approval.