سؤال

من أجل تخفيف حمل Apache، يقترح الأشخاص غالبًا استخدام lighttpd لتقديم محتوى ثابت.

على سبيل المثال http://www.linux.com/feature/51673

في هذا الإعداد، يقوم Apache بتمرير طلبات المحتوى الثابت مرة أخرى إلى lighttpd عبر mod_proxy، بينما يخدم الطلبات الديناميكية نفسها.

سؤالي هو:كيف يؤدي هذا إلى تقليل الحمل على الخادم؟نظرًا لأنه لا يزال لديك عملية apache يتم إنشاؤها لكل طلب يأتي، فكيف يؤثر ذلك بشكل إيجابي على الحمل؟مما أستطيع أن أرى أن حجم عملية Apache التي تقوم بتوكيل طلبها من خلال lighttpd كبير كما لو كان يخدم الملف نفسه.

هل كانت مفيدة؟

المحلول

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

ما ستراه هو أن الأشخاص يستخدمون خادم ويب خفيف الوزن نجينكس ك نهاية المقدمة خادم لخدمة الملفات الثابتة وعناوين URL الديناميكية للوكيل إلى Apache.أو يمكنك الركض ورنيش أو حبار كواجهة أمامية للوكيل العكسي للتخزين المؤقت، بحيث يمكن لجميع ملفاتك الثابتة ذات حركة المرور العالية (أي.الصور، CSS الخ. و أي صفحات ديناميكية ترغب في إرسال رؤوس مناسبة لذاكرة التخزين المؤقت لها) يتم عرضها خارج الذاكرة.

يمكن أيضًا تحسين Apache لخدمة الملفات الثابتة - في كثير من الأحيان عندما أسمع أشخاصًا يشكون من Apache، فإنهم لا يعرفون حقًا كيفية تكوينه.لقد استخدموا فقط الشوكة المسبقة MPM (مقابل.مترابطة أو عاملة) ويتم تمكين جميع أنواع الوحدات النمطية (عادةً ما يتم تشغيلها من حزمة Apache لحوض المطبخ الخاصة بتوزيع Linux والتي تبني كل شيء كوحدات نمطية وتفترض تمكين 10-20 وحدة أو أكثر).قم بضبط Apache عن طريق إيقاف تشغيل الوحدات غير الضرورية/الميزات الغبية مثل دعم .htaccess (مما يجعل Apache يقوم بفحص نظام الملفات عند كل طلب!) أولاً.(يمكنك أيضًا تشغيل مثيلين من Apache، مع Apache "خفيف" كواجهة أمامية تعمل كوكيل لـ Apache "الثقيل" للطلبات الديناميكية...ربما تكون الواجهة الأمامية الخاصة بك مترابطة ولكن الواجهة الخلفية الخاصة بك تكون مسبقة لأنه يتعين عليك تشغيل وحدات خارجية غير آمنة لمؤشر الترابط مثل mod_php.)

يكرر:

نظرًا لأنه لا يزال لديك عملية Apache التي ولدت لكل طلب يأتي ، كيف يؤثر هذا بشكل إيجابي على الحمل؟من ما أستطيع أن أرى حجم عملية Apache ، يكون طلب طلبها من خلال LightTPD كبيرًا كما لو كان يخدم الملف نفسه.

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

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

ربما يمكنني التوصل إلى "تكوين كابوس" لـ Apache كان جعله في الواقع أبطأ في تقديم الملفات الثابتة من تفويض تلك الطلبات إلى الواجهة الخلفية Lighttpd، ولكنه قد يتضمن تمكين ميزات باهظة الثمن مثل .htaccess في Apache التي تم تعطيلها في Lighttpd، لذلك لن يكون ذلك عادلاً حقًا.

نصائح أخرى

  1. إذا كان لا يزال لديك القوة ليخدم محتوى ثابت وديناميكي من نفس الآلة (كما هم في الخاص بك المادة المشار إليها افعل)، فأنا لا أرى أي فائدة من هذا الإعداد.
  2. ربما يؤدي ذلك إلى تقليل تحميل Apache، لأنه لا يحتاج إلى إجراء إدخال/إخراج على القرص، ولكنه سيزيد من تحميل Lighttpd على نفس الآلة وبالتالي تقليل التحميل المتاح لأباتشي ...
  3. ربما يكون الوصول إلى Lighttpd IO أخف من الوصول إلى Apache 1.3، لكن لماذا لا ننتقل إلى Apache 2 أو Lighttpd بالكامل؟وإذا بدأ الأداء سيئًا بالفعل، فقم باستضافة الملفات الثابتة على جهاز آخر (media.yourdomain.com).

توجد مقدمة صغيرة لكيفية إنشاء إعداد فعال هنا:نشر جانغو -> قم بالتمرير إلى Scaling بعض الصفحات قبل النهاية

لا أعرف الكثير عن العمل الداخلي لـ Apache، لكن أحد التفسيرات التي رأيتها يتعلق بضغط الذاكرة.باختصار، يحاول Apache موازنة الذاكرة التي يستخدمها للتخزين المؤقت والصفحات الديناميكية؛ولكن عادةً ما ينتهي الأمر بذاكرة تخزين مؤقت كبيرة جدًا وقليل جدًا من التطبيقات.إذا قمت بفصلها إلى عمليات مختلفة، فستعمل كل واحدة منها على تحسين نوع الحمل.

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

(نعم، يمكن أيضًا استخدام lighttpd كواجهة أمامية لـ Apache و/أو FastCGI)

وليس لديك لدت عملية أباتشي لكل طلب - الملفات الثابتة (الصور وما شابه ذلك) يتم جلب مباشرة لايت باد

واستخدام أباتشي MPM العمال fastcgi هذا من شأنه أن يخفض لك استخدام الذاكرة الخادم. يخدم MPM عامل محتوى ثابت أفضل ثم Prefork وهو تقريبا على قدم المساواة مع لايت باد عندما يتعلق الأمر محتوى ثابت.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top