2016-03-19 27 views
8

Chúng tôi đang sử dụng cần tây để thực hiện cuộc gọi http của bên thứ ba. Chúng tôi có khoảng 100 nhiệm vụ chỉ đơn giản là gọi các cuộc gọi API HTTP của bên thứ ba. Một số nhiệm vụ gọi số lượng lớn của API, ví dụ: nửa triệu yêu cầu lúc 4 giờ sáng vào buổi sáng, trong khi một số là các luồng API liên tục nhận được yêu cầu gần như một lần hoặc hai lần mỗi giây.Tối ưu hóa cần tây cho các cuộc gọi HTTP của bên thứ ba

Hầu hết thời gian phản hồi cuộc gọi API là từ 500 - 800 ms.

Chúng tôi thấy tỷ lệ phân phối rất chậm với cần tây. Đối với hầu hết các tác vụ trên, tốc độ phân phối tối đa là khoảng 100/s (tối đa) đến gần 1/s (phút). Tôi tin rằng điều này là rất nghèo và một cái gì đó chắc chắn là sai, nhưng tôi không thể tìm ra nó là gì.

Chúng tôi bắt đầu với cụm 3 máy chủ và từng bước biến nó thành một cụm gồm 7 máy chủ, nhưng không có cải tiến. Chúng tôi đã thử với các cài đặt đồng thời khác nhau từ autoscale đến cố định 10, 20, 50, 100 công nhân. Không có kết quả phụ trợ và nhà môi giới của chúng tôi là RabbitMQ.

Vì thời gian thực hiện nhiệm vụ của chúng tôi là rất nhỏ, ít hơn một giây cho hầu hết, chúng tôi cũng đã cố gắng làm cho số lượng tìm nạp không giới hạn các giá trị khác nhau.

--time-limit=1800 --maxtasksperchild=1000 -Ofair -c 64 --config=celeryconfig_production

Máy chủ là 64 G RAM, Centos 6.6.

Bạn có thể cho tôi ý tưởng về những gì có thể sai hoặc gợi ý về cách giải quyết nó?

Chúng ta có nên đi với gevents không? Mặc dù tôi có ít ý tưởng về nó là gì.

+0

Hàng đợi của bạn đã đầy trong RabbitMQ như thế nào? RabbitMQ nhanh nhất khi hàng đợi trống. Bạn có thể giám sát việc sử dụng CPU của máy RabbitMQ. Nếu bạn thấy sử dụng CPU nặng, có lẽ, đó là bởi vì RabbitMQ đang làm rất nhiều để đối phó với kích thước hàng đợi lớn. – LearnerEarner

+1

Có thể âm thanh ngớ ngẩn và chắc chắn bạn đã chú ý đến điều này nhưng bạn đã kiểm tra xem máy chủ của bên thứ ba có hoạt động tốt dưới tải không? Nó vẫn đáp ứng trong 500-800ms ngay cả khi bạn nhấn nó với nhiều yêu cầu đồng thời? – LearnerEarner

+0

http://www.rabbitmq.com/blog/2012/05/11/some-queuing-theory-throughput-latency-and-bandwidth/ – LearnerEarner

Trả lời

5

Trước hết - GIL - điều đó không phải là một trường hợp, vì nhiều máy nên đi nhanh hơn. Nhưng - vui lòng kiểm tra xem tải có chỉ đi trên một lõi của máy chủ hay không ...

Tôi không chắc chắn liệu toàn bộ cần tây là ý tưởng hay trong trường hợp của bạn hay không. Đó là phần mềm tuyệt vời, với rất nhiều chức năng. Tuy nhiên, nếu điều đó là không cần thiết, tốt hơn là sử dụng một cái gì đó đơn giản hơn - chỉ trong trường hợp một số tính năng đó can thiệp. Tôi sẽ viết PoC nhỏ, kiểm tra phần mềm máy khách khác, như pika. Nếu điều đó không giúp được gì - vấn đề là với cơ sở hạ tầng. Nếu giúp - bạn có giải pháp. :)

Thật khó để biết điều gì đang diễn ra. Nó có thể là một cái gì đó với IO, hoặc quá nhiều cuộc gọi mạng ... Tôi sẽ bước trở lại - để tìm ra một cái gì đó làm việc. Viết các bài kiểm tra tích hợp, nhưng hãy chắc chắn sử dụng 2-3 máy chỉ để sử dụng toàn bộ stack tcp. Hãy chắc chắn để có CI, và chạy thử nghiệm đó một lần một ngày, hoặc như vậy - để xem nếu mọi thứ đang đi đúng hướng.

+0

Cũng trong một số trường hợp cụ thể, GIL không phát hành sau 100ms –

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