2012-06-25 32 views
6

Tôi quan tâm đến các cách tối ưu hóa thiết lập Unicorn cho ứng dụng Ruby on Rails 3.1.3 của tôi. Tôi hiện đang sinh ra 14 quy trình công nhân trên High-CPU Extra Large Instance vì ứng dụng của tôi dường như bị ràng buộc CPU trong khi kiểm tra tải. Vào khoảng 20 yêu cầu mỗi giây phát lại yêu cầu trên một thử nghiệm tải mô phỏng, tất cả 8 lõi trên ví dụ của tôi nhận được đạt đỉnh điểm, và tải hộp gai lên đến 7-8. Mỗi trường hợp kỳ lân được sử dụng khoảng 56-60% CPU.Sử dụng CPU Unicorn trong quá trình kiểm tra tải, cách tối ưu hóa

Tôi tò mò những cách nào để tôi có thể tối ưu hóa điều này? Tôi muốn có thể thêm nhiều yêu cầu mỗi giây vào một phiên bản có kích thước này. Bộ nhớ hoàn toàn tốt như tất cả các I/O khác. CPU đang được tanked trong các thử nghiệm của tôi.

+0

Bạn có sử dụng ruby ​​1.9 không? Nếu không, điều đó có thể hữu ích. – Reactormonk

+0

Tôi đang sử dụng Ruby 1.9.3 – randombits

+4

Cấu hình mã của bạn (ruby-prof) tìm hiểu lý do tại sao nó chậm, cố gắng viết lại nút cổ chai. Lặp lại cho đến khi đủ nhanh. Với 0 thông tin chúng tôi không thể đoán tại sao mã của bạn không nhanh hơn –

Trả lời

1

Trước hết, bạn có thể không muốn các phiên bản ở mức 45-60% cpu. Trong trường hợp đó, nếu bạn nhận được tăng đột biến lưu lượng truy cập, tất cả các trường hợp của bạn sẽ bị sặc.

Tiếp theo, 14 trường hợp Unicorn có vẻ lớn. Unicorn không sử dụng luồng. Thay vào đó, mỗi tiến trình chạy với một luồng đơn. Quá trình tổng thể của Unicorn sẽ chỉ select một chuỗi nếu nó có thể xử lý nó. Bởi vì điều này, số lượng lõi không phải là số liệu bạn nên sử dụng để đo lường hiệu suất với Unicorn.

Một thiết lập bảo thủ hơn có thể sử dụng 4 hoặc quá trình Unicorn cho mỗi trường hợp, đáp ứng 5-8 yêu cầu mỗi giây. Sau đó, điều chỉnh số lượng các trường hợp cho đến khi CPU của bạn sử dụng là khoảng 35%. Điều này sẽ đảm bảo sự ổn định theo yêu cầu '20 yêu cầu mỗi giây 'căng thẳng'.

Cuối cùng, bạn có thể nhận được nhiều số liệu và thống kê chi tiết hơn bằng cách sử dụng God.

+2

1) OP cho biết đây là trong quá trình kiểm tra tải, do đó, * này * là tăng đột biến lưu lượng truy cập. 2) Những gì không có quá trình luồng phải làm với số lượng lõi? –

6

Nếu bạn là CPU bị ràng buộc bạn muốn sử dụng không có quá trình kỳ lạ hơn bạn có lõi, nếu không bạn quá tải hệ thống và làm chậm lịch trình. Bạn có thể kiểm tra điều này trên một hộp dev bằng cách sử dụng ab. Bạn sẽ nhận thấy rằng 2 kỳ lân sẽ tốt hơn 20 (số phụ thuộc vào lõi, nhưng khái niệm sẽ giữ đúng).

Ngoại lệ đối với quy tắc này là nếu IO của bạn bị ràng buộc. Trong trường hợp này, hãy thêm nhiều kỳ lân như bộ nhớ có thể giữ.

Bí quyết hiệu suất tốt là định tuyến các yêu cầu liên kết IO đến một máy chủ ứng dụng khác nhau lưu trữ nhiều kỳ lân. Ví dụ: nếu bạn có yêu cầu sử dụng truy vấn sql chậm hoặc bạn đang chờ yêu cầu bên ngoài, chẳng hạn như giao dịch thẻ tín dụng. Nếu sử dụng nginx, hãy xác định một máy chủ ngược dòng cho các yêu cầu liên kết IO, chuyển tiếp các url đó đến một hộp có 40 kỳ lân. CPU ràng buộc hoặc yêu cầu thực sự nhanh chóng, chuyển tiếp đến một hộp với 8 kỳ lân (bạn nói bạn có 8 lõi, nhưng trên aws bạn có thể muốn thử 4-6 như schedulers của họ được hypervised và đã rất bận rộn).

Ngoài ra, tôi không chắc chắn bạn có thể tin tưởng vào aws cho bạn sử dụng CPU đáng tin cậy, như bạn nhận được một tỷ lệ phần trăm của một tỷ lệ phần trăm tối nghĩa.

1

Đối với trường hợp lớn hơn CPU cao, 20 yêu cầu mỗi giây là rất thấp. Có thể có vấn đề với mã. Một vấn đề kỳ lân cụ thể dường như ít có khả năng xảy ra. Nếu bạn đang nghi ngờ, bạn có thể thử một máy chủ ứng dụng khác và xác nhận nó vẫn xảy ra.

Trong kịch bản này, câu hỏi tôi muốn được suy nghĩ về ...

1 - Bạn đang làm một cái gì đó CPU chuyên sâu trong mã - có lẽ cái gì đó thực sự phải ở trong cơ sở dữ liệu. Ví dụ, nếu bạn đang mang lại một recordset lớn và lặp qua nó trong ruby ​​/ rails để sắp xếp nó hoặc thực hiện một số hoạt động khác, điều đó sẽ giải thích một nút cổ chai CPU ở mức này trái ngược với bên trong cơ sở dữ liệu. Các khuyến nghị trong trường hợp này là để revamp truy vấn để làm nhiều hơn và lấy gánh nặng ra khỏi đường ray.Ví dụ, nếu bạn đang sắp xếp tập hợp kết quả trong bộ điều khiển của bạn, thay vì thông qua sql, điều đó sẽ gây ra một vấn đề như thế này.

2 - Bạn có đang làm bất kỳ điều gì khác thường so với ứng dụng vani vani, như truy cập tài nguyên được chia sẻ hay bất kỳ điều gì tranh chấp có thể là vấn đề không?

3 - Bạn có bất kỳ vòng lặp nào có thể đốt cháy CPU, đặc biệt nếu có tranh chấp cho tài nguyên?

4 - Thử bỏ các phần khác nhau của logic bộ điều khiển được đề cập. Ví dụ, quy mô của nó sẽ tốt như thế nào nếu bạn hack mã của mình để trả về một phản hồi thế giới chào hỏi tĩnh thay thế? Tôi đặt cược đột nhiên kỳ lân sẽ được nhanh chóng blazlingly. Sau đó, thử thêm lại vào các phần của mã của bạn cho đến khi bạn phát hiện ra nguồn của sự chậm chạp.

Các vấn đề liên quan