2010-02-04 10 views
26

Tôi đã làm việc để triển khai một ứng dụng Rails tương đối lớn (Rails 2.3.5) và gần đây thực hiện một số thử nghiệm tải chúng tôi phát hiện ra rằng thông lượng cho trang web là dưới mức dự kiến ​​của lưu lượng truy cập.Hành khách lưu trữ ứng dụng Rails * đau đớn * chậm, nhưng máy chủ là một con thú

Chúng tôi đang chạy trên một máy chủ 32 bit chuẩn, 3GB RAM với Centos và chúng tôi đang chạy phiên bản Ruby Enterprise Edition (Phiên bản mới nhất), Hành khách (Xây dựng mới nhất) và Nginx (Bản dựng mới nhất) - khi chỉ có một hoặc hai người dùng trang web chạy tốt (như bạn mong đợi) tuy nhiên khi chúng tôi cố gắng tăng tốc tải lên ~ 50 yêu cầu đồng thời, nó hoàn toàn bị chết. (Báo cáo băng ghế dự bị Apache ~ 2,3 req/giây, là khủng khiếp)

Chúng tôi đang chạy RPM và cố gắng xác định vấn đề tải, nhưng nó được phân phối khá đều trên Rails, SQL và Memcached, vì vậy chúng tôi ít nhiều đi qua và tối ưu hóa codebase.

Hết sức tuyệt vọng, chúng tôi tách một phiên bản EC2 lớn (Ubuntu 9.10, 7.5GB RAM, 2 Đơn vị tính/Lõi) và thiết lập cùng cấu hình với máy chủ gốc, và trong khi có nhiều tài nguyên hơn, chúng tôi vẫn thấy thảm hại các kết quả. Vì vậy, sau khi dành quá nhiều thời gian cố gắng để tối ưu hóa, chơi với cấu hình bộ nhớ đệm, vv Tôi quyết định kiểm tra thông lượng của một số mongrels, và ta-da, họ đang thực hiện tốt hơn nhiều sau đó Passenger.

Hiện tại cấu hình là Mongxels 15x được proxy thông qua Nginx, và dường như đáp ứng yêu cầu tải của chúng tôi chỉ nhưng không đủ để làm cho tôi cảm thấy thoải mái khi phát trực tiếp ... của một số nguyên nhân có thể cho điều này ...?

cấu hình của tôi cho hành khách/nginx là:

  • nhân Nginx: cố gắng từ 1 đến 10, thường là ba mặc dù.
  • Kích thước hồ bơi tối đa của hành khách: 10 - 30 (có, những con số này khá cao)
  • Hàng đợi toàn cầu của hành khách: thử cả hai tắt và bật.
  • nginx GZip trên: yes

Nó có thể trả tiền để lưu ý rằng chúng tôi đã tăng kích thước cơ thể khách hàng nginx max đến 200m để cho phép upload file lớn.

Bất kỳ đề nghị nào cũng sẽ là thực sự được đánh giá cao, trong khi mongrels làm việc tốt, nó thay đổi cách chúng tôi làm việc rất nhiều và tôi thực sự thích sử dụng Hành khách - ngoài ra, nó không phải là dễ dàng hơn ?

+4

Chỉ cần fyi đây là giải thích: Sự khác biệt là mongrels đẻ trứng trường hợp tách của ứng dụng của bạn để mỗi ứng dụng có hồ bơi sql riêng của mình trong khi hành khách dồn các phiên bản mới ra khỏi một người khởi tạo ứng dụng được khởi tạo trước duy nhất (nhanh hơn nhiều) để chia sẻ hồ bơi sql của bạn. – hurikhan77

+0

Cảm ơn lời giải thích - khi chúng tôi thử nghiệm những thay đổi đối với hồ bơi (vâng, một khi tôi đọc gợi ý) nó trở nên rất rõ ràng đối với tôi - như những người khôn ngoan thường nói, đôi khi bạn chỉ cần một đôi mắt khác;) –

+0

Bạn có thể muốn sửa đổi tiêu đề của bạn vì điều này được giải quyết là không liên quan đến nginx. Nó sẽ xảy ra trên mọi triển khai hành khách nếu bạn đặt kích thước bể bơi sql quá nhỏ. – hurikhan77

Trả lời

17

Có thể kích thước bể bơi sql của bạn quá nhỏ? Điều này về cơ bản giới hạn tính song song của khối lượng công việc cơ sở dữ liệu trong ứng dụng của bạn mà lần lượt xây dựng lên đến tải tăng nhiều ngay sau khi bạn đặt công việc trên ngăn xếp ứng dụng của bạn ...

+0

Chà, tôi không thể tin rằng tôi không nghĩ về điều này - chúng tôi đã nâng cấp hồ bơi lên một con số cao hơn (có điều gì quá 'cao?' Là 50 quá cao?) Và sự khác biệt là * tuyệt vời *. Cảm ơn rất nhiều vì gợi ý của bạn –

+0

Bạn sẽ không cần nhiều hơn kích thước hồ bơi chở khách của bạn ... Có thể cung cấp thêm bộ đệm 4 hoặc 5. – hurikhan77

+0

@ hurikhan77 - bất kỳ đề xuất nào về kích thước hồ bơi chở khách? Tôi đoán 'nó phụ thuộc vào trang web, máy chủ và nhu cầu ...'? ;) –

2

Là bước đầu tiên, tôi sẽ triển khai ứng dụng Rails "Hello World" tối thiểu cho môi trường của bạn và xem thông lượng bạn nhận được với điều đó. Làm như vậy ít nhất sẽ cho bạn biết nếu vấn đề của bạn là với môi trường hoặc một nơi nào đó trong ứng dụng của bạn.