ما هي التجربة التي تستخدمها NGINX و MEMCACHED لتحسين موقع الويب؟

Question

لدينا تطبيق ويب قائم على Java EE يعمل على أ السمكة الزجاجية App Server Cluster. ستكون حركة المرور الواردة بشكل أساسي طلبات مريحة للتمثيلات المستندة إلى XML لموارد التطبيق الخاصة بنا ، ولكن ربما تكون 5 ٪ من حركة المرور للتمثيلات القائمة على JSON- أو XHTML/CSS.

نحن الآن نتحقق من حلول توازن الحمل لتوزيع حركة المرور الواردة عبر مثيلات الأسماك الزجاجية في المجموعة. نحن نبحث أيضًا في كيفية تفريغ المجموعة باستخدام Memcached ، وهي خريطة تجزئة موزعة في الذاكرة ستكون مفاتيحها هي أسماء موارد REST (على سبيل المثال ، "/المستخدم/BOB" ، "/Group/Jazzlovers") والتي تكون قيمها قيمها تمثيلات XML المقابلة.

أحد الأساليب التي تبدو واعدة هي قتل كل من الطائرات بحجر واحد واستخدام الوزن الخفيف والسريع nginx خادم HTTP/وكيل عكسي. ستتعامل Nginx مع كل طلب وارد من خلال البحث أولاً عن URI في memcached لمعرفة ما إذا كان هناك تمثيل XML غير المنتهض بالفعل هناك. إذا لم يكن الأمر كذلك ، يرسل Nginx الطلب إلى إحدى حالات Glassfish. تم وصف الوحدة النمطية nginx memcached في هذه الكتابة القصيرة.

ما هو انطباعك العام مع nginx و memcached المستخدمة بهذه الطريقة ، ما مدى سعادتك معهم؟ ما هي الموارد التي وجدتها أكثر فائدة للتعرف عليها؟ إذا جربتهم ولم يتناسبوا مع أغراضك ، فلماذا لا ، وماذا استخدمت بدلاً من ذلك؟

ملاحظة: هنا أ السؤال ذي الصلة.

تحديث: سألت لاحقًا نفس السؤال على serverfault.com. الإجابات هناك تقترح بشكل أساسي بدائل لـ Nginx (مفيدة ، ولكن بشكل غير مباشر).

Answer 1

على افتراض أن لديك بنك من خوادم التطبيق بيانات تسليم المنبع للمستخدمين.

upstream webservices {
    server 10.0.0.1:80;
    server 10.0.0.2:80;
    server 10.0.0.3:80;
}
server {
    ... default nginx stuff ...
    location /dynamic_content {
          memcached_pass localhost:11211;
          default_type   text/html;
          error_page     404 502 = @dynamic_content_cache_miss;
          set $memcached_key $uri;
    }
    location @dynamic_content_cache_miss {
          proxy_pass http://webservices;
    }

ما يفعله مقتطف nginx.conf أعلاه هو توجيه جميع حركة المرور من http://example.com/dynamic/* مباشرة إلى خادم memcached. إذا كان لدى Memcache المحتوى ، فلن ترى خوادم المنبع أي حركة مرور.

إذا فشل ضرب ذاكرة التخزين المؤقت بخطأ 404 أو 502 (وليس في ذاكرة التخزين المؤقت أو Memcache) ، فسيقوم Nginx بتمرير الطلب إلى الخوادم المنبع. نظرًا لوجود ثلاثة خوادم في تعريف المنبع ، ستحصل أيضًا على وكيل موازنة تحميل شفاف أيضًا.

الآن التحذير الوحيد هو أنه يتعين عليك التأكد من أن خوادم تطبيقات الواجهة الخلفية تحتفظ بالبيانات في Memcache Fresh. يمكنني استخدام nginx + memcached + web.py لإنشاء أنظمة صغيرة بسيطة تتعامل مع آلاف الطلبات في الدقيقة على أجهزة متواضعة نسبيًا.

الرمز الزائف العام لخادم التطبيق يشبه هذا لـ Web.py

class some_page:
     def GET(self):
         output = 'Do normal page generation stuff'
         web_url = web.url().encode('ASCII')
         cache.set(web_url, str(output), seconds_to_cache_content)
         return output

إن الأشياء المهمة التي يجب تذكرها في Web.Py / Pseudo Code هي أن المحتوى القادم من memcached عبر nginx لا يمكن تغييره على الإطلاق. Nginx يستخدم سلاسل بسيطة وليس Unicode. إذا قمت بتخزين إخراج Unicode في memcached ، فستحصل على الأقل شخصيات غريبة في بداية ونهاية المحتوى المخزنة مؤقتًا.

أستخدم Nginx و Memcached لموقع ويب مرتبط بالرياضة حيث نحصل على نبضات ضخمة من حركة المرور التي تستمر فقط لبضع ساعات. لم أستطع الحصول على بدون nginx و memcached. انخفض تحميل الخادم خلال آخر رابع من يوليو من 70 ٪ إلى 0.6 ٪ بعد تنفيذ التغييرات المذكورة أعلاه. لا أستطيع أن أوصي به بما فيه الكفاية.