يخدم Nginx آلاف الاتّصالات لكلّ عامل بلا جهد. فإن كان موقعك بطيئًا فهو ينتظر PHP أو قاعدة البيانات خلفه في الغالب الأعمّ. ورفعُ هذه الأرقام ينقل الطابور ولا يقصّره.
الرقمان
worker_processes auto; # one per CPU core - leave it
events {
worker_connections 1024; # per worker
multi_accept on;
}auto يطابق عدد الأنوية، وهو الجواب الصحيح على كلّ جهاز دون الجهاز الشديد الغرابة. والسعة الكلّيّة هي العمّال مضروبين في الاتّصالات، والمتصفّح الذي يفتح عدّة اتّصالات لموقع واحد يُحسَب عدّة مرّات.
الخطأ الذي يعني ارفعه
grep "worker_connections are not enough" /var/log/nginx/error.logهذا السطر، وهذا السطر وحده، سببٌ لرفع الرقم. وبدونه فالحدُّ ليس هو ما تصطدم به.
ما يكون الحدَّ الحقيقيَّ عادةً
- أبناء PHP-FPM — الطابور هناك لا في Nginx. انظر قياس حوض PHP-FPM.
- اتّصالات قاعدة البيانات — انظر اتّصالات أكثر من اللازم.
- الملفّات المفتوحة — يبلغ العامل حدَّ النظام قبل حدِّه هو بكثير.
# the one worth raising, with the connections
worker_rlimit_nofile 65535;أعد التحميل للتطبيق، لا التشغيل أبدًا
sudo nginx -t && sudo systemctl reload nginxإعادة التحميل تبدأ عمّالًا جددًا للاتّصالات الجديدة وتدع القدامى يُتمّون. وإعادة التشغيل تُسقط ما في الطريق، وذلك على موقعٍ مزدحم خطأٌ يراه أحدهم بعينه.