Tôi đã dành một khoảng thời gian để điều chỉnh ứng dụng của mình trên heroku và đã dành thời gian làm việc để điều chỉnh hiệu suất của các ứng dụng Rails trong nhiều cài đặt khác nhau.
Khi tôi chạy ab -n 300 -c 75 ... myapp.com .... # là bản sao lưu vào trang web chính của tôi và nằm trong gói cedar miễn phí với unicorn
Requests per second: 132.11 [#/sec] (mean)
Time per request: 567.707 [ms] (mean)
Time per request: 7.569 [ms] (mean, across all concurrent requests)
(điều này chống lại một trang chủ không hoạt động mạnh mẽ, vì vậy tôi chỉ cung cấp nó như một ví dụ "heroku có thể nhanh đến mức nào trên gói miễn phí với một trang rất đơn giản?", chứ không phải là "ứng dụng của bạn nên nhanh quá ")
Đây là danh sách kiểm tra Rails Performance Tuning 101 của tôi:
-
Đo lường trình duyệt / thời gian tải trang trước (trình duyệt đưa ra rất nhiều yêu cầu, ab chỉ cho bạn biết về một trong số chúng và thường thì yêu cầu trang chính của bạn không phải là vấn đề), lấy số liệu cơ bản về tải trang từ các công cụ như www.webpagetest.org hoặc www.gtmetrix.com cho các trang hiển thị công khai hoặc các công cụ trình duyệt Yslow, tốc độ trang google hoặc dynatrace cho các trang riêng tư. Nếu bạn nhìn vào sơ đồ thác nước tải trang (bảng điều khiển 'Net' trong chrome / firefox), nó thường cho thấy html của bạn tải nhanh (dưới một giây), nhưng sau đó mọi thứ khác sẽ mất 1-3 giây để tải. Thực hiện theo các đề xuất về tốc độ trang / Yslow về cách cải thiện (đảm bảo rằng bạn đang sử dụng toàn bộ nội dung của đường dẫn nội dung Rails 3.1)
-
Đọc qua các tệp nhật ký / di tích mới của bạn để tìm điểm hấp dẫn của yêu cầu 'chậm nhất / lần truy cập thường xuyên nhất' và lập hồ sơ điều gì xảy ra cho yêu cầu đó (nó có phải là ruby chậm / sử dụng nhiều mem hay nhiều truy vấn không?) để có một cách đáng tin cậy để phát hiện và giám sát các vấn đề về hiệu suất và không chỉ thay đổi mọi thứ một cách ngẫu nhiên. Khi bạn đã xác định được một số khu vực mục tiêu, hãy tạo các tập lệnh thử nghiệm để trợ giúp trước / sau khi thử nghiệm và chứng minh rằng thay đổi của bạn có ích và phát hiện xem liệu hồi quy có xâm nhập hay không.
-
Thiếu chỉ mục trên cột db là một trong những vấn đề phổ biến nhất và dễ giải quyết nhất. Chạy giải thích về các truy vấn mục tiêu hoặc xem qua nhật ký truy vấn chậm của bạn, để xem công cụ lập kế hoạch truy vấn đang làm gì. Thêm chỉ mục cho khóa ngoại, cột tìm kiếm hoặc dữ liệu chính (bao gồm chỉ mục) nếu thích hợp. Thử nghiệm lại với dữ liệu sản xuất thực tế để chứng minh rằng nó tạo ra sự khác biệt. (bạn có thể chạy giải thích trong heroku, cũng như chạy các truy vấn cho các chỉ mục bị thiếu hoặc không sử dụng)
-
Hầu hết các ứng dụng Rails hoạt động kém đều mắc phải N + 1 truy vấn vì nó quá dễ dàng để viết order.owner.address.city và không nghĩ về điều gì sẽ xảy ra khi nó ở trong một vòng lặp. Các truy vấn N + 1 không nhất thiết là các truy vấn chậm, vì vậy chúng không hiển thị trong nhật ký truy vấn chậm, chỉ là có rất nhiều truy vấn và hiệu quả hơn nếu thực hiện tất cả cùng một lúc. Sử dụng:include hoặc .includes () để tải dữ liệu đó một cách háo hức hoặc xem xét việc thực hiện truy vấn của bạn theo cách khác.
-
Phân tích luồng ứng dụng của bạn và tìm kiếm cơ hội lưu vào bộ nhớ đệm. Nếu người dùng quay đi quay lại giữa trang chỉ mục và trang chi tiết và quay lại lần nữa, có lẽ chế độ xem chi tiết ngắn gọn mà không rời khỏi trang chỉ mục sẽ cung cấp cho họ dữ liệu họ cần theo cách nhanh hơn. Tôi đã viết một số suy nghĩ thêm về điều đó trên blog của mình
Tôi đã thuyết trình về những kỹ thuật này và những ý tưởng khác ở Chicago tại hội nghị WindyCityRails năm nay. Bạn có thể xem video tại đây trên www.RailsPerformance của tôi blog .com Điều tôi thích ở heroku là bạn phải có khả năng mở rộng ngay từ đầu. Khi bạn xem các cuộc thảo luận trên danh sách gửi thư, bạn thấy rằng hầu hết mọi người đều biết các phương pháp hay nhất về hiệu suất và cách tận dụng tối đa máy chủ. Tôi cũng thích cách bạn nếu bạn muốn duy trì giá rẻ, bạn hãy tìm hiểu các thủ thuật điều chỉnh hiệu suất sẽ giúp bạn đạt được hiệu quả cao nhất.
Chúc bạn thành công!
