كيفية تخزين المحتوى في NGINX

الدروس التعليمية

NGINX كونه خادم ويب مفتوح المصدر موحد وعالي الأداء يسرّع توصيل المحتوى والتطبيقات، ويعزز الأمان، ويحسّن التوسع. إحدى أكثر حالات استخدام Nginx شيوعًا هي تخزين المحتوى، والذي يعتبر أكثر الطرق فعالية لتعزيز أداء موقع الويب.

اقرأ أيضًا: 10 أدوات تخزين مفتوحة المصدر الأعلى لنظام التشغيل Linux

يمكنك استخدام NGINX لتسريع خوادم المصدر المحلية عن طريق تكوينه لتخزين الاستجابات من الخوادم الأصلية وكذلك لإنشاء خوادم حواف لشبكات توزيع المحتوى (CDNs). NGINX يشغّل بعض أكبر شبكات توزيع المحتوى.

عند تكوينه كذاكرة مؤقتة، سيقوم NGINX بـ:

  • تخزين المحتوى الثابت والديناميكي.
  • تحسين أداء المحتوى الديناميكي باستخدام المايكرو-كاشينغ.
  • تقديم محتوى قديم أثناء إعادة التحقق في الخلفية لتحسين الأداء.
  • تجاوز أو تعيين رؤوس التحكم في التخزين المؤقت، والمزيد.

في هذه المقالة، ستتعلم كيفية تكوين NGINX كـ تخزين محتوى في نظام Linux لجعل خوادم الويب تعمل بكفاءة قصوى.

المتطلبات المسبقة:

يجب أن يكون لديك NGINX مثبتًا على خادم Linux الخاص بك، إذا لم يكن كذلك، اتبع هذه الأدلة لتثبيت Nginx:

تخزين محتوى ثابت على Nginx

المحتوى الثابت هو محتوى موقع يبقى ثابتًا (لا يتغير) عبر الصفحات. أمثلة على المحتوى الثابت تشمل الملفات مثل الصور ومقاطع الفيديو والمستندات؛ ملفات CSS وملفات JavaScript.

إذا كان موقع الويب الخاص بك يستخدم الكثير من المحتوى الثابت، فيمكنك تحسين أدائه عن طريق تمكين التخزين المؤقت على جانب العميل حيث يقوم المتصفح بتخزين نسخ من المحتوى الثابت للوصول السريع.

تكوين العينة التالية هو اختيار جيد، قم ببساطة بتعويض www.example.com بعنوان URL لموقع الويب الخاص بك وقم بإجراء التعديلات على مسارات الطرق الأخرى حسب الاقتضاء.

server {
    # substitute your web server's URL for www.example.com
    server_name www.example.com;
    root /var/www/example.com/htdocs;
    index index.php;

    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ .php$ {
        try_files $uri =404;
        include fastcgi_params;
        # substitute the socket, or address and port, of your WordPress server
        fastcgi_pass unix:/var/run/php5-fpm.sock;
        #fastcgi_pass 127.0.0.1:9000;
 	}   

    location ~* .(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg
                  |jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid
                  |midi|wav|bmp|rtf)$ {
        expires max;
        log_not_found off;
        access_log off;
    }
}

تخزين محتوى ديناميكي على Nginx

NGINX يستخدم ذاكرة تخزين مؤقتة مستمرة موجودة في نظام الملفات المحلي. لذا ابدأ بإنشاء دليل القرص المحلي المناسب لتخزين المحتوى المؤقت.
# mkdir -p /var/cache/nginx

بعد ذلك، قم بتعيين الملكية المناسبة على دليل التخزين المؤقت. يجب أن يكون مملوكًا لمستخدم NGINX (nginx) والمجموعة (nginx) كما يلي.

# chown nginx:nginx /var/cache/nginx

الآن تواصل لمعرفة كيفية تمكين المحتوى الديناميكي على Nginx في القسم التالي.

تمكين FastCGI Cache في NGINX

FastCGI (أو FCGI) هو بروتوكول مستخدم على نطاق واسع لتفاعل التطبيقات مثل PHP مع خوادم الويب مثل NGINX. وهو امتداد لـ CGI (Common Gateway Interface).

الميزة الرئيسية لـ FCGI هي أنه يدير طلبات CGI متعددة في عملية واحدة. بدون ذلك، يتعين على خادم الويب فتح عملية جديدة (يجب التحكم فيها، معالجة الطلب، وإغلاقها) لكل طلب عميل لخدمة.

لمعالجة النصوص PHP في نظام تشغيل LEMP، يستخدم NGINX FPM (FastCGI Process Manager) أو PHP-FPM، وهو تنفيذ PHP FastCGI بديل شائع. بمجرد تشغيل عملية PHP-FPM، يتم تكوين NGINX لتوجيه الطلبات إليه للمعالجة. وبالتالي، يمكن أيضًا تكوين NGINX لحفظ الاستجابات من الخادم التطبيقي الخلفي PHP-FPM.

تحت NGINX، يتم إعلان ذاكرة التخزين المؤقت لمحتوى FastCGI باستخدام توجيه يسمى fastcgi_cache_path في سياق http{} العلوي، داخل هيكل تكوين NGINX. يمكنك أيضًا إضافة fastcgi_cache_key التي تحدد مفتاحًا (معرف الطلب) للتخزين المؤقت.

بالإضافة إلى ذلك، لقراءة حالة ذاكرة التخزين المؤقت العليا، أضف التوجيه add_header X-Cache-Status داخل سياق http{} – وهذا مفيد لأغراض تصحيح الأخطاء.

بافتراض أن ملف تكوين كتلة الخادم الخاص بموقعك يقع في /etc/nginx/conf.d/testapp.conf أو /etc/nginx/sites-available/testapp.conf (تحت Ubuntu ومشتقاتها)، افتح ملف التحرير وأضف الأسطر التالية في أعلى الملف.

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=CACHEZONE:10m; inactive=60m max_size=40m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
add_header X-Cache $upstream_cache_status;
Enable FastCGI Cache in NGINX

يحدد التوجيه fastcgi_cache_path عدد المعلمات التي هي:

  • /var/cache/nginx – المسار إلى دليل القرص المحلي للتخزين المؤقت.
  • levels – يحدد مستويات الهرم للتخزين المؤقت، ويعيد ضبط هرم الدليل ذو المستوىين تحت /var/cache/nginx.
  • keys_zone (name:size) – يمكن إنشاء منطقة ذاكرة مشتركة حيث يتم تخزين جميع المفاتيح النشطة ومعلومات البيانات (الفرعية). يجب ملاحظة أن تخزين المفاتيح في الذاكرة يسرع عملية التحقق، عن طريق تسهيل عملية NGINX في تحديد ما إذا كان ذلك MISS أو HIT، دون التحقق من الحالة على القرص.
  • inactive – يحدد مدة الوقت بعد التي يتم حذف البيانات المخزنة المؤقتة التي لم يتم الوصول إليها خلال الوقت المحدد من التخزين المؤقت بغض النظر عن طول صلاحيتها. قيمة 60m في تكوين المثال الخاص بنا تعني أن الملفات التي لم يتم الوصول إليها بعد 60 دقيقة سيتم حذفها من التخزين المؤقت.
  • الحجم_الأقصى – يحدد الحجم الأقصى للذاكرة المؤقتة. هناك المزيد من المعلمات التي يمكنك استخدامها هنا (اقرأ وثائق NGINX لمزيد من المعلومات).

تُوضح المتغيرات في توجيه fastcgi_cache_key كما هو موضح أدناه.

تستخدم NGINX هذه المتغيرات في حساب مفتاح (معرف) الطلب. والأمر المهم هو أنه لإرسال استجابة مخزنة مؤقتًا إلى العميل، يجب أن يحتوي الطلب على نفس المفتاح كاستجابة مخزنة مؤقتًا.

  • $scheme – مخطط الطلب، HTTP أو HTTPS.
  • $request_method – طريقة الطلب، عادةً “GET” أو “POST”.
  • $host – يمكن أن يكون هذا اسم الاستضافة من سطر الطلب، أو اسم الاستضافة من حقل رأس الطلب “Host”، أو اسم الخادم المطابق لطلب، بحسب ترتيب الأولوية.
  • $request_uri – يعني الرابط الأصلي الكامل للطلب (مع المعلمات).

أيضًا، يتم حساب المتغير $upstream_cache_status في توجيه add_header X-Cache-Status لكل طلب يستجيب NGINX له، سواء كانت الاستجابة MISS (لا يتم العثور على الاستجابة في الذاكرة المؤقتة، تم الحصول عليها من خادم التطبيق) أو HIT (الاستجابة المقدمة من الذاكرة المؤقتة) أو أي من القيم المدعومة الأخرى.

بعد ذلك، ضمن توجيه location الذي يمرر طلبات PHP إلى PHP-FPM، يستخدم توجيهات fastcgi_cache لتفعيل الذاكرة المؤقتة التي قمت بتعريفها للتو.

يتم أيضًا تعيين وقت التخزين المؤقت للاستجابات المختلفة باستخدام توجيه fastcgi_cache_valid كما هو موضح.

fastcgi_cache CACHEZONE;
fastcgi_cache_valid  60m;
Define Caching Zone and Time

إذا تم تحديد وقت التخزين المؤقت فقط كما هو الحال في حالتنا، يتم تخزين الاستجابات 200، 301، و 302 فقط. ولكن يمكنك أيضًا تحديد الاستجابات بشكل صريح أو استخدام أي استجابة (لأي كود استجابة): 

fastcgi_cache CACHEZONE;
fastcgi_cache_valid 200  301 203 60m;
fastcgi_cache_valid 404 10m;
OR
fastcgi_cache CACHEZONE;
fastcgi_cache_valid  any 10m;

ضبط أداء تخزين FastCGI بدقة عالية على Nginx

لتعيين الحد الأدنى لعدد مرات التوجيه التي يجب أن يتم فيها طلب بنفس المفتاح قبل تخزين الاستجابة، يجب تضمين التوجيه fastcgi_cache_min_uses، سواء في سياق http{} أو server{} أو location{}. 

fastcgi_cache_min_uses  3
Set Minimum Cache Usage

لتمكين إعادة التحقق من العناصر المخزنة المنتهية الصلاحية باستخدام طلبات شرطية مع حقول الرأس “If-Modified-Since” و “If-None-Match“، أضف التوجيه fastcgi_cache_revalidate، ضمن سياق http{} أو server{} أو location{}. 

fastcgi_cache_revalidate on;
Set Cache Re-validation

يمكنك أيضًا تعليم NGINX لتسليم المحتوى المخزن عندما يكون الخادم الأصلي أو خادم FCGI غير متاح، باستخدام التوجيه proxy_cache_use_stale، ضمن توجيه الموقع.

يعني تكوين العينة هذا أنه عندما يتلقى NGINX خطأً أو مهلةً وأي من الأخطاء المحددة من الخادم الفرعي ويحتوي على نسخة قديمة من الملف المطلوب في المحتوى المخزن، فإنه يسلم الملف القديم.

proxy_cache_use_stale error timeout http_500;
Enable Serving of Stale Data

تعد التوجيهات الأخرى المفيدة لضبط أداء التخزين المؤقت لـ FCGI هي fastcgi_cache_background_update والتي تعمل بالتزامن مع توجيه proxy_cache_use_stale. عند تعيينها على وضع التشغيل، توجه NGINX لتقديم المحتوى القديم عندما يطلب العملاء ملفًا منتهي الصلاحية أو يتم تحديثه من الخادم العلوي.

fastcgi_cache_background_update on;
Enable Cache Background Update

كما أن fastcgi_cache_lock مفيدة أيضًا لضبط أداء التخزين المؤقت، بحيث إذا طلب عملاء متعددون نفس المحتوى الذي ليس في الذاكرة المؤقتة، ستقوم NGINX بإرسال الطلب الأول فقط إلى الخادم العلوي، وتخزين الاستجابة ثم تقديم طلبات العملاء الأخرى من الذاكرة المؤقتة.

fastcgi_cache_lock on;
Enable Cache Lock

بعد إجراء جميع التغييرات أعلاه في ملف تكوين NGINX، احفظ الملف وأغلقه. ثم تحقق من بنية التكوين لأي أخطاء في الصياغة قبل إعادة تشغيل خدمة NGINX.

# nginx -t
# systemctl restart nginx
Check and Start Nginx Service

بعد ذلك، اختبر ما إذا كان التخزين المؤقت يعمل بشكل صحيح، حاول الوصول إلى تطبيق الويب الخاص بك أو الموقع من خلال استخدام الأمر curl التالي (يجب أن يشير الوقت الأول إلى MISS، ولكن يجب أن تشير الطلبات اللاحقة إلى HIT كما هو موضح في لقطة الشاشة).

# curl -I http://testapp.tecmint.com
Test FastCGI Cache

إليك لقطة شاشة أخرى تظهر NGINX وهي تقدم بيانات قديمة.

Test Nginx Serving Stale Data

إضافة استثناءات لتجاوز الذاكرة المؤقتة

من الممكن تحديد شروط تحتها يجب عدم إرسال استجابات مخزنة من NGINX إلى العملاء، باستخدام توجيهة fastcgi_cache_bypass. ولإرشاد NGINX بعدم تخزين استجابات من الخادم العلوي على الإطلاق، استخدم fastcgi_no_cache.

على سبيل المثال، إذا أردت أن تذهب الطلبات POST والعناوين مع سلسلة الاستعلام دائمًا إلى PHP. أولاً، قم بتعريف عبارة if لتعيين الشرط على النحو التالي.

set $skip_cache 0; 
if ($request_method = POST) { 
	set $skip_cache 1; 
}

ثم قم بتفعيل الاستثناء أعلاه في توجيهة location التي تمرر طلبات PHP إلى PHP-FPM، باستخدام توجيهات fastcgi_cache_bypass و fastcgi_no_cache.

 
fastcgi_cache_bypass $skip_cache; 
fastcgi_no_cache $skip_cache;

هناك العديد من أجزاء موقعك التي قد لا ترغب في تمكين تخزين المحتوى لها. التالي هو مثال على تكوين NGINX لتحسين أداء موقع WordPress، المقدم على مدونة nginx.com.

لاستخدامه، قم بإجراء التغييرات (مثل النطاق، المسارات، الأسماء، إلخ) لتعكس ما يوجد في بيئتك.

fastcgi_cache_path /var/run/NGINX-cache levels=1:2 keys_zone=WORDPRESS:100m inactive=60m; 
fastcgi_cache_key "$scheme$request_method$host$request_uri"; 
server { 
	server_name example.com www.example.com; 
	root /var/www/example.com; 
	index index.php; 
	access_log /var/log/NGINX/example.com.access.log; 
	error_log /var/log/NGINX/example.com.error.log; 
	set $skip_cache 0; 
	# POST requests and URLs with a query string should always go to PHP 	
	if ($request_method = POST) { 
		set $skip_cache 1; 
	} 
	if ($query_string != "") {
		set $skip_cache 1; 
	} 
	# Don't cache URIs containing the following segments 
	if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php |sitemap(_index)?.xml") { 
		set $skip_cache 1; 
	} 
	# Don't use the cache for logged-in users or recent commenters 
	if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass |wordpress_no_cache|wordpress_logged_in") {
		set $skip_cache 1; 
	} 
	location / { 
		try_files $uri $uri/ /index.php?$args; 
	} 
	location ~ .php$ { 
		try_files $uri /index.php; 
		include fastcgi_params; 
		fastcgi_pass unix:/var/run/php5-fpm.sock; 
		fastcgi_cache_bypass $skip_cache; 
		fastcgi_no_cache $skip_cache; 
		fastcgi_cache WORDPRESS; 
		fastcgi_cache_valid 60m; 
	} 
	location ~ /purge(/.*) {
		fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1"; 
	} 
	location ~* ^.+.(ogg|ogv|svg|svgz|eot|otf|woff|mp4|ttf|css|rss|atom|js|jpg|jpeg |gif|png|ico|zip|tgz|gz|rar|bz2|doc|xls|exe|ppt|tar|mid|midi |wav|bmp|rtf)$ { 
		access_log off; 
		log_not_found off; 
		expires max; 
	} 
	location = /robots.txt { 
		access_log off; 
		log_not_found off; 
	}
	location ~ /. { 
		deny all; 
		access_log off; 
		log_not_found off; 
	} 
}

تمكين تخزين الوكيل في NGINX

NGINX يدعم أيضًا تخزين الاستجابات من خوادم الوكلاء الأخرى (التي يتم تعريفها بواسطة توجيهة proxy_pass). لحالة الاختبار هذه، نحن نستخدم NGINX كوكيل واجهة عكسية لتطبيق ويب Node.js، لذلك سنقوم بتمكين NGINX كذاكرة مؤقتة لتطبيق Node.js. جميع توجيهات التكوين المستخدمة هنا لها معانٍ مماثلة لتوجيهات FastCGI في القسم السابق، لذلك لن نشرحها مرة أخرى.

لتمكين تخزين الاستجابات من خادم وكيل، قم بتضمين التوجيه proxy_cache_path في سياق http{} على مستوى الأعلى. لتحديد كيفية تخزين الطلبات، يمكنك أيضًا إضافة التوجيه proxy_cache_key على النحو التالي.

proxy_cache_path /var/cache/nginx app1 keys_zone=PROXYCACHE:100m inactive=60m max_size=500m;
proxy_cache_key  "$scheme$request_method$host$request_uri";
add_header X-Cache-Status $upstream_cache_status;
proxy_cache_min_uses 3;

ثم، قم بتنشيط التخزين المؤقت في التوجيه المحدد.

location / {
	proxy_pass http://127.0.0.1:3000;
	proxy_cache        PROXYCACHE;
	proxy_cache_valid 200 302 10m;
	proxy_cache_valid 404      1m;
}

لتحديد الشروط التي بموجبها لا يقوم NGINX بإرسال محتوى مخزن ولا يخزن استجابة على الإطلاق من الخادم الفرعي، ضمن التوجيهات proxy_cache_bypass و proxy_no_cache.

 
proxy_cache_bypass  $cookie_nocache $arg_nocache$arg_comment;
proxy_no_cache        $http_pragma $http_authorization;

تهيئة أداء تخزين الوكيل بشكل دقيق

التوجيهات التالية مفيدة لتهيئة أداء تخزين الوكيل بشكل دقيق. كما أن لديها نفس المعاني كتوجيهات FastCGI.

proxy_cache_min_uses 3;
proxy_cache_revalidate on;
proxy_cache_use_stale error timeout updating http_500;
proxy_cache_background_update on;
proxy_cache_lock on;

لمزيد من المعلومات وتوجيهات تهيئة التخزين المؤقت، راجع وثائق الوحدتين الرئيسيتين ngx_http_fastcgi_module و ngx_http_proxy_module.

موارد إضافية: تخزين محتوى NGINX و نصائح لتحسين أداء ووردبريس.

Source:
https://www.tecmint.com/cache-content-with-nginx/