Làm cách nào để tăng tốc hoạt động Batch API?

Tôi đã gặp phải vấn đề này với các mô-đun đóng góp của bên thứ 3 cũng như một số hoạt động của riêng tôi. Tôi tò mò về các cách khác nhau để tăng tốc các hoạt động hàng loạt / đóng góp của mình ?

Giả sử họ làm việc với các nút (nhập / cập nhật, v.v.) và chúng tôi đang xử lý phân tích danh sách các nút trong phạm vi 10.000+ (mặc dù tôi đã phải xử lý 15 triệu hàng .. điều đó đúng - tôi chỉ bị lừa. .)

Có nhanh hơn để gắn vào công việc drupals cron.php và chạy "không đầu"? Sử dụng Drush? hoặc đây chỉ đơn giản là một câu hỏi về cách phân tích nhanh và hiệu quả mà tôi có thể phát triển mã của mình và không có ảnh hưởng bên ngoài hoặc các mẹo tối ưu hóa cụ thể hàng loạt ...

Hiện tại tôi đã chạy vào các hoạt động (sử dụng một số tính toán sơ bộ) có thể mất hơn 24 giờ ...

Cảm ơn!

Điều này không hoạt động đối với mã đóng góp, nhưng nếu đó là mã của bạn và bạn biết rõ về nó, tôi khuyên bạn nên viết một lệnh drush để thực hiện công việc. Trong drush, giới hạn drupal_bootstrap () ở mức bootstrap thích hợp. Tôi không thể nhớ lại các con số thực tế, nhưng một tỷ lệ rất lớn thời gian cho mỗi yêu cầu drupal được dành cho bootstrap và bạn có thể tiết kiệm rất nhiều thời gian ở đó.

Hơn nữa, hãy kiểm tra can đảm của mô-đun Di chuyển. Tôi không biết làm thế nào nó làm mojo (không bao giờ mất thời gian để mò mẫm nó), nhưng nó có thể thổi qua các lô nút rất lớn rất nhanh.

Mỗi cuộc gọi hàng loạt là một yêu cầu HTTP. Vì vậy, bạn cần tìm ra sự pha trộn hoàn hảo của số lần lặp bạn có thể xử lý trước khi yêu cầu HTTP khác được thực hiện. Hai điều cần xem xét là bộ nhớ và thời gian thực hiện tối đa. Bạn sẽ muốn xử lý càng nhiều lần lặp càng tốt mỗi đợt để giảm số lượng yêu cầu HTTP vì rất có thể chúng là thủ phạm gây ra đợt chậm của bạn.

Nếu lô của bạn quá nặng để chạy hiệu quả, bạn có thể thử sử dụng hàng đợi thay thế. Có một đợt tốt so với trình bày hàng đợi ở đây http://sf2010.drupal.org/conference/simes/batch-vs-queue-api-smackdown . Hàng đợi không cung cấp phản hồi của người dùng và có thể được chạy song song.

Nếu bạn yêu cầu phản hồi của người dùng, bạn được gắn với lô, nhưng bạn thậm chí có thể sử dụng hàng đợi trong lô của mình để cố gắng tối ưu hóa nó.

Như những người khác đã nói Drush là một giải pháp tốt, nhưng hàng đợi là một công cụ tuyệt vời để sử dụng. API hàng loạt trong Drupal 7 sử dụng API hàng đợi lõi tích hợp để nếu bạn đang sử dụng MySQL, quy trình của bạn có thể bị tắc nghẽn ở đó. Nhưng, API hàng đợi của Drupal 7 có thể cắm được, vì vậy bạn có thể sử dụng một hệ thống xếp hàng khác như beanstalkd.

Nếu bạn có thể làm cho nó song song đó là một khởi đầu tốt. Dưới đây là một số suy nghĩ của tôi về điều này khi tôi đã sử dụng 4 luồng để thu thập dữ liệu trên một triệu trang trước đó (thông qua boost). Tìm cách để làm cho nó khái quát bây giờ. http://groups.drupal.org/node/126624