Menggunakan Node.js dengan Nginx untuk melaksanakan network_node.js beban tinggi

Apabila ia datang untuk membina aplikasi web berkemampuan tinggi, NginX dan Node.js adalah padanan semula jadi. Kesemuanya direka bentuk berdasarkan model dipacu acara dan boleh dengan mudah menembusi kesesakan pelayan web tradisional C10K seperti Apache. Konfigurasi lalai sudah boleh mencapai keselarasan tinggi, tetapi jika anda ingin mencapai lebih daripada beribu-ribu permintaan sesaat pada perkakasan murah, masih terdapat beberapa kerja yang perlu dilakukan.

Artikel ini menganggap bahawa pembaca menggunakan HttpProxyModule NginX untuk bertindak sebagai proksi terbalik untuk pelayan node.js huluan. Kami akan memperkenalkan penalaan sysctl dalam sistem Ubuntu 10.04 dan ke atas, serta penalaan aplikasi node.js dan NginX. Sudah tentu, jika anda menggunakan sistem Debian, anda juga boleh mencapai matlamat yang sama, tetapi kaedah penalaan adalah berbeza.

Penalaan Rangkaian

Jika anda tidak memahami terlebih dahulu mekanisme penghantaran asas Nginx dan Node.js dan menjalankan pengoptimuman disasarkan, tidak kira betapa terperinci pengoptimuman kedua-duanya, ia mungkin sia-sia. Secara umumnya, Nginx menghubungkan klien dan aplikasi huluan melalui soket TCP.

Sistem kami mempunyai banyak ambang dan sekatan untuk TCP, yang ditetapkan melalui parameter kernel. Nilai lalai parameter ini selalunya ditetapkan untuk tujuan umum dan tidak dapat memenuhi trafik tinggi dan keperluan hayat pendek pelayan web.

Berikut ialah beberapa parameter yang menjadi calon untuk menala TCP. Untuk menjadikannya berkesan, anda boleh meletakkannya dalam fail /etc/sysctl.conf, atau meletakkannya dalam fail konfigurasi baharu, seperti /etc/sysctl.d/99-tuning.conf, dan kemudian jalankan sysctl -p ke biarkan kernel memuatkan mereka. Kami menggunakan sysctl-cookbook untuk melakukan kerja fizikal ini.

Perlu diambil perhatian bahawa nilai yang disenaraikan di sini adalah selamat untuk digunakan, tetapi masih disyorkan agar anda mengkaji maksud setiap parameter untuk memilih nilai yang lebih sesuai berdasarkan beban, perkakasan dan penggunaan anda.

Serlahkan beberapa perkara penting.

Untuk melayan klien hiliran untuk aplikasi huluan, NginX mesti membuka dua sambungan TCP, satu kepada klien dan satu kepada aplikasi. Apabila pelayan menerima banyak sambungan, port yang tersedia sistem akan cepat habis. Dengan mengubah suai parameter net.ipv4.ip_local_port_range, anda boleh meningkatkan julat port yang tersedia. Jika ralat sedemikian ditemui dalam /var/log/syslog: "kemungkinan SYN banjir pada port 80. Menghantar kuki", ini bermakna sistem tidak dapat mencari port yang tersedia. Meningkatkan parameter net.ipv4.ip_local_port_range boleh mengurangkan ralat ini.

Apabila pelayan perlu bertukar antara sejumlah besar sambungan TCP, sejumlah besar sambungan dalam keadaan TIME_WAIT akan dijana. TIME_WAIT bermakna sambungan itu sendiri ditutup, tetapi sumber belum dikeluarkan. Menetapkan net_ipv4_tcp_tw_reuse kepada 1 membolehkan kernel cuba mengitar semula sambungan apabila ia selamat, yang jauh lebih murah daripada mewujudkan semula sambungan baharu.

Ini ialah masa minimum sambungan dalam keadaan TIME_WAIT mesti menunggu sebelum dikitar semula. Menjadikannya lebih kecil boleh mempercepatkan kitar semula.
Cara menyemak status sambungan

Gunakan netstat:

atau gunakan ss:

Apabila beban pada pelayan web meningkat secara beransur-ansur, kami akan mula menghadapi beberapa batasan aneh NginX. Sambungan terputus dan kernel terus melaporkan banjir SYN. Pada masa ini, purata beban dan penggunaan CPU adalah sangat kecil, dan pelayan jelas boleh mengendalikan lebih banyak sambungan, yang benar-benar mengecewakan.

Selepas siasatan, didapati terdapat banyak sambungan dalam keadaan TIME_WAIT. Ini adalah output daripada salah satu pelayan:

Terdapat 47135 TIME_WAIT sambungan! Lebih-lebih lagi, ia dapat dilihat dari ss bahawa mereka semua adalah sambungan tertutup. Ini menunjukkan bahawa pelayan telah menggunakan kebanyakan port yang tersedia, dan juga membayangkan bahawa pelayan memperuntukkan port baharu untuk setiap sambungan. Penalaan rangkaian membantu sedikit masalah ini, tetapi masih tidak ada port yang mencukupi.

Selepas penyelidikan lanjut, saya menjumpai dokumen tentang arahan keepalive uplink, yang berbunyi:

• Tetapkan bilangan maksimum sambungan kekal-hidup terbiar ke pelayan huluan Sambungan ini akan dikekalkan dalam cache proses pekerja.

Menarik. Secara teorinya, persediaan ini meminimumkan sambungan terbuang dengan menghantar permintaan ke atas sambungan tembolok. Dokumentasi juga menyebut bahawa kita harus menetapkan proxy_http_version kepada "1.1" dan mengosongkan pengepala "Sambungan". Selepas penyelidikan lanjut, saya mendapati bahawa ini adalah idea yang baik, kerana HTTP/1.1 sangat mengoptimumkan penggunaan sambungan TCP berbanding HTTP1.0, dan Nginx menggunakan HTTP/1.0 secara lalai.

Selepas mengubah suai seperti yang dicadangkan dalam dokumen, fail konfigurasi pautan atas kami menjadi seperti ini:

Saya juga mengubah suai tetapan proksi dalam bahagian pelayan seperti yang dicadangkan. Pada masa yang sama, proxy_next_upstream telah ditambahkan untuk melangkau pelayan yang gagal, keepalive_timeout pelanggan telah dilaraskan dan log akses telah dimatikan. Konfigurasi menjadi seperti ini:

Selepas menggunakan konfigurasi baharu, saya mendapati soket yang diduduki oleh pelayan telah dikurangkan sebanyak 90%. Permintaan kini boleh dihantar menggunakan sambungan yang jauh lebih sedikit. Keluaran baharu adalah seperti berikut:

Node.js

Terima kasih kepada reka bentuk dipacu acara yang mengendalikan I/O secara tak segerak, Node.js boleh mengendalikan sejumlah besar sambungan dan permintaan di luar kotak. Walaupun terdapat kaedah penalaan lain, artikel ini akan menumpukan terutamanya pada aspek proses node.js.

Nod adalah satu-benang dan tidak secara automatik menggunakan berbilang teras. Dalam erti kata lain, aplikasi tidak boleh mendapatkan keupayaan penuh pelayan secara automatik.

Mencapai pengelompokan proses Nod

Kami boleh mengubah suai aplikasi supaya ia memotong berbilang benang dan menerima data pada port yang sama, dengan itu membolehkan beban menjangkau berbilang teras. Node mempunyai modul kelompok yang menyediakan semua alatan yang diperlukan untuk mencapai matlamat ini, tetapi menambahkannya pada aplikasi memerlukan banyak kerja manual. Jika anda menggunakan express, eBay mempunyai modul yang dipanggil cluster2 yang boleh digunakan.

Halang penukaran konteks

Apabila menjalankan berbilang proses, anda harus memastikan bahawa setiap teras CPU hanya sibuk dengan satu proses pada satu masa. Secara umumnya, jika CPU mempunyai teras N, kita harus menjana proses aplikasi N-1. Ini memastikan bahawa setiap proses mendapat potongan masa yang munasabah, meninggalkan satu teras percuma untuk penjadual kernel menjalankan tugas lain. Kami juga perlu memastikan bahawa pada asasnya tiada tugas lain selain Node.js dilaksanakan pada pelayan untuk mengelakkan perbalahan CPU.

Kami pernah membuat kesilapan dan menggunakan dua aplikasi node.js pada pelayan, dan kemudian setiap aplikasi membuka proses N-1. Akibatnya, mereka bersaing antara satu sama lain untuk CPU, menyebabkan beban sistem meningkat dengan mendadak. Walaupun pelayan kami semuanya mesin 8 teras, prestasi overhed yang disebabkan oleh penukaran konteks masih dapat dirasai dengan jelas. Penukaran konteks merujuk kepada fenomena di mana CPU menggantung tugas semasa untuk melaksanakan tugas lain. Apabila bertukar, kernel mesti menggantung semua keadaan proses semasa dan kemudian memuatkan dan melaksanakan proses lain. Untuk menyelesaikan masalah ini, kami mengurangkan bilangan proses yang dimulakan oleh setiap aplikasi supaya mereka boleh berkongsi CPU secara adil Akibatnya, beban sistem telah dikurangkan:

Sila perhatikan gambar di atas untuk melihat bagaimana beban sistem (garisan biru) menurun di bawah bilangan teras CPU (garisan merah). Pada pelayan lain, kami melihat perkara yang sama. Memandangkan jumlah beban kerja kekal sama, peningkatan prestasi dalam graf di atas hanya boleh dikaitkan dengan pengurangan suis konteks.