كيف يمكنني تحسين أداء Moose في عمليات CGI غير المستمرة؟

Question

غزال أمريكي ضخم هو إطار كائن رائع.المشكلة هي أنه إذا أخذنا مع تبعياته، فهو كذلك جداً كبير.تشير ملفات التعريف الخاصة بنا إلى أنه على منصتنا، فإن مجرد تحميل Moose سيتحمل عبءًا إضافيًا يتراوح من 5 إلى 6 ثوانٍ على نصوص تطبيقات CGI غير المستمرة.هذا غير مقبول لهذه التطبيقات لمرة واحدة.

على النقيض من ذلك، عندما نستخدم نظام معالجة مستمر (مثل FCGI)، يتم التخلص من عبء بدء التشغيل هذا (أو بالأحرى، يتم تكبده مرة واحدة فقط)، ويصبح كل شيء على ما يرام.المشكلة التي نواجهها هي أننا لا نستطيع ضمان تشغيل كافة التعليمات البرمجية الخاصة بنا دائمًا في إطار عملية مستمرة.

لقد بحثنا باستخدام الفأر كبديل محدود الميزات لـ Moose، ولكن كما اتضح (كما هو مذكور في هذه الإجابة) هذا ليس خيارًا قابلاً للتطبيق.أي مكتبات نكتبها للعمل مع Moose ستفشل في العمل مع Mouse بطرق دقيقة ولكنها مهمة.و نحن حقًا لا نريد تفرع جميع وحداتنا حتى نتمكن من دعم كل من Moose في بيئة مستمرة والماوس لـ "vanilla" CGI.

وبناء على ذلك، لدينا الخيارات التالية:

1. شوكة وحداتنا الداخلية للعمل مع Moose أو Mouse، حسب الاقتضاء.(ياك!)
2. فقط قم بتطوير وحداتنا الخاصة بـ FCGI/Moose.لا تدعم CGI "الفانيليا" بعد الآن.إذا كان علينا كتابة نصوص برمجية غير مستمرة، فلن تتمكن من الاستفادة من وحداتنا الداخلية.
3. لا تستخدم أي موس أو ماوس, ، ولكن بعض إطار الكائن الآخر.

ما هو الخيار الأفضل؟نحن نميل نحو الرقم 2 في الوقت الحالي، وسنمتصه إذا أردنا تشغيل شيء ما باعتباره صورة الفانيليا المولدة بواسطة الكمبيوتر.ماذا عن الأطر الأخرى؟هل هناك أي شيء أكثر خفة الوزن يجب أن ننظر إليه؟

Answer 1

أفضلي هو إسقاط دعم الفانيليا CGI.تعد استضافة FCGI رخيصة جدًا هذه الأيام ولا يوجد سبب للخضوع لـ Vanilla CGI (IMO) لأنها تعزز الرأي القائل بأن Perl بطيء.ولكن إذا لم تتمكن من تجنب ذلك، فيمكنك استخدام شيء مثل الكائن::صغير.ولكن إذا كنت بحاجة إلى الأدوار والقيود والبرمجة الوصفية وكل الأشياء الرائعة الأخرى التي يوفرها Moose، فلن يحالفك الحظ إلا إذا قمت بإسقاط الفانيليا CGI.

Answer 2

يمكنك كتابة تطبيق خادم خلفي باستخدام Moose، ثم كتابة نصوص CGI صغيرة جدًا وبسيطة تستعلم عن النهاية الخلفية.

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

هذا هو ما تفعله FCGI بشكل أو بآخر، لذلك قد يكون من المنطقي استخدام FCGI فقط.

من ناحية أخرى، قد تكون هناك فوائد حقيقية في وجود خادم خلفي غير تابع لـ cgi يمكنه تثبيت أي واجهة مجردة حسب الحاجة.

على سبيل المثال، إذا كنت تستخدم مقابس TCP (أو UDP)، فمن الممكن أن يكون لديك تطبيق سطح مكتب أصلي يصل إلى نفس الواجهة الخلفية مثل CGI الخاص بك.

ما هو الأفضل في حالتك يعتمد حقًا على حالتك المحددة.اعتمادًا على تفاصيل الموقف، أستطيع أن أرى نفسي أقرر استخدام هذا النهج أو أي من الأساليب التي ذكرتها أعلاه.

Answer 3

اقتراحي هو استخدام الخيار رقم 2 ومن ثم مساعدتنا في إعادة تصميم Moose حتى تصبح CGI قابلة للتطبيق.تعمل fREW حاليًا على مجموعة اختبار Moose من أجل تمكين مشروع MooseX::Antlers والذي من المفترض أن يقلل معظم النفقات العامة مما يعني أن Moose غير قابل للاستخدام في بيئة CGI.

أعرب Matt Trout (mst)، الرجل الذي يقف حاليًا وراء MooseX::Antlers، عن رغبته في أن يكون قادرًا على تشغيل التطبيقات في بيئة CGI إذا لزم الأمر.أقترح التمسك بـ FCGI في الوقت الحالي وإلحاحه بشأن ما يمكنك فعله للمساعدة!

Answer 4

كتب جوناثان روكواي عنه التطبيق::ثابت (والتي، بشكل غريب، ليست موجودة في CPAN) قبل بضعة أشهر.لم أستخدمه، ولكن استنادًا إلى منشور مدونته المرتبط أعلاه، فإنه يتطلع إلى توفير بنية خادم وعميل شفافة إلى حد ما يمكنك تغليف المعالجة الفعلية لـ CGI الخاصة بك بها.

Answer 5

الفكرة الأساسية ل App::Persistent, pperl, SpeedyCGI وربما يكون البعض الآخر هو أن عملية تجميع برنامج Perl الخاص بك إلى كود بايت تتم مرة واحدة فقط ويتم استخدام نوع من التخزين المؤقت في الدعوات بعد ذلك.نظرًا لأنه يقال إن Moose لديه عقوبة وقت الترجمة، فسأجرب هذا الأسلوب أولاً.

لقد استخدمت بنجاح pperl لرسم الكثير من MRTG الرسوم البيانية على النظام القديم حوالي عام 2001.تم تنفيذ برنامج Perl لكل رسم بياني كان يمثل عبئًا كبيرًا - وهذا على الأرجح يمكن مقارنته بسيناريو CGI الخاص بك.

Answer 6

هناك أيضًا خيار آخر - بيرل.

لم أستخدمها أبدًا، لكنها تبدو مثيرة للاهتمام بالتأكيد.والشخص الذي كتبه (Matt Sergeant المعروف أيضًا باسم baud) - يمنحك ضمانًا عمليًا لرمز عالي الجودة.