Kubernetes ٹپس اور ٹرکس: NGINX اور PHP-FPM میں شاندار بند کی خصوصیات

Kubernetes میں CI/CD کو لاگو کرتے وقت ایک عام شرط: ایپلیکیشن کو مکمل طور پر رکنے سے پہلے کلائنٹ کی نئی درخواستوں کو قبول نہ کرنے کے قابل ہونا چاہیے، اور سب سے اہم بات یہ ہے کہ موجودہ درخواستوں کو کامیابی کے ساتھ مکمل کرے۔

اس شرط کی تعمیل آپ کو تعیناتی کے دوران صفر ڈاؤن ٹائم حاصل کرنے کی اجازت دیتی ہے۔ تاہم، بہت مقبول بنڈلز (جیسے NGINX اور PHP-FPM) استعمال کرتے وقت بھی، آپ کو ایسی مشکلات کا سامنا کرنا پڑ سکتا ہے جو ہر تعیناتی کے ساتھ غلطیوں میں اضافے کا باعث بنیں گی...

نظریہ. پوڈ کیسے رہتا ہے

ہم پھلی کے لائف سائیکل کے بارے میں پہلے ہی تفصیل سے شائع کر چکے ہیں۔ اس مضمون. زیر نظر موضوع کے تناظر میں، ہم مندرجہ ذیل میں دلچسپی رکھتے ہیں: اس وقت جب پھلی ریاست میں داخل ہوتی ہے۔ ختم کرنا، نئی درخواستیں اس کو بھیجنا بند کر دیں (pod ہٹا دیا سروس کے اختتامی مقامات کی فہرست سے)۔ اس طرح، تعیناتی کے دوران ڈاؤن ٹائم سے بچنے کے لیے، ہمارے لیے ایپلیکیشن کو درست طریقے سے روکنے کے مسئلے کو حل کرنا کافی ہے۔

آپ کو یہ بھی یاد رکھنا چاہیے کہ ڈیفالٹ رعایتی مدت ہے۔ 30 سیکنڈ: اس کے بعد، پوڈ کو ختم کر دیا جائے گا اور درخواست کے پاس اس مدت سے پہلے تمام درخواستوں پر کارروائی کرنے کا وقت ہونا چاہیے۔ نوٹ: اگرچہ کوئی بھی درخواست جس میں 5-10 سیکنڈ سے زیادہ وقت لگتا ہے پہلے سے ہی پریشانی کا شکار ہے، اور خوبصورت شٹ ڈاؤن اب اس کی مدد نہیں کرے گا...

بہتر طور پر سمجھنے کے لیے کہ جب پوڈ ختم ہوتا ہے تو کیا ہوتا ہے، صرف درج ذیل خاکہ کو دیکھیں:

A1، B1 - چولہا کی حالت کے بارے میں تبدیلیاں وصول کرنا
A2 - روانگی SIGTERM
B2 - اختتامی مقامات سے پوڈ کو ہٹانا
B3 - تبدیلیاں موصول ہو رہی ہیں (اختتام کے مقامات کی فہرست بدل گئی ہے)
B4 - iptables کے قواعد کو اپ ڈیٹ کریں۔

براہ کرم نوٹ کریں: اختتامی پوڈ کو حذف کرنا اور SIGTERM بھیجنا ترتیب وار نہیں ہوتا، بلکہ متوازی طور پر ہوتا ہے۔ اور اس حقیقت کی وجہ سے کہ Ingress کو فوری طور پر اینڈ پوائنٹس کی تازہ ترین فہرست موصول نہیں ہوتی، کلائنٹس کی جانب سے نئی درخواستیں پوڈ کو بھیجی جائیں گی، جو پوڈ کے خاتمے کے دوران 500 غلطی کا سبب بنے گی۔ (اس مسئلے پر مزید تفصیلی مواد کے لیے، ہم ترجمہ). اس مسئلے کو درج ذیل طریقوں سے حل کرنے کی ضرورت ہے۔

• کنکشن بھیجیں: جوابی ہیڈر میں بند کریں (اگر یہ HTTP ایپلیکیشن سے متعلق ہے)۔
• اگر کوڈ میں تبدیلیاں کرنا ممکن نہیں ہے، تو درج ذیل مضمون میں ایک حل بیان کیا گیا ہے جو آپ کو شاندار مدت کے اختتام تک درخواستوں پر کارروائی کرنے کی اجازت دے گا۔

نظریہ. NGINX اور PHP-FPM اپنے عمل کو کیسے ختم کرتے ہیں۔

این جی این ایکس

آئیے NGINX کے ساتھ شروع کریں، کیونکہ اس کے ساتھ سب کچھ کم و بیش واضح ہے۔ نظریہ میں غوطہ لگاتے ہوئے، ہم یہ سیکھتے ہیں کہ NGINX میں ایک ماسٹر پروسیس اور کئی "کارکن" ہوتے ہیں - یہ بچے کے عمل ہیں جو کلائنٹ کی درخواستوں پر کارروائی کرتے ہیں۔ ایک آسان آپشن فراہم کیا گیا ہے: کمانڈ کا استعمال کرتے ہوئے nginx -s <SIGNAL> یا تو تیز شٹ ڈاؤن یا خوبصورت شٹ ڈاؤن موڈ میں عمل کو ختم کریں۔ ظاہر ہے، یہ مؤخر الذکر آپشن ہے جو ہماری دلچسپی کا باعث ہے۔

پھر سب کچھ آسان ہے: آپ کو شامل کرنے کی ضرورت ہے۔ preStop-hook ایک کمانڈ جو ایک خوبصورت شٹ ڈاؤن سگنل بھیجے گی۔ یہ کنٹینر بلاک میں تعیناتی میں کیا جا سکتا ہے:

       lifecycle:
          preStop:
            exec:
              command:
              - /usr/sbin/nginx
              - -s
              - quit

اب، جب پوڈ بند ہو جائے گا، ہم NGINX کنٹینر لاگ میں درج ذیل دیکھیں گے:

2018/01/25 13:58:31 [notice] 1#1: signal 3 (SIGQUIT) received, shutting down
2018/01/25 13:58:31 [notice] 11#11: gracefully shutting down

اور اس کا مطلب یہ ہوگا کہ ہمیں کیا ضرورت ہے: NGINX درخواستوں کے مکمل ہونے کا انتظار کرتا ہے، اور پھر اس عمل کو ختم کر دیتا ہے۔ تاہم، ذیل میں ہم ایک عام مسئلہ پر بھی غور کریں گے جس کی وجہ سے، کمانڈ کے ساتھ بھی nginx -s quit عمل غلط طریقے سے ختم ہو جاتا ہے.

اور اس مرحلے پر ہم NGINX کے ساتھ کام کر چکے ہیں: کم از کم لاگز سے آپ سمجھ سکتے ہیں کہ سب کچھ ویسا ہی کام کر رہا ہے جیسا کہ ہونا چاہیے۔

PHP-FPM کے ساتھ کیا معاملہ ہے؟ یہ خوبصورت بند کو کیسے ہینڈل کرتا ہے؟ آئیے اس کا پتہ لگائیں۔

پی ایچ پی - ایف پی ایم

PHP-FPM کے معاملے میں، تھوڑی کم معلومات ہے۔ اگر آپ توجہ مرکوز کرتے ہیں سرکاری دستی PHP-FPM کے مطابق، یہ کہے گا کہ درج ذیل POSIX سگنلز قبول کیے گئے ہیں:

1. SIGINT, SIGTERM - تیزی سے بند؛
2. SIGQUIT - خوبصورت بند (ہمیں کیا ضرورت ہے)۔

اس کام میں باقی سگنلز کی ضرورت نہیں ہے، اس لیے ہم ان کے تجزیہ کو چھوڑ دیں گے۔ عمل کو صحیح طریقے سے ختم کرنے کے لیے، آپ کو درج ذیل preStop ہک لکھنے کی ضرورت ہوگی:

        lifecycle:
          preStop:
            exec:
              command:
              - /bin/kill
              - -SIGQUIT
              - "1"

پہلی نظر میں، دونوں کنٹینرز میں خوبصورت شٹ ڈاؤن انجام دینے کے لیے یہ سب کچھ درکار ہے۔ تاہم، کام لگتا ہے سے کہیں زیادہ مشکل ہے. ذیل میں دو ایسے معاملات ہیں جن میں شاندار شٹ ڈاؤن کام نہیں کر سکا اور تعیناتی کے دوران پراجیکٹ کی قلیل مدتی عدم دستیابی کا سبب بنا۔

مشق کریں۔ مکرم شٹ ڈاؤن کے ساتھ ممکنہ مسائل

این جی این ایکس

سب سے پہلے، یہ یاد رکھنا مفید ہے: کمانڈ پر عمل کرنے کے علاوہ nginx -s quit ایک اور مرحلہ ہے جس پر توجہ دینے کے قابل ہے۔ ہمیں ایک مسئلہ کا سامنا کرنا پڑا جہاں NGINX اب بھی SIGQUIT سگنل کے بجائے SIGTERM بھیجے گا، جس کی وجہ سے درخواستیں درست طریقے سے مکمل نہیں ہو پا رہی ہیں۔ اسی طرح کے معاملات مل سکتے ہیں، مثال کے طور پر، یہاں. بدقسمتی سے، ہم اس رویے کی مخصوص وجہ کا تعین کرنے سے قاصر تھے: NGINX ورژن کے بارے میں ایک شبہ تھا، لیکن اس کی تصدیق نہیں ہوئی۔ علامت یہ تھی کہ NGINX کنٹینر لاگ میں پیغامات دیکھے گئے: "اوپن ساکٹ #10 کنکشن 5 میں باقی ہے"، جس کے بعد پھلی رک گئی۔

ہم اس طرح کے مسئلے کا مشاہدہ کر سکتے ہیں، مثال کے طور پر، Ingress پر ہمیں درکار جوابات سے:

تعیناتی کے وقت اسٹیٹس کوڈز کے اشارے

اس صورت میں، ہمیں Ingress سے صرف ایک 503 ایرر کوڈ موصول ہوتا ہے: یہ NGINX کنٹینر تک رسائی حاصل نہیں کر سکتا، کیونکہ یہ اب قابل رسائی نہیں ہے۔ اگر آپ NGINX کے ساتھ کنٹینر لاگز کو دیکھیں تو ان میں درج ذیل ہیں:

[alert] 13939#0: *154 open socket #3 left in connection 16
[alert] 13939#0: *168 open socket #6 left in connection 13

سٹاپ سگنل کو تبدیل کرنے کے بعد، کنٹینر صحیح طریقے سے رکنا شروع ہو جاتا ہے: اس کی تصدیق اس حقیقت سے ہوتی ہے کہ 503 کی خرابی اب نظر نہیں آتی۔

اگر آپ کو بھی اسی طرح کا مسئلہ درپیش ہے، تو یہ سمجھنا سمجھ میں آتا ہے کہ کنٹینر میں کون سا سٹاپ سگنل استعمال ہوتا ہے اور پری اسٹاپ ہک بالکل کیسا لگتا ہے۔ یہ بہت ممکن ہے کہ اس کی وجہ بالکل اسی میں مضمر ہو۔

PHP-FPM... اور مزید

PHP-FPM کے ساتھ مسئلہ کو معمولی انداز میں بیان کیا گیا ہے: یہ چائلڈ پروسیسز کے مکمل ہونے کا انتظار نہیں کرتا، یہ انہیں ختم کر دیتا ہے، یہی وجہ ہے کہ تعیناتی اور دیگر کارروائیوں کے دوران 502 غلطیاں ہوتی ہیں۔ bugs.php.net پر 2005 سے کئی بگ رپورٹس موجود ہیں (مثلاً یہاں и یہاں)، جو اس مسئلہ کو بیان کرتا ہے۔ لیکن غالباً آپ کو لاگز میں کچھ نظر نہیں آئے گا: PHP-FPM بغیر کسی غلطی یا فریق ثالث کی اطلاع کے اپنے عمل کی تکمیل کا اعلان کرے گا۔

یہ واضح کرنے کے قابل ہے کہ مسئلہ خود ایپلی کیشن پر کم یا زیادہ حد تک منحصر ہوسکتا ہے اور خود کو ظاہر نہیں کرسکتا ہے، مثال کے طور پر، نگرانی میں. اگر آپ اس کا سامنا کرتے ہیں تو، سب سے پہلے ایک سادہ حل ذہن میں آتا ہے: اس کے ساتھ ایک پری اسٹاپ ہک شامل کریں۔ sleep(30). یہ آپ کو ان تمام درخواستوں کو مکمل کرنے کی اجازت دے گا جو پہلے تھیں (اور ہم نئی درخواستوں کو قبول نہیں کرتے ہیں، چونکہ پوڈ پہلے ہی حالت میں ختم کرنا)، اور 30 ​​سیکنڈ کے بعد پوڈ خود ایک سگنل کے ساتھ ختم ہو جائے گا۔ SIGTERM.

یہ پتہ چلا ہے کہ lifecycle کنٹینر کے لئے اس طرح نظر آئے گا:

    lifecycle:
      preStop:
        exec:
          command:
          - /bin/sleep
          - "30"

تاہم، 30 سیکنڈ کی وجہ سے sleep ہم ہیں زیادہ ہم تعیناتی کے وقت میں اضافہ کریں گے، کیونکہ ہر پوڈ کو ختم کر دیا جائے گا۔ کم سے کم 30 سیکنڈ، جو برا ہے۔ اس بارے میں کیا کیا جا سکتا ہے؟

آئیے درخواست پر براہ راست عمل درآمد کے لیے ذمہ دار فریق کی طرف رجوع کرتے ہیں۔ ہمارے معاملے میں یہ ہے۔ پی ایچ پی - ایف پی ایمکون سا پہلے سے طے شدہ طور پر اس کے بچے کے عمل کے نفاذ کی نگرانی نہیں کرتا ہے۔: ماسٹر عمل فوری طور پر ختم کر دیا جاتا ہے. آپ ہدایت کا استعمال کرتے ہوئے اس طرز عمل کو تبدیل کر سکتے ہیں۔ process_control_timeout، جو ماسٹر کی طرف سے سگنلز کا انتظار کرنے کے لیے بچوں کے عمل کے لیے وقت کی حد متعین کرتا ہے۔ اگر آپ قیمت کو 20 سیکنڈ پر سیٹ کرتے ہیں، تو یہ کنٹینر میں چلنے والے زیادہ تر سوالات کا احاطہ کرے گا اور ان کے مکمل ہونے کے بعد ماسٹر عمل کو روک دے گا۔

اس علم کے ساتھ، آئیے اپنے آخری مسئلے کی طرف لوٹتے ہیں۔ جیسا کہ ذکر کیا گیا ہے، Kubernetes ایک یک سنگی پلیٹ فارم نہیں ہے: اس کے مختلف اجزاء کے درمیان رابطے میں کچھ وقت لگتا ہے۔ یہ خاص طور پر سچ ہے جب ہم Ingresses اور دیگر متعلقہ اجزاء کے آپریشن پر غور کرتے ہیں، کیونکہ تعیناتی کے وقت اتنی تاخیر کی وجہ سے 500 غلطیوں کا اضافہ کرنا آسان ہے۔ مثال کے طور پر، اپ اسٹریم کو درخواست بھیجنے کے مرحلے پر ایک خرابی واقع ہوسکتی ہے، لیکن اجزاء کے درمیان تعامل کا "ٹائم لیگ" کافی مختصر ہے - ایک سیکنڈ سے بھی کم۔

لہذا، کل ملا کر پہلے ہی ذکر کردہ ہدایت کے ساتھ process_control_timeout آپ مندرجہ ذیل تعمیرات کے لیے استعمال کر سکتے ہیں۔ lifecycle:

lifecycle:
  preStop:
    exec:
      command: ["/bin/bash","-c","/bin/sleep 1; kill -QUIT 1"]

اس صورت میں، ہم حکم کے ساتھ تاخیر کی تلافی کریں گے۔ sleep اور تعیناتی کے وقت میں بہت زیادہ اضافہ نہ کریں: کیا 30 سیکنڈ اور ایک کے درمیان کوئی واضح فرق ہے؟... حقیقت میں، یہ ہے process_control_timeoutاور lifecycle وقفہ کی صورت میں صرف "حفاظتی جال" کے طور پر استعمال کیا جاتا ہے۔

عام طور پر بیان کردہ طرز عمل اور متعلقہ کام کا اطلاق نہ صرف PHP-FPM پر ہوتا ہے۔. دوسری زبانیں/فریم ورک استعمال کرتے وقت اسی طرح کی صورتحال کسی نہ کسی طریقے سے پیدا ہو سکتی ہے۔ اگر آپ دوسرے طریقوں سے خوبصورت شٹ ڈاؤن کو ٹھیک نہیں کر سکتے ہیں - مثال کے طور پر، کوڈ کو دوبارہ لکھ کر تاکہ ایپلیکیشن درست طریقے سے برطرفی کے سگنلز پر کارروائی کرے - آپ بیان کردہ طریقہ استعمال کر سکتے ہیں۔ یہ سب سے خوبصورت نہیں ہوسکتا ہے، لیکن یہ کام کرتا ہے.

مشق کریں۔ پوڈ کے آپریشن کو چیک کرنے کے لیے لوڈ ٹیسٹنگ

لوڈ ٹیسٹنگ یہ جانچنے کے طریقوں میں سے ایک ہے کہ کنٹینر کیسے کام کرتا ہے، کیونکہ یہ طریقہ کار اسے حقیقی جنگی حالات کے قریب لاتا ہے جب صارفین سائٹ پر جاتے ہیں۔ مندرجہ بالا سفارشات کو جانچنے کے لیے، آپ استعمال کر سکتے ہیں۔ Yandex.Tankom: یہ ہماری تمام ضروریات کو بالکل پورا کرتا ہے۔ ہمارے تجربے سے ایک واضح مثال کے ساتھ ٹیسٹ کرنے کے لیے درج ذیل نکات اور سفارشات ہیں، بذات خود Grafana اور Yandex.Tank کے گراف کی بدولت۔

یہاں سب سے اہم بات یہ ہے۔ قدم بہ قدم تبدیلیاں چیک کریں۔. ایک نیا فکس شامل کرنے کے بعد، ٹیسٹ چلائیں اور دیکھیں کہ آخری رن کے مقابلے میں نتائج تبدیل ہوئے ہیں یا نہیں۔ دوسری صورت میں، غیر موثر حل کی نشاندہی کرنا مشکل ہو جائے گا، اور طویل مدت میں یہ صرف نقصان پہنچا سکتا ہے (مثال کے طور پر، تعیناتی کے وقت میں اضافہ)۔

ایک اور اہم بات یہ ہے کہ کنٹینر لاگز کو اس کے ختم ہونے کے دوران دیکھنا ہے۔ کیا مکرم شٹ ڈاؤن کے بارے میں معلومات وہاں ریکارڈ کی گئی ہیں؟ کیا دوسرے وسائل (مثال کے طور پر، پڑوسی PHP-FPM کنٹینر تک) تک رسائی کرتے وقت لاگز میں کوئی خرابی ہے؟ درخواست میں ہی غلطیاں (جیسا کہ اوپر بیان کردہ NGINX کے معاملے میں)؟ مجھے امید ہے کہ اس مضمون کی تعارفی معلومات آپ کو بہتر طور پر یہ سمجھنے میں مدد کرے گی کہ کنٹینر کے ختم ہونے کے دوران اس کا کیا ہوتا ہے۔

لہذا، پہلا ٹیسٹ رن بغیر ہوا lifecycle اور ایپلیکیشن سرور کے لیے اضافی ہدایات کے بغیر (process_control_timeout PHP-FPM میں)۔ اس ٹیسٹ کا مقصد غلطیوں کی تخمینی تعداد کی شناخت کرنا تھا (اور آیا کوئی ہے)۔ اس کے علاوہ، اضافی معلومات سے، آپ کو معلوم ہونا چاہیے کہ ہر پوڈ کے لیے تعیناتی کا اوسط وقت تقریباً 5-10 سیکنڈ تھا جب تک کہ یہ مکمل طور پر تیار نہ ہو جائے۔ نتائج یہ ہیں:

Yandex.Tank انفارمیشن پینل 502 خرابیوں کا اضافہ دکھاتا ہے، جو تعیناتی کے وقت پیش آیا اور اوسطاً 5 سیکنڈ تک جاری رہا۔ غالباً اس کی وجہ یہ تھی کہ پرانے پوڈ کی موجودہ درخواستوں کو اس وقت ختم کیا جا رہا تھا جب اسے ختم کیا جا رہا تھا۔ اس کے بعد، 503 غلطیاں نمودار ہوئیں، جو کہ ایک رکے ہوئے NGINX کنٹینر کا نتیجہ تھی، جس نے بیک اینڈ کی وجہ سے کنکشن بھی گرا دیا (جس نے Ingress کو اس سے منسلک ہونے سے روکا)۔

آئیے دیکھتے ہیں کہ کیسے process_control_timeout PHP-FPM میں بچوں کے عمل کے مکمل ہونے کا انتظار کرنے میں ہماری مدد کرے گا، یعنی ایسی غلطیوں کو درست کریں۔ اس ہدایت کا استعمال کرتے ہوئے دوبارہ تعینات کریں:

500 ویں تعیناتی کے دوران مزید غلطیاں نہیں ہیں! تعیناتی کامیاب ہے، شاندار شٹ ڈاؤن کام کرتا ہے۔

تاہم، یہ Ingress کنٹینرز کے مسئلے کو یاد رکھنے کے قابل ہے، غلطیوں کا ایک چھوٹا فیصد جس میں ہمیں وقت کے وقفے کی وجہ سے موصول ہو سکتا ہے۔ ان سے بچنے کے لیے، جو کچھ باقی ہے وہ اس کے ساتھ ایک ڈھانچہ شامل کرنا ہے۔ sleep اور تعیناتی کو دہرائیں۔ تاہم، ہمارے خاص معاملے میں، کوئی تبدیلی نظر نہیں آئی (دوبارہ، کوئی غلطی نہیں)۔

حاصل يہ ہوا

عمل کو احسن طریقے سے ختم کرنے کے لیے، ہم درخواست سے درج ذیل رویے کی توقع کرتے ہیں:

1. چند سیکنڈ انتظار کریں اور پھر نئے کنکشن قبول کرنا بند کریں۔
2. تمام درخواستوں کے مکمل ہونے کا انتظار کریں اور ان تمام محفوظ کنکشنز کو بند کریں جو درخواستوں پر عمل نہیں کر رہے ہیں۔
3. اپنا عمل ختم کریں۔

تاہم، تمام ایپلیکیشنز اس طرح کام نہیں کر سکتیں۔ Kubernetes حقائق میں مسئلہ کا ایک حل یہ ہے:

• ایک پری اسٹاپ ہک شامل کرنا جو چند سیکنڈ انتظار کرے گا۔
• مناسب پیرامیٹرز کے لیے ہمارے بیک اینڈ کی کنفیگریشن فائل کا مطالعہ کرنا۔

NGINX کے ساتھ مثال یہ واضح کرتی ہے کہ ایک ایسی ایپلیکیشن بھی جسے ابتدائی طور پر ختم کرنے کے سگنلز کو درست طریقے سے پروسیس کرنا چاہیے ایسا نہیں کر سکتا، اس لیے ایپلیکیشن کی تعیناتی کے دوران 500 غلطیوں کی جانچ کرنا ضروری ہے۔ یہ آپ کو مسئلہ کو زیادہ وسیع طور پر دیکھنے اور کسی ایک پوڈ یا کنٹینر پر توجہ مرکوز کرنے کی اجازت نہیں دیتا ہے، بلکہ پورے بنیادی ڈھانچے کو مجموعی طور پر دیکھتا ہے۔

ٹیسٹنگ ٹول کے طور پر، آپ Yandex.Tank کو کسی بھی مانیٹرنگ سسٹم کے ساتھ استعمال کر سکتے ہیں (ہمارے معاملے میں، ٹیسٹ کے لیے ڈیٹا گرافانا سے پرومیتھیس بیک اینڈ کے ساتھ لیا گیا تھا)۔ خوبصورت شٹ ڈاؤن کے ساتھ مسائل واضح طور پر بھاری بوجھ کے تحت نظر آتے ہیں جو بینچ مارک پیدا کر سکتا ہے، اور نگرانی ٹیسٹ کے دوران یا اس کے بعد صورتحال کا مزید تفصیل سے تجزیہ کرنے میں مدد کرتی ہے۔

مضمون پر رائے کے جواب میں: یہ بات قابل ذکر ہے کہ یہاں NGINX Ingress کے سلسلے میں مسائل اور حل بیان کیے گئے ہیں۔ دیگر معاملات کے لیے، اور بھی حل ہیں، جن پر ہم سیریز کے درج ذیل مواد میں غور کر سکتے ہیں۔

PS

K8s ٹپس اینڈ ٹرکس سیریز سے دیگر:

• «NGINX Ingress میں حسب ضرورت خرابی والے صفحات؛ "
• «ویب ایپلیکیشن پر نوڈ ایلوکیشن اور لوڈ کے بارے میں؛ "
• «ڈیو سائٹس تک رسائی؛ "
• «بڑے ڈیٹا بیس کے لیے بوٹسٹریپ کو تیز کرنا'.

ماخذ: www.habr.com