Konfigurasi dan Optimasi Nginx

Artikel ini ditayangkan pada 2 April 2017, sekitar 4 bulan yang lalu. Informasi pada tulisan ini mungkin sudah tidak sesuai.

Nginx merupakan salah satu web server yang sangat populer. Menurut survei yang dilakukan oleh Netcraft pada Januari 2017 lalu, Nginx berada di posisi 3 besar bersama Apache dan Microsoft IIS.

Logo Nginx Logo Nginx

Nginx umum digunakan karena performanya bila dibandingkan dengan beberapa kompetitornya. Meski begitu, saya yang sudah cukup lama menggunakan Nginx masih merasa bahwa performa Nginx yang saya gunakan di blog ini juga terasa “perlu ditingkatkan lagi”.

Apalagi untuk ukuran sebuah blog yang berada di sebuah instance VPS dengan spesifikasi yang tidak begitu besar, meningkatkan kinerja Nginx tentu menjadi sebuah keharusan.

Pada tulisan ini, saya membagikan pengalaman dan konfigurasi Nginx yang saya gunakan. Selain sebagai catatan pribadi, siapa tahu konfigurasi yang saya terapkan ini bisa berguna.

Nginx saya pasang pada Ubuntu 16.10 (Yakkety Yak) dengan menggunakan instalasi standar menggunakan apt-get dari repositori Nginx Mainline. Saya menggunakan Nginx versi 1.11.x (Mainline) karena versi ini adalah versi Mainline selalu terbaru bila dibandingkan dengan Nginx Stable.

Optimasi Dasar

Beberapa hal dasar yang bisa dilakukan adalah menyesuaikan beberapa nilai pada berkas nginx.conf. Berikut ini beberapa nilai yang harus diperhatikan.

Worker Processes

Angka pada worker processes dihitung dari jumlah core CPU yang digunakan. Pada instance yang saya gunakan, jumlah core prosesornya 1, maka nilai dari worker processes ini adalah 1.

Arti dari worker processes adalah Nginx akan menyerahkan 1 proses worker ke 1 CPU.

Nilai auto juga bisa dipakai agar Nginx secara otomatis menyesuaikan jumlah worker sesuai dengan jumlah CPU.

worker_processes 1;
# worker_processes auto; # Gunakan auto untuk nilai yang aman

Untuk mengetahui jumlah core CPU yang digunakan, bisa menggunakan perintah grep ^processor /proc/cpuinfo | wc -l dari console.

Worker Connections

Nilai worker connections merupakan jumlah koneksi maksimal yang bisa diproses dalam satu waktu oleh masing-masing proses worker. Secara default, nilai worker connections adalah 512, namun di beberapa sistem, angka ini bisa diset lebih tinggi.

Untuk mengetahui batas maksimal yang bisa ditangani oleh sistem, gunakan perintah ulimit -n. Pada instance yang saya gunakan, nilainya adalah 1024. Masukkan angka ini pada bagian worker connections.

Untuk menangani jumlah koneksi yang besar secara optimal, gunakan epoll, sebuah sistem notifikasi event yang mengatur penggunaan I/O (input/output).

Supaya worker bisa menerima semua koneksi pada saat yang bersamaan, aktifkan multi accept pada konfigurasi.

events {
    worker_connections  1024;
    use epoll;
    multi_accept on;
}

HTTP dan TCP

Bagian ini mengatur bagaimana sebuah koneksi HTTP dilakukan. Keep alive timeout mengatur jangka waktu sebuah koneksi dipertahankan, sedangkan keep alive requests mengatur jumlah request yang akan dipertahankan.

Untuk melayani berkas statis seperti gambar, berkas CSS, dan berkas JS dengan optimal, send file wajib dinyalakan.

TCP no delay mengizinkan Nginx mengirimkan paket TCP secara bersama-sama dalam paket-paket kecil. TCP no push mengoptimalkan jumlah data yang dikirim melalui TCP.

http {
    keepalive_timeout   65;
    keepalive_requests  1000;
    sendfile    on;
    tcp_nopush  on;
    tcp_nodelay on;
}

Ukuran Buffers dan Timeouts

Jika ukuran buffer terlalu kecil, maka Nginx akan membuat sebuah berkas sementara, yang akan mempengaruhi performa karena melibatkan I/O media penyimpan (hard disk atau SSD).

Client body buffer size menangani ukuran buffer sebuah klien. Buffer ini sebagian besar berasal dari variabel POST. Ukuran buffer sebesar 128k sudah cukup.

Client max body size menentukan besar maksimal buffer, biasanya digunakan saat mengunggah berkas. Jika sebuah request ukurannya lebih besar dari nilai ini, pesan kesalahan HTTP 413 (request entity too large) akan dikirimkan. Jika nilai ini diset ke 0 maka Nginx tidak akan melakukan pemeriksaan terhadap ukuran request. Jika menggunakan PHP, pastikan angka ini sama dengan nilai upload max filesize di php.ini

Client header buffer size menentukan ukuran header buffer. Ukuran yang cukup adalah 1k. Large client header buffers menentukan jumlah dan ukuran maksimal sebuah header dari klien yang besar. Jumlah 4 header dengan 4k buffer sudah cukup.

Output buffers menentukan jumlah dan ukuran sebuah buffer yang digunakan untuk membaca respon dari disk. Jika memungkinkan, pengiriman data akan ditunda sampai Nginx mendapat jumlah data tertentu.

Client body timeout menentukan waktu tunggu sebelum Nginx mengirimkan hasil ke klien. Client header timeout menentukan waktu tunggu sebelum header respon dikirim ke klien. Jika tidak ada header atau body yang dikirim, Nginx akan mengirim pesan kesalahan HTTP 408 (request time out).

Send timeout menentukan waktu pengiriman respon ke klien. Jika klien tidak membaca data yang dikirimkan pada jangka waktu tertentu, Nginx akan memutuskan koneksi ke klien.

Untuk mengurangi kemungkinan gateway timed out, perpanjang waktu tunggu proxy dan fast CGI yang dipakai.

http {
    client_body_buffer_size     128k;
    client_max_body_size        20m;
    client_header_buffer_size   1k;
    large_client_header_buffers 4 4k;
    output_buffers              1 32k;
    postpone_output             1460;
    client_header_timeout       60s;
    client_body_timeout         60s;
    send_timeout                60s;
}

server {
    location / {
        proxy_read_timeout 150;
    }

    location ~* .php$ {
        fastcgi_read_timeout 150;
    }
}

Kompresi Dengan Gzip

Berkas yang berupa teks, termasuk XML, JSON, CSS, dan JS, bisa dikompresi dengan gzip sehingga ukuran data yang dikirimkan menjadi lebih kecil. Peramban modern biasanya telah mendukung kompresi gzip ini.

http {
    gzip on;
    gzip_disable "msie6";
    gzip_vary on;
    gzip_proxied any;
    gzip_comp_level 6;
    gzip_buffers 16 32k;
    gzip_http_version 1.1;
    gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
}

Menggunakan Cache

Pada berkas statis seperti gambar, berkas CSS, dan berkas JS, gunakan cache agar berkas-berkas ini disimpan pada peramban dan menggunakannya jika halaman yang sama dibuka kembali.

Tidak seperti pada pengaturan di atas di mana pengaturan dilakukan di berkas nginx.conf pada blok event dan http, pengaturan cache ini diletakkan pada blok server pada berkas pengaturan virtual host.

Pengaturan cache dilakukan dengan melakukan pengesetan header pada berkas dengan ekstensi tertentu.

server {
    # Feed
    location ~* \.(?:rss|atom)$ {
        expires 1h;
        add_header Cache-Control "public";
    }
    
    # Media: images, icons, video, audio, HTC
    location ~* \.(?:jpg|jpeg|gif|png|ico|cur|gz|svg|svgz|mp4|ogg|ogv|webm|htc)$ {
        expires 1y;
        access_log off;
        add_header Cache-Control "public";
    }
    
    # CSS dan Javascript
    location ~* \.(?:css|js)$ {
        expires 1y;
        access_log off;
        add_header Cache-Control "public";
    }

    # Media: fonts
    location ~* \.(?:eot|ttf|woff|woff2)$ {
        expires 1y;
        access_log off;
        add_header Cache-Control "public";
    }
}

Konfigurasi lengkap berkas nginx.conf bisa dilihat di Github.

Template Konfigurasi Nginx

Untuk kemudahan, saya mempublikasikan template konfigurasi Nginx yang bisa digunakan di Github. Konfigurasi ini saya gunakan untuk dokumentasi pribadi.

Silakan gunakan dan sesuaikan dengan kebutuhan dan konfigurasi server yang digunakan. Karena berkas ini saya gunakan pada Ubuntu, kemungkinan jika menggunakan sistem operasi lain seperti Centos atau yang lainnya, perlu ada penyesuaian lebih lanjut. Namun secara garis besar, konfigurasi ini bisa digunakan.

Konfigurasi virtual hosts saya letakkan di direktori conf.d mengikuti gaya Ubuntu. Beberapa konfigurasi saya pecah dan saya letakkan di direktori includes, seperti pada pengaturan php-fpm dan pengaturan lokasi root directory.

Muhammad Zamroni

pengembang web • penyelam scuba • pejalan pemula • peminat perangkat

Jakarta, Indonesia

1 komentar

Artikel ini ditayangkan pada 2 April 2017, sekitar 4 bulan yang lalu. Informasi pada tulisan ini mungkin sudah tidak sesuai.

Yeni Setiawan

2 April 2017 22:25

#heker

Statistik

Telah dibaca 86 kali. Waktu baca rata-rata 9 menit. Ada 1 komentar.