Làm cách nào để cải thiện hiệu suất của Moose trong các quy trình CGI không liên tục?

Question

Moose là một khung đối tượng tuyệt vời. Vấn đề là, cùng với sự phụ thuộc của nó, nó là rất lớn. Hồ sơ của chúng tôi cho thấy rằng trên nền tảng của chúng tôi, chỉ cần tải Moose sẽ phải chịu phí cao hơn 5-6 giây đối với các tập lệnh ứng dụng CGI không liên tục. Điều đó không thể chấp nhận được đối với những ứng dụng một lần này.

Ngược lại, khi chúng tôi đang sử dụng hệ thống xử lý liên tục (như FCGI), chi phí khởi động này bị loại bỏ (hoặc đúng hơn, chỉ phát sinh một lần) và tất cả đều tốt. Vấn đề chúng tôi có là chúng tôi không thể đảm bảo rằng tất cả mã của chúng tôi sẽ luôn chạy theo một quy trình liên tục.

Chúng tôi đã điều tra bằng cách sử dụng Mouse làm tính năng thay thế giới hạn cho Moose, nhưng hóa ra (như được đề cập trong this answer) không phải là lựa chọn khả thi. Bất kỳ thư viện nào chúng tôi viết để làm việc với Moose sẽ không hoạt động với Chuột theo những cách tinh tế nhưng quan trọng. Và chúng tôi thực sự không muốn chia tất cả các mô-đun của mình để chúng tôi có thể hỗ trợ cả Moose trong môi trường liên tục và Chuột cho "vanilla" CGI.

Cho rằng, chúng tôi có các tùy chọn sau:

1. Fork trong nhà của chúng tôi module để làm việc với một trong hai Moose hoặc chuột, khi thích hợp. (Yuck!)
2. Chỉ phát triển các mô-đun của chúng tôi cho FCGI/Moose. Không hỗ trợ "vanilla" CGI nữa. Nếu chúng ta phải viết các tập lệnh không liên tục, chúng sẽ không thể tận dụng các mô-đun trong nhà của chúng ta.
3. Không sử dụng Moose hoặc Chuột, nhưng một số khung đối tượng khác.

Tùy chọn nào là tốt nhất? Chúng tôi đang nghiêng về phía 2 ngay bây giờ, và chúng tôi sẽ chỉ hút nó lên nếu chúng ta có để có được một cái gì đó chạy như một vanilla CGI. Làm thế nào về các khuôn khổ khác? Có điều gì nhẹ hơn chúng ta nên xem xét không?

Answer 1

Sở thích của tôi là giảm hỗ trợ vanilla CGI. FCGI lưu trữ thực sự là giá rẻ những ngày này và không có lý do để đi lang thang để vanilla CGI (IMO) bởi vì nó chỉ củng cố ý kiến ​​rằng Perl là chậm. Nhưng nếu bạn không thể tránh nó thì bạn có thể sử dụng một cái gì đó như Object::Tiny. Nhưng nếu bạn cần Vai trò, các ràng buộc, lập trình meta và tất cả những vẻ đẹp khác mà Moose cung cấp, bạn sẽ không may mắn trừ khi bạn thả vanilla CGI.

Answer 2

Ngoài ra còn có một tùy chọn khác - PPerl.

Tôi chưa bao giờ sử dụng nó, nhưng nó chắc chắn có vẻ thú vị. Và người đã viết nó (Matt Sergeant aka baud) - nó mang lại cho bạn thực tế đảm bảo mã chất lượng tốt.

Answer 3

Bạn có thể viết ứng dụng máy chủ kết thúc bằng Moose, sau đó viết các script CGI rất nhỏ, đơn giản truy vấn phần cuối.

+-------+ +--------------+ 
| Small |===>| Persistent | 
| CGI |<===| Moose Server | 
+-------+^+--------------+ 
      | 
     Socket 
     Connection 

Đây là điều ít nhiều FCGI thực hiện, vì vậy có thể có ý nghĩa hơn khi sử dụng FCGI.

Mặt khác, có thể có lợi ích thực sự khi có máy chủ kết thúc không phải cgi có thể có bất kỳ giao diện trừu tượng nào được bật khi cần.

Ví dụ: nếu bạn sử dụng ổ cắm TCP (hoặc UDP), thì bạn có thể có ứng dụng máy tính để bàn gốc nhấn cùng một đầu cuối với CGI của bạn.

Điều gì phù hợp nhất trong trường hợp của bạn thực sự phụ thuộc vào tình huống cụ thể của bạn. Tùy thuộc vào các chi tiết của tình huống, tôi có thể thấy bản thân mình quyết định sử dụng phương pháp này hoặc bất kỳ phương pháp nào bạn phác thảo ở trên.

Answer 4

Đề xuất của tôi là đi với tùy chọn # 2 và sau đó giúp chúng tôi refactor Moose để CGI trở nên khả thi. fREW hiện đang làm việc trên bộ kiểm tra Moose để kích hoạt dự án MooseX :: Antlers mà nên giảm hầu hết các chi phí trên có nghĩa là Moose không sử dụng được cho môi trường CGI.

Matt Trout (mst), người đàn ông hiện đang đứng sau MooseX :: Antlers, đã bày tỏ mong muốn có thể chạy các ứng dụng trong môi trường CGI nếu cần thiết. Tôi muốn đề nghị gắn bó với FCGI bây giờ và pester anh ta cho những gì bạn có thể làm để giúp đỡ!

Answer 5

Jonathan Rockway đã viết về APP::Peristent (trong đó, kỳ quặc, không có trong CPAN) cách đây vài tháng. Tôi đã không sử dụng nó, nhưng dựa trên bài đăng trên blog được liên kết ở trên của mình, có vẻ như cung cấp một kiến ​​trúc máy chủ-khách hàng khá minh bạch để bạn có thể bao bọc việc xử lý thực tế của CGI của bạn.

Answer 6

Ý tưởng cơ bản của App::Persistent, pperl, SpeedyCGI và có lẽ một số khác là quá trình biên dịch chương trình Perl của bạn thành mã byte chỉ được thực hiện một lần và một số loại bộ nhớ đệm được sử dụng trên các lời gọi sau đó. Kể từ khi Moose được cho là đã có một hình phạt khá biên dịch, tôi sẽ thử phương pháp này trước.

Tôi đã sử dụng thành công pperl để vẽ rất nhiều biểu đồ MRTG trên một hệ thống cổ xưa vào khoảng năm 2001. Chương trình Perl được thực hiện cho mọi đồ thị vốn khá là chi phí - điều này có thể so sánh với kịch bản CGI của bạn.