في حياة كل مشروع ، يأتي الوقت الذي يتوقف فيه الخادم عن تلبية متطلبات اتفاقية مستوى الخدمة ويبدأ فعليًا في خنق كمية حركة المرور الواردة. بعد ذلك ، تبدأ العملية الطويلة للبحث عن الاختناقات أو الاستعلامات الثقيلة أو الفهارس التي تم إنشاؤها بشكل غير صحيح أو البيانات غير المخزنة مؤقتًا أو العكس بالعكس ، والتي غالبًا ما يتم تحديث البيانات في ذاكرة التخزين المؤقت والجوانب المظلمة الأخرى للمشروع.
ولكن ماذا تفعل عندما يكون رمزك "مثاليًا" ، ويتم وضع جميع الطلبات الثقيلة في الخلفية ، وكل شيء كان ممكنًا تم تخزينه مؤقتًا ، ولا يزال الخادم لا يصل إلى مؤشرات اتفاقية مستوى الخدمة التي نحتاجها؟ إذا أمكن ، بالطبع يمكنك شراء سيارات جديدة ، وتوزيع بعض حركة المرور ونسيان المشكلة لفترة من الوقت.
ولكن إذا كان لديك شعور بأن الخادم الخاص بك قادر على المزيد ، أو أن هناك معلمة سحرية تسرع الموقع 100 مرة ، فيمكنك تذكر ميزة nginx المضمنة التي تسمح لك بتخزين الاستجابات من الخلفية. دعنا نلقي نظرة على ما هو وكيف يمكن أن يساعد في زيادة عدد الطلبات التي تتم معالجتها بواسطة الخادم.
ما هو Nginx cache وكيف يعمل؟
يمكن أن تقلل ذاكرة التخزين المؤقت في Nginx عدد طلبات الواجهة الخلفية بشكل ملحوظ. يتم تحقيق ذلك عن طريق حفظ استجابة HTTP لفترة معينة ، وعند الوصول إلى المورد مرة أخرى ، وإعادته من ذاكرة التخزين المؤقت دون إجراء وكيل لطلب الواجهة الخلفية. التخزين المؤقت ، حتى لفترة قصيرة ، سيعطي زيادة كبيرة في عدد الطلبات المعالجة من قبل الخادم.
قبل متابعة تكوين nginx ، يجب أن تتأكد من أنه تم إنشاؤه باستخدام الوحدة النمطية "ngx_http_proxy_module" ، حيث سنقوم بتكوينه باستخدام هذه الوحدة.
للراحة ، يمكنك نقل التكوين إلى ملف منفصل ، على سبيل المثال ، "/etc/nginx/conf.d/cache.conf". دعنا نلقي نظرة على توجيه proxy_cache_path ، الذي يسمح لك بتكوين إعدادات تخزين ذاكرة التخزين المؤقت.
proxy_cache_path /var/lib/nginx/proxy_cache levels=1:2 keys_zone=proxy_cache:15m max_size=1G;
يحدد "/ Var / lib / nginx / proxy_cache" مسار تخزين ذاكرة التخزين المؤقت على الخادم. في هذا الدليل ، سيحفظ nginx الملفات نفسها بالاستجابة من الواجهة الخلفية. في الوقت نفسه ، لن يقوم nginx بإنشاء دليل لذاكرة التخزين المؤقت بشكل مستقل ، وعليك الاهتمام بهذا بنفسك.
"المستويات = 1: 2" - يضبط مستوى تداخل الدلائل مع ذاكرة التخزين المؤقت. يشار إلى مستويات التعشيش من خلال ":" ، في هذه الحالة سيتم إنشاء دليلين ، في مجموع 3 مستويات تداخل مسموح بها. لكل مستوى تداخل ، تتوفر قيم من 1 إلى 2 ، تشير إلى كيفية إنشاء اسم الدليل.
النقطة المهمة هي أنه لا يتم اختيار اسم الدليل بشكل عشوائي ، ولكن يتم إنشاؤه بناءً على اسم الملف. اسم الملف ، بدوره ، هو نتيجة وظيفة md5 من مفتاح ذاكرة التخزين المؤقت ؛ سننظر في مفتاح ذاكرة التخزين المؤقت بعد ذلك بقليل.
دعونا نرى عمليا كيف يتم بناء المسار إلى ملف ذاكرة التخزين المؤقت:
/var/lib/nginx/proxy_cache/2/49/07edcfe6974569ab4da6634ad4e5d492
تحدد المعلمة “Keys_zone = proxy_cache: 15m” اسم المنطقة في الذاكرة المشتركة ، حيث يتم تخزين جميع المفاتيح والمعلومات النشطة عليها. يشير ":" إلى حجم الذاكرة المخصصة بالميغابايت. وفقًا لـ nginx ، يكفي 1 ميغابايت لتخزين 8 آلاف مفتاح.
يحدد "Max_size = 1G" الحد الأقصى لحجم ذاكرة التخزين المؤقت لجميع الصفحات التي سيتولى nginx أعلاه حذف البيانات الأقل حاجة إليها.
من الممكن أيضًا التحكم في عمر البيانات الموجودة في ذاكرة التخزين المؤقت ، لذلك يكفي تحديد المعلمة "غير النشطة" لتوجيه "proxy_cache_path" ، وهو 10 دقائق افتراضيًا. إذا لم تكن هناك استدعاءات لبيانات ذاكرة التخزين المؤقت خلال الفترة المحددة في المعلمة "غير النشطة" ، فسيتم حذف هذه البيانات حتى إذا لم تكن ذاكرة التخزين المؤقت "حامضة" حتى الآن.
كيف تبدو ذاكرة التخزين المؤقت هذه؟ هذا في الواقع ملف عادي على الخادم ، تتم كتابة محتوياته:
• مفتاح التخزين المؤقت ؛
• رؤوس ذاكرة التخزين المؤقت ؛
• استجابة المحتوى من الخلفية.
إذا كان كل شيء واضحًا مع الرؤوس والاستجابة من الواجهة الخلفية ، فهناك عدد من الأسئلة على "مفتاح ذاكرة التخزين المؤقت". كيف يتم بنائه وكيف يمكن إدارته؟
لوصف القالب لبناء مفتاح ذاكرة التخزين المؤقت في nginx ، هناك توجيه proxy_cache_key ، حيث يتم تحديد السلسلة كمعلمة. يمكن أن تتكون السلسلة من أي متغيرات متوفرة في nginx.
على سبيل المثال:
proxy_cache_key $request_method$host$orig_uri:$cookie_some_cookie:$arg_some_arg;
يتم استخدام الرمز ":" بين معلمة ملف تعريف الارتباط ومعلمة get لمنع التصادم بين مفاتيح التخزين المؤقت ، يمكنك اختيار أي رمز آخر من اختيارك. بشكل افتراضي ، يستخدم nginx السطر التالي لإنشاء المفتاح:
proxy_cache_key $scheme$proxy_host$request_uri;
يجب ملاحظة التوجيهات التالية التي ستساعدك على إدارة التخزين المؤقت بشكل أكثر مرونة:
proxy_cache_valid - يحدد وقت التخزين المؤقت للاستجابة. من الممكن الإشارة إلى الحالة المحددة للاستجابة ، على سبيل المثال 200 ، 302 ، 404 ، إلخ ، أو تحديد كل شيء دفعة واحدة باستخدام البناء "أي". إذا تم تحديد وقت التخزين المؤقت فقط ، فسيكون nginx افتراضيًا للتخزين المؤقت لحالات 200 و 301 و 302 فقط.
مثال:
proxy_cache_valid 15m; proxy_cache_valid 404 15s;
في هذا المثال ، قمنا بتعيين عمر التخزين المؤقت على 15 دقيقة للحالات 200 ، 301 ، 302 (تستخدمها nginx بشكل افتراضي ، حيث لم نحدد حالة معينة). يضبط السطر التالي وقت التخزين المؤقت على 15 ثانية ، فقط للردود بالحالة 404.
proxy_cache_lock -
سيساعد هذا التوجيه على تجنب التمريرات المتعددة للواجهة الخلفية مباشرة بعد مجموعة من ذاكرة التخزين المؤقت ، فقط قم بتعيين القيمة في الوضع "تشغيل". ستنتظر جميع الطلبات الأخرى استجابة في ذاكرة التخزين المؤقت ، أو مهلة لحظر الطلب على الصفحة. وفقًا لذلك ، يمكن تكوين كل المهلات.
proxy_cache_lock_age - يسمح لك بتعيين حد المهلة لاستجابة من الخادم ، وبعد ذلك سيتم إرسال الطلب التالي إليه بعد تعيين ذاكرة التخزين المؤقت. القيمة الافتراضية هي 5 ثوان.
proxy_cache_lock_timeout -
لضبط وقت انتظار القفل ، وبعد ذلك سيتم إرسال الطلب إلى الواجهة الخلفية ، ولكن لن يتم تخزين الاستجابة مؤقتًا. القيمة الافتراضية هي 5 ثوان.
proxy_cache_use_stale - توجيه مفيد آخر يسمح لك بالتكوين عندما يكون من الممكن استخدام ذاكرة تخزين مؤقت قديمة.
مثال:
proxy_cache_use_stale error timeout updating;
في هذه الحالة ، سيستخدم ذاكرة تخزين مؤقت قديمة في حالة حدوث خطأ في الاتصال ، أو إرسال طلب ، أو قراءة استجابة من الخادم ، أو تجاوز حد الانتظار لإرسال طلب ، أو قراءة استجابة من الخادم ، أو إذا تم تحديث البيانات الموجودة في ذاكرة التخزين المؤقت في وقت الطلب.
proxy_cache_bypass - تحدد الشروط التي لن
تتلقى فيها nginx استجابة من ذاكرة التخزين المؤقت ، ولكنها تعيد توجيه الطلب على الفور إلى الواجهة الخلفية. إذا كانت إحدى المعلمات على الأقل ليست فارغة ولا تساوي "0". مثال:
proxy_cache_bypass $cookie_nocache $arg_nocache;
proxy_no_cache - تعيين الحالة التي لن يحفظ فيها nginx الاستجابة من الواجهة الخلفية إلى ذاكرة التخزين المؤقت. مبدأ التشغيل هو نفسه مبدأ توجيه proxy_cache_bypass.
المشاكل المحتملة في التخزين المؤقت للصفحة
كما ذكر أعلاه ، إلى جانب التخزين المؤقت لاستجابة HTTP ، يحفظ nginx الرؤوس المتلقاة من الواجهة الخلفية. إذا كان موقعك يستخدم جلسة ، فسيتم أيضًا تخزين ملف تعريف ارتباط الجلسة في ذاكرة التخزين المؤقت. سيتلقى جميع المستخدمين الذين يزورون الصفحة التي كنت محظوظًا فيها التخزين المؤقت بياناتك الشخصية المخزنة في الجلسة.
التحدي التالي الذي ستواجهه هو إدارة التخزين المؤقت. بالطبع ، يمكنك ضبط وقت ذاكرة تخزين مؤقت غير مهم من 2-5 دقائق وسيكون هذا كافيًا في معظم الحالات. لكن هذا لا ينطبق في جميع المواقف ، لذلك سنعيد ابتكار دراجتنا. الآن ، أول شيء أولاً.
إدارة حفظ ملفات تعريف الارتباطالتخزين المؤقت على الجانب nginx يفرض بعض قيود التصميم. على سبيل المثال ، لا يمكننا استخدام الجلسات على الصفحات المخبأة ، حيث لا يصل المستخدم إلى الواجهة الخلفية ، وهناك قيود أخرى هي تسليم ملفات تعريف الارتباط من قبل الواجهة الخلفية. نظرًا لأن nginx تخزن جميع الرؤوس في ذاكرة التخزين المؤقت ، لتجنب تخزين جلسة شخص آخر في ذاكرة التخزين المؤقت ، نحتاج إلى حظر تسليم ملفات تعريف الارتباط للصفحات المخزنة مؤقتًا. سيساعدنا توجيه proxy_ignore_headers في ذلك. تسرد الوسيطة الرؤوس التي يجب تجاهلها من الواجهة الخلفية.
مثال:
proxy_ignore_headers "Set-Cookie";
مع هذا الخط ، نتجاهل تثبيت ملفات تعريف الارتباط من الخادم الوكيل ، أي أن المستخدم سيتلقى استجابة بدون رأس "Set-Cookies". وفقًا لذلك ، سيتم تجاهل كل شيء حاولت الواجهة الخلفية كتابته إلى ملف تعريف الارتباط من جانب العميل ، لأنه لن يعرف حتى أن هناك شيئًا مخصصًا له. يجب مراعاة تقييد ملف تعريف الارتباط هذا عند تطوير تطبيق. على سبيل المثال ، لطلب تفويض ، يمكنك إيقاف تشغيل الإشعال بحيث يتلقى المستخدم ملف تعريف ارتباط الجلسة.
يجب أن تأخذ في الاعتبار أيضًا مدة الجلسة ، حيث يمكن عرضها في معلمة "
session.gc_maxlifetime " لتكوين php.ini. تخيل أن المستخدم قام بتسجيل الدخول إلى الموقع وبدأ في عرض موجز الأخبار ، كل البيانات موجودة بالفعل في ذاكرة التخزين المؤقت لـ nginx. بعد مرور بعض الوقت ، يلاحظ المستخدم أن تفويضه قد اختفى ويحتاج مرة أخرى للخضوع لعملية التفويض ، على الرغم من أنه كان طوال الوقت في الموقع يشاهد الأخبار. حدث هذا لأن nginx في جميع طلباتها أعادت النتيجة من ذاكرة التخزين المؤقت دون إرسال طلب إلى الواجهة الخلفية. لذلك ، قررت الخلفية أن المستخدم كان غير نشط وبعد حذف الوقت المحدد في "
session.gc_maxlifetime " حذف ملف الجلسة.
لمنع حدوث ذلك ، يمكننا محاكاة طلبات الواجهة الخلفية. على سبيل المثال ، من خلال ajax ، أرسل طلبًا سيتم ضمان تمريره إلى الواجهة الخلفية. لتمرير ذاكرة التخزين المؤقت nginx إلى الواجهة الخلفية ، فقط أرسل طلب POST ، يمكنك أيضًا استخدام القاعدة من توجيه "proxy_cache_bypass" ، أو ببساطة قم بتعطيل ذاكرة التخزين المؤقت لهذه الصفحة. لا يجب أن يعيد الطلب شيئًا ما ، يمكن أن يكون ملفًا بسطر واحد يبدأ الجلسة. الغرض من مثل هذا الطلب هو إطالة عمر الجلسة أثناء وجود المستخدم على الموقع ، وتعطي nginx بضمير البيانات المخزنة مؤقتًا لجميع طلباتها.
إدارة تدفق ذاكرة التخزين المؤقتتحتاج أولاً إلى تحديد المتطلبات ، ما الهدف الذي نحاول تحقيقه. لنفترض أن موقعنا يحتوي على قسم به بث نصي للأحداث الرياضية الشهيرة. عند تحميل الصفحة من ذاكرة التخزين المؤقت ، تأتي جميع الرسائل الجديدة على مآخذ. حتى يتمكن المستخدم من رؤية الرسائل الحالية في الوقت الحالي في التمهيد الأول ، بدلاً من 15 دقيقة ، نحتاج إلى أن نتمكن من مسح ذاكرة التخزين المؤقت لـ nginx بشكل مستقل في أي وقت. في نفس الوقت ، قد لا يكون nginx موجودًا على نفس الجهاز مثل التطبيق. أيضًا ، سيكون أحد متطلبات إعادة الضبط هو القدرة على حذف ذاكرة التخزين المؤقت عبر صفحات متعددة في وقت واحد.
قبل أن تبدأ في كتابة الحل الخاص بك ، دعنا نرى ما يقدمه nginx خارج الصندوق. لإعادة تعيين ذاكرة التخزين المؤقت ، يحتوي nginx على توجيه خاص يسمى "proxy_cache_purge" ، والذي يسجل حالة إعادة تعيين ذاكرة التخزين المؤقت. الشرط هو في الواقع خط عادي ، إذا لم يكن فارغًا وليس "0" ، فسيتم حذف ذاكرة التخزين المؤقت من خلال المفتاح الذي تم تمريره. فكر في مثال صغير.
proxy_cache_path /data/nginx/cache keys_zone=cache_zone:10m; map $request_method $purge_method { PURGE 1; default 0; } server { ... location / { proxy_pass http://backend; proxy_cache cache_zone; proxy_cache_key $uri; proxy_cache_purge $purge_method; } }
تم أخذ مثال من موقع nginx الرسمي.المتغير $ purge_method مسؤول عن مسح ذاكرة التخزين المؤقت ، وهو شرط لتوجيه proxy_cache_purge ويتم تعيينه على 0 بشكل افتراضي. هذا يعني أن nginx يعمل في الوضع "العادي" (يحفظ الاستجابات من الواجهة الخلفية). ولكن إذا قمت بتغيير طريقة الطلب إلى "PURGE" ، فبدلاً من تقديم طلب الواجهة الخلفية مع حفظ الاستجابة ، سيتم حذف إدخال ذاكرة التخزين المؤقت باستخدام مفتاح التخزين المؤقت المقابل. من الممكن أيضًا تحديد قناع حذف عن طريق تحديد "*" في نهاية مفتاح التخزين المؤقت. وبالتالي ، لا نحتاج إلى معرفة موقع ذاكرة التخزين المؤقت على القرص ومبدأ تكوين المفتاح ، ويتولى nginx هذه المسؤوليات. ولكن هناك أيضًا عيوب في هذا النهج.
- يتوفر التوجيه proxy_cache_purge كجزء من اشتراك تجاري.
- من الممكن فقط حذف ذاكرة التخزين المؤقت بشكل نقطي ، أو باستخدام قناع النموذج {مفتاح التخزين المؤقت} "*"
نظرًا لأن عناوين الصفحات المخزنة مؤقتًا يمكن أن تكون مختلفة تمامًا ، بدون أجزاء شائعة ، فإن النهج باستخدام القناع "*" والتوجيه "proxy_cache_purge" غير مناسب لنا. يبقى أن نتذكر القليل من النظرية واكتشف IDide المفضلة لديك.
نحن نعلم أن ذاكرة التخزين المؤقت nginx هي ملف عادي على الخادم. حددنا بشكل مستقل الدليل لتخزين ملفات ذاكرة التخزين المؤقت في توجيه "proxy_cache_path" ، حتى أننا حددنا منطق تشكيل المسار إلى الملف من هذا الدليل باستخدام "المستويات". الشيء الوحيد الذي نفتقده هو التكوين الصحيح لمفتاح التخزين المؤقت. ولكن يمكننا أيضًا رؤيته في توجيه "proxy_cache_key". الآن كل ما علينا فعله هو:
- تشكيل المسار الكامل للصفحة ، تمامًا كما هو محدد في توجيه proxy_cache_key ؛
- ترميز السلسلة الناتجة في md5 ؛
- إنشاء أدلة متداخلة باستخدام القاعدة من معلمة "المستويات".
- والآن لدينا بالفعل المسار الكامل إلى ملف ذاكرة التخزين المؤقت على الخادم. الآن كل ما تبقى لنا هو حذف هذا الملف بالذات. من الجزء التمهيدي ، نعلم أن nginx قد لا يكون موجودًا على جهاز التطبيق ، لذلك تحتاج إلى تمكين حذف عدة عناوين في وقت واحد. مرة أخرى ، نصف الخوارزمية:
- المسارات التي تم إنشاؤها لملفات ذاكرة التخزين المؤقت سنكتب إلى الملف ؛
- لنكتب نص باش بسيط نضعه على الجهاز مع التطبيق. ستكون مهمته الاتصال عبر ssh بالخادم حيث لدينا التخزين المؤقت nginx وحذف جميع ملفات ذاكرة التخزين المؤقت المحددة في الملف الذي تم إنشاؤه من الخطوة 1 ؛
ننتقل من النظرية إلى الممارسة ، وسنكتب مثالًا صغيرًا يوضح خوارزمية عملنا.
الخطوة 1. إنشاء ملف بمسارات إلى ذاكرة التخزين المؤقت.
$urls = [ 'httpGETdomain.ru/news/111/1:2', 'httpGETdomain.ru/news/112/3:4', ]; function to_nginx_cache_path(url) { $nginxHash = md5($url); $firstDir = substr($nginxHash, -1, 1); $secondDir = substr($nginxHash, -3, 2); return "/var/lib/nginx/proxy_cache/$firstDir/$secondDir/$nginxHash"; } // tmp $filePath = tempnam('tmp', 'nginx_cache_'); // $fileStream = fopen($filePath, 'a'); foreach ($urls as $url) { // $cachePath = to_nginx_cache_path($url); // fwrite($fileStream, $cachePath . PHP_EOL); } // fclose($fileStream); // bash exec("/usr/local/bin/cache_remover $filePath");
يرجى ملاحظة أن عناوين url المتغيرة تحتوي على عنوان url الخاص بالصفحات المخزنة مؤقتًا ، بالتنسيق proxy_cache_key المحدد بالفعل في التكوين nginx. يعمل Url كعلامة للكيانات المعروضة على الصفحة. على سبيل المثال ، يمكنك إنشاء جدول عادي في قاعدة البيانات ، حيث سيتم تعيين كل كيان لصفحة معينة يتم عرضها عليه. بعد ذلك ، عند تغيير أي بيانات ، يمكننا إجراء تحديد على الجدول وحذف ذاكرة التخزين المؤقت لجميع الصفحات التي نحتاجها.
الخطوة 2. الاتصال بخادم ذاكرة التخزين المؤقت وحذف ملفات ذاكرة التخزين المؤقت.
# , FILE_LIST=`cat $1 | tr ` # ssh SSH=`which ssh` USER= # nginx HOST= # KEY= # SSH , $SSH -i ${KEY} ${USER}@${HOST} # rm -rf rm -f $1 #
الأمثلة أعلاه هي للإرشاد فقط ، لا تستخدمها في الإنتاج. في الأمثلة ، يتم حذف عمليات التحقق من معلمات الإدخال وقيود الأوامر. إحدى المشاكل التي قد تواجهها هي تحديد طول الوسيطة لأمر rm. عند الاختبار في بيئة تطوير على وحدات تخزين صغيرة ، يمكن تفويتها بسهولة ، وفي الإنتاج تحصل على الخطأ "rm: قائمة الوسائط طويلة جدًا".
التخزين المؤقت كتلة مخصصة
دعونا نلخص ما تمكنا من القيام به:
- تقليل الحمل على الواجهة الخلفية ؛
- تعرف على كيفية إدارة التخزين المؤقت
- تعلمت مسح ذاكرة التخزين المؤقت في أي وقت.
ولكن ليس كل شيء جيد كما قد يبدو للوهلة الأولى. الآن ، على الأرجح ، إن لم يكن في كل مرة ، فإن كل موقع ثاني على وجه التحديد يحتوي على وظيفة تسجيل / تفويض ، بعد المرور ، سنريد عرض اسم المستخدم في مكان ما في الرأس. الكتلة التي تحمل الاسم فريدة ويجب أن تعرض اسم المستخدم الذي يتم تفويضنا بموجبه. نظرًا لأن nginx يحفظ الاستجابة من الواجهة الخلفية ، وفي حالة الصفحة يكون محتوى html للصفحة ، فسيتم أيضًا تخزين كتلة البيانات الشخصية مؤقتًا. سيرى جميع زوار الموقع اسم المستخدم الأول الذي مرر إلى الواجهة الخلفية لمجموعة من ذاكرة التخزين المؤقت.
لذلك ، يجب ألا تعطي الواجهة الخلفية كتلًا حيث توجد المعلومات الشخصية بحيث لا تقع هذه المعلومات تحت ذاكرة التخزين المؤقت لـ nginx.
من الضروري النظر في تحميل بديل لهذه الأجزاء من الصفحة. كما هو الحال دائمًا ، يمكن القيام بذلك بعدة طرق ، على سبيل المثال ، بعد تحميل الصفحة ، وإرسال طلب أجاكس ، وعرض المحمل بدلاً من المحتوى الشخصي. طريقة أخرى سننظر فيها اليوم هي استخدام علامات ssi. دعونا نفهم أولاً ما هو SSI ، ثم كيف يمكننا استخدامه مع ذاكرة التخزين المؤقت nginx.
ما هو SSI وكيف يعمل
SSI (يتضمن جانب الخادم ، التضمينات من جانب الخادم) هي مجموعة من الأوامر المضمنة في صفحة html والتي تخبر الخادم بما يجب القيام به.
فيما يلي قائمة بهذه الأوامر (التوجيهات):
• if / elif / else / endif - عامل التفرع ؛
• صدى - يعرض قيم المتغيرات ؛
• include - يسمح لك بإدراج محتويات ملف آخر في المستند.
سيتم مناقشة التوجيه الأخير فقط. يحتوي توجيه التضمين معلمتين:
• ملف - يحدد المسار للملف على الخادم. بخصوص الدليل الحالي ؛
• ظاهري - يشير إلى المسار الافتراضي للمستند على الخادم.
نحن مهتمون بالمعلمة "الظاهرية" ، نظرًا لأن تحديد المسار الكامل للملف على الخادم ليس دائمًا مناسبًا ، أو في حالة البنية الموزعة ، فإن الملف الموجود على الخادم غير موجود ببساطة. توجيه المثال:
لكي تبدأ nginx في معالجة إدخالات ssi ، تحتاج إلى تعديل الموقع على النحو التالي:
location / { ssi on; ... }
الآن سيتمكن جميع الطلبات التي تمت معالجتها بواسطة الموقع "/" من تنفيذ إدخالات Ssi.
كيف سيمر طلبنا بهذا المخطط بأكمله؟
- يطلب العميل الصفحة ؛
- تقوم Nginx بطلب طلب الواجهة الخلفية ؛
- تعطي الواجهة الخلفية الصفحة بإدراج ssi ؛
- يتم تخزين النتيجة في ذاكرة التخزين المؤقت ؛
- تستفسر Nginx عن الكتل المفقودة ؛
- يتم إرسال الصفحة الناتجة إلى العميل.
كما ترى من الخطوات ، ستدخل تصميمات ssi في ذاكرة التخزين المؤقت nginx ، مما سيسمح بعدم تخزين الكتل الشخصية مؤقتًا ، وسيتم إرسال صفحة html جاهزة مع كل المدخلات. هنا يعمل تحميلنا ، تطلب nginx بشكل مستقل كتل الصفحات المفقودة. ولكن مثل أي حل آخر ، فإن هذا النهج له إيجابياته وسلبياته. تخيل أن هناك العديد من الكتل في الصفحة التي يجب عرضها بشكل مختلف اعتمادًا على المستخدم ، ثم سيتم استبدال كل كتلة من هذا القبيل بإدراج ssi. كما هو متوقع ، ستطلب Nginx كل كتلة من هذه الواجهة الخلفية ، أي أن طلبًا واحدًا من المستخدم سيؤدي على الفور إلى إنشاء عدة طلبات للواجهة الخلفية ، وهو ما لا أرغب فيه على الإطلاق.
التخلص من طلبات الواجهة الخلفية المستمرة عبر SSI
لحل هذه المشكلة ، ستساعدنا وحدة nginx “ngx_http_memcached_module”. تسمح الوحدة بتلقي القيم من خادم memcached. لن تعمل الكتابة من خلال الوحدة النمطية ، يجب أن يعتني خادم التطبيق بذلك. فكر في مثال صغير لتكوين nginx بالاقتران مع وحدة نمطية:
server { location /page { set $memcached_key "$uri"; memcached_pass 127.0.0.1:11211; error_page 404 502 504 = @fallback; } location @fallback { proxy_pass http://backend; } }
في المتغير $ memcache_key حددنا المفتاح الذي ستحاول nginx من خلاله الحصول على البيانات من memcache. يتم تعيين المعلمات للاتصال بخادم memcache في التوجيه memcached_pass. يمكن تحديد الاتصال بعدة طرق:
• اسم المجال ؛
memcached_pass cache.domain.ru;
• عنوان IP والمنفذ ؛
memcached_pass localhost:11211;
• مقبس يونكس.
memcached_pass unix:/tmp/memcached.socket;
• توجيه المنبع.
upstream cachestream { hash $request_uri consistent; server 10.10.1.1:11211; server 10.10.1.2:11211; } location / { ... memcached_pass cachestream; ... }
إذا تمكن nginx من الحصول على استجابة من خادم ذاكرة التخزين المؤقت ، فإنه يعطيها للعميل. في حالة عدم وجود بيانات في ذاكرة التخزين المؤقت ، سيتم إرسال الطلب إلى الواجهة الخلفية عبر "fallback". سيساعدنا هذا الإعداد الصغير للوحدة memcached تحت nginx على تقليل عدد طلبات المرور للواجهة الخلفية من إدخالات ssi.
نأمل أن تكون هذه المقالة مفيدة وقد تمكنا من إظهار إحدى الطرق لتحسين الحمل على الخادم ، والنظر في المبادئ الأساسية لإعداد التخزين المؤقت لـ nginx وإغلاق المشكلات التي تنشأ عند استخدامه.