Chúng tôi thường nhận được câu hỏi về việc tối ưu hóa hoặc giám sát Sidekiq. Theo dõi là một trò chơi của chúng tôi, nhưng tối ưu hóa hiệu suất của Sidekiq hoàn toàn là một trò chơi bóng khác. Trên thực tế, việc tối ưu hóa rất phức tạp, nhưng hãy bắt đầu bằng cách xem xét các câu trả lời có vẻ đơn giản ...
Hai cách tăng tốc độ
Để bắt đầu, tốc độ có thể được tăng lên theo hai cách - bằng cách thực hiện các công việc lớn hơn (có thể chiếm nhiều bộ nhớ hơn hoặc IO hoặc phức tạp hơn), hoặc bằng cách điều chỉnh cài đặt đồng thời hoặc công nhân (sẽ sử dụng nhiều CPU hơn và có thể là IO). Ouch, thực tế đang bắt đầu:tốc độ đi kèm với cái giá phải trả. Nếu bạn có thể dành thêm bộ nhớ, IO hoặc CPU thì điều này là miễn phí, nhưng chúng tôi nghĩ rằng điều quan trọng là phải nhận ra những đánh đổi có thể cần phải thực hiện.
Tăng tốc độ thông qua cài đặt đồng thời
Sidekiq xử lý đồng thời bằng cách sử dụng nhiều luồng trong quy trình của nó. Bằng cách này, nó có thể xử lý nhiều công việc cùng một lúc, mỗi luồng xử lý một công việc tại một thời điểm. Theo mặc định, Sidekiq sử dụng 10 luồng cho mỗi quy trình. Bạn có thể định cấu hình nó để sử dụng nhiều luồng hơn, do đó tăng tính đồng thời.
Xin lưu ý rằng mô hình đồng thời mới cần được ứng dụng của bạn hỗ trợ. Ví dụ:nó cần một nhóm đủ lớn các kết nối đến cơ sở dữ liệu và máy chủ của bạn cần có khả năng xử lý sự gia tăng các hoạt động I / O. Bạn có thể xem tài liệu Sidekiq về đồng thời để biết thêm thông tin.
Tăng tốc độ bằng cách chạy nhiều nhân viên
Bên cạnh việc tạo ra nhiều quy trình, bạn cũng có thể chạy nhiều công nhân. Bằng cách này, bạn có thể mở rộng quy mô bất kỳ bộ phận nào sử dụng nhiều CPU, chạy mọi thứ song song khi chúng nằm trong cách của nhau trên CPU nếu chúng chạy trong một quy trình. Trước đây, chúng tôi đã viết về đồng thời trong Ruby và Khóa thông dịch viên toàn cầu trong bài viết này nếu bạn muốn nắm bắt điều đó.
Nó hoạt động hay nó hỏng? Những gì cần theo dõi và Bảng điều khiển kỳ diệu của chúng tôi
Việc thay đổi các thông số mặc định có thể ảnh hưởng đến hiệu suất ứng dụng của bạn. Trước khi thay đổi cài đặt, bạn nên thiết lập theo dõi để xem liệu những thay đổi có tạo ra tác động tích cực hay chúng làm giảm hiệu suất.
Hãy bắt đầu bằng cách kiểm tra xem chúng ta có đang phá vỡ mọi thứ ở cấp độ máy chủ hay không. Bạn sẽ muốn xem ứng dụng của mình sử dụng nhiều tài nguyên như thế nào trên phần cứng bạn đang chạy. Nếu bạn còn dung lượng trong bộ nhớ và CPU, bạn có thể tăng cài đặt đồng thời để làm cho mọi thứ nhanh hơn một chút.
Bất kể APM (Giám sát hiệu suất ứng dụng) bạn sử dụng là gì, nó có thể có một cách để theo dõi số liệu máy chủ lưu trữ. Nếu bạn sử dụng AppSignal, trang tổng quan cho máy chủ của bạn sẽ tự động được tạo. Để đảm bảo rằng bạn nhận được thông báo trước khi mọi thứ thực sự chạy amok, bạn có thể dễ dàng thiết lập cảnh báo về việc sử dụng CPU trên các máy chủ cụ thể bằng tính năng Phát hiện bất thường.
Bây giờ, hãy xem liệu mọi thứ có không phá vỡ ở cấp độ Sidekiq hay không. APM mà bạn lựa chọn có thể sẽ cho phép bạn thiết lập giám sát và cảnh báo cho các công việc nền của bạn theo một số cách thủ công. Trên AppSignal, điều này rất dễ dàng:chúng tôi theo dõi điều này cho bạn trong bảng điều khiển ma thuật Sidekiq (được tạo mà không cần bất kỳ thiết lập nào từ phía bạn, khi bạn chạy phiên bản gần đây của đá quý của chúng tôi).
Trong thiết lập này, bạn sẽ muốn theo dõi trạng thái công việc trên mỗi hàng đợi và đặt kích hoạt để cảnh báo tỷ lệ thất bại trên Slack, PagerDuty, email hoặc bất cứ thứ gì bạn sử dụng.
Việc làm ít hơn, nhiều hơn?
Chúng tôi đã xem xét nhanh việc tăng tốc độ trong khi kinh doanh CPU. Bây giờ, hãy xem xét việc tăng tốc độ trong khi giao dịch trên bộ nhớ hoặc IO, hoặc phức tạp hơn. Bạn sẽ nghĩ rằng bạn có thể làm được điều đó bằng cách tạo ra những công việc lớn hơn. Ý tưởng là các công việc lớn có thể nhanh hơn vì chúng không có chi phí Sidekiq cho mỗi hoạt động. Tuy nhiên, theo kinh nghiệm của chúng tôi, chi phí Sidekiq hiếm khi giết chết hiệu suất của bạn. Thông thường, các truy vấn cơ sở dữ liệu mà công việc thực hiện có thể giết chết hiệu suất. Chúng tôi thấy rằng việc kết hợp nhiều công việc hơn, để thực hiện ít truy vấn hơn là một cách quan trọng để có hiệu suất tốt hơn. Đơn giản hóa:thực hiện một lần cập nhật 1000 bản ghi thay vì 1000 lần cập nhật 1 bản ghi.
Cần theo dõi những gì để xem nó hoạt động hay hỏng?
Trước tiên, bạn sẽ muốn theo dõi trạng thái công việc mỗi hàng đợi ở đây cũng như đặt kích hoạt cho tỷ lệ thất bại . Vì công việc mất nhiều thời gian hơn và có nhiều thao tác hơn, bạn cũng sẽ muốn theo dõi việc sử dụng bộ nhớ của Sidekiq . Bạn cũng nên thiết lập cảnh báo về Sử dụng bộ nhớ Sidekiq , nhưng cụ thể là đối với máy chủ sắp hết bộ nhớ bằng cách sử dụng tính năng phát hiện Điểm bất thường của AppSignal.
Bạn cũng nên theo dõi độ dài hàng đợi mỗi hàng đợi. Điều này sẽ cảnh báo cho bạn khi có một công việc tồn đọng đang hình thành — khi công nhân đã xếp hàng nhiều hơn mức họ có thể xử lý. Chúng tôi khuyên bạn nên thiết lập trình kích hoạt Phát hiện bất thường cho hàng đợi công việc 'quan trọng' của mình.
Sự đánh đổi bạn sẽ không thấy trong APM của mình
Vấn đề lớn với các công việc lớn hơn là chúng khó viết mã hơn. Bạn sẽ phải thực hiện các công việc riêng lẻ một cách rõ ràng và theo dõi trạng thái của chúng. Trong một ví dụ đơn giản:khi bạn có một công việc gửi thư cho một người và nó không thành công, bạn có thể thử lại mà không gây hại nhiều. Khi gửi thư cho 1000 người, nếu công việc không thành công, bạn không muốn gửi lại cho 240 người mà bạn đã gửi thư trước khi công việc không thành công. Đảm bảo rằng điều đó không xảy ra làm cho mã phức tạp hơn.
Sự phức tạp thực sự của thực tế
Thời gian để kiểm tra thực tế khác. Thông thường, các quy trình nền của bạn có thể không bị chậm do có bất kỳ thứ gì đang chạy trong Sidekiq. Có thể cơ sở dữ liệu bạn đang truy vấn chậm vì máy chủ mà nó chạy sắp hết bộ nhớ. Khi tìm kiếm một ví dụ thú vị để sử dụng trong bài đăng này, chúng tôi đã gặp phải một trường hợp như vậy:hóa ra thời lượng đang đạt đỉnh vì API bên ngoài có thời gian phản hồi lâu. Không có gì trong Sidekiq sẽ giải quyết được điều đó.
Vì vấn đề có thể được nhìn thấy ở một nơi nhưng hoàn toàn có thể gây ra ở nơi khác, tại AppSignal, chúng tôi đã xây dựng sản phẩm để sản phẩm có lỗi, hiệu suất và các chỉ số máy chủ tất cả trong một. Các chỉ số kết hợp của chế độ xem này sẽ giúp bạn dễ dàng tìm ra nguyên nhân gốc rễ của vấn đề hơn.
Không có câu trả lời dễ dàng nào, có không?
Mặc dù chúng tôi bắt đầu bài viết này với những kiến thức cơ bản về giám sát và tối ưu hóa Sidekiq, nhưng chúng tôi ngay lập tức nhận ra rằng tốc độ sẽ tiêu tốn CPU và IO. Hoặc Bộ nhớ. Hoặc giới thiệu phức tạp hơn. Và mặc dù chúng tôi đã đề cập đến một số mức độ phức tạp của hiệu suất trong kiến trúc của bạn, nhưng thực tế là chúng tôi đã giải quyết được 99% những điều khó khăn trong bài đăng này.
Vì vậy, mặc dù chúng tôi có thể đã làm mất đi hy vọng của bạn về những câu trả lời đơn giản, nhưng chúng tôi hy vọng bài viết này sẽ gợi lên một số suy nghĩ thú vị về việc tối ưu hóa và giám sát thiết lập Sidekiq của bạn!