Untuk mengkonfigurasi HTTPS server, Anda harus mengaktifkan protokol SSL di blok server, dan menuliskan lokasi dari berkas server certificate dan private key:

server {
    listen               443;
    server_name          www.nginx.com;
    ssl                  on;
    ssl_certificate      www.nginx.com.crt;
    ssl_certificate_key  www.nginx.com.key;
    ssl_protocols        SSLv3 TLSv1;
    ssl_ciphers          HIGH:!ADH:!MD5;
    ...
}

Server certificate adalah entitas publik. Ini akan dikirim ke setiap klien yang terhubung ke server. Sedangkan private key adalah entitas keamanan dan harus disimpan dalam berkas dengan akses terbatas, tapi walau terbatas harus bisa dibaca oleh master proses nginx. Private key bisa juga disimpan dalam berkas sama sebagai certificate:

    ssl_certificate      www.nginx.com.cert;
    ssl_certificate_key  www.nginx.com.cert;

yang dalam kasus ini akses ke berkas juga harus dibatasi. Meskipun sertifikat dan kuncinya disimpan dalam satu berkas, hanya bagian certificate yang akan dikirim ke klien.

Direktif “ssl_protocols” dan “ssl_chipers” mungkin bisa digunakan untuk membatasi koneksi ke versi aman/kuat (strong) protokol SSL dan chipers. Sejak versi 0.8.20, nginx menggunakan “ssl_protocols SSLv3 TLSv1” dan “ssl_chipers HIGH:!ADH:!MD5” pada konfigurasi default, jadi semua itu hanya harus diset jika menggunakan versi nginx sebelumnya.

Optimasi HTTPS server

Operasi SSL mengkonsumsi sumberdaya CPU lebih banyak. Pada sistem multi prosesor Anda sebaiknya menjalankan beberapa worker processes: tidak lebih sedikit dari jumlah CPU core yang tersedia. Operasi yang paling banyak memakai sumberdaya CPU adalah pada saat SSL handshake.

Ada dua cara untuk meminimalkan jumlah operasi ini per klien: yang pertama adalah mengaktifkan keepalive connections untuk mengirimkan beberapa request melalui satu koneksi dan yang kedua adalah untuk menggunakan ulang sesi SSL untuk menghindari SSL handshake untuk koneksi parallel dan subsequent connections. Sesi-sesi ini disimpan dalam SSL session cache yang di share antara worker dan dikonfigurasi oleh direktif “ssl_session_cache“. Satu megabyte dari cache bisa menyimpan sekitar 4000 sesi. Nilai default untuk cache timeout adalah 5 menit. Dan bias dinaikkan menggunakan direktif “ssl_session_timeout“.

Berikut ini adalah contoh konfigurasi yang sudah dioptimasi untuk sistem quad core dengan 10M shared session cache:

worker_processes  4;
 
http {
    ssl_session_cache    shared:SSL:10m;
    ssl_session_timeout  10m;
 
    server {
        listen               443;
        server_name          www.nginx.com;
        keepalive_timeout    70;
 
        ssl                  on;
        ssl_certificate      www.nginx.com.crt;
        ssl_certificate_key  www.nginx.com.key;
        ssl_protocols        SSLv3 TLSv1;
        ssl_ciphers          HIGH:!ADH:!MD5;
        ...

SSL certifcate chains

Beberapa peramban mungkin komplen tentang sertifikat yang ditandatangani oleh well-kown certificate authority, sementara peramban lainnya mungkin menerima sertifikat tanpa masalah. Hal ini terjadi karena yang mengeluarkan otoritas telah menandatangi sertifikat server menggunakan sertifikat perantara (intermediate certificate) yang tidak tersedia di basis sertifikat dari well-known trusted certificate authorities, tapi dilain sisi sertifikat ini mungkin didistribusikan di sebagian peramban lainnya. Dalam kasus ini si otoritas biasanya menyediakan satu bundle chained certificates yang harus di gabungkan (concatenated) ke sertifikat yang telah ditandatangani. Sertifikat harus muncul sebelum chained certificates pada berkas yang sudah digabung:

$ cat www.nginx.com.crt bundle.crt > www.nginx.com.chained.crt

Berkas yang dihasilkan digunakan dalam direktif “ssl_certificate“:

server {
    listen               443;
    server_name          www.nginx.com;
    ssl                  on;
    ssl_certificate      www.nginx.com.chained.crt;
    ssl_certificate_key  www.nginx.com.key;
    ...
}

Jika sertifikate server dan bunel sudah digabungkan dalam urutan yang salah, nginx akan gagal dijalankan dan akan menampilkan pesan error:

SSL_CTX_use_PrivateKey_file(" ... /www.nginx.com.key") failed
   (SSL: error:0B080074:x509 certificate routines:
    X509_check_private_key:key values mismatch)

karena nginx mencoba menggunakan private key dengan certifikat pertama dari bundle dan bukan ke sertifikat server yang seharusnya.

Peramban biasanya menyimpan sertifikat perantara yang mereka terima dan yang ditandatangani oleh otoritas terpercaya, jadi peramban yang sudah digunakan secara aktif mungkin sudah memiliki sertifikat perantara yang dibutuhkan dan tidak akan komplen tentang sertifikat yang dikirim tanpa bundle. Untuk meyakinkan server mengirimkan certificate chain yang lengkap, Anda bisa menggunakan perintah “openssl“, misalnya:

$ openssl s_client -connect www.godaddy.com:443

...
Certificate chain
 0 s:/C=US/ST=Arizona/L=Scottsdale/1.3.6.1.4.1.311.60.2.1.3=US
     /1.3.6.1.4.1.311.60.2.1.2=AZ/O=GoDaddy.com, Inc
     /OU=MIS Department/CN=www.GoDaddy.com
     /serialNumber=0796928-7/2.5.4.15=V1.0, Clause 5.(b)
   i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
     /OU=http://certificates.godaddy.com/repository
     /CN=Go Daddy Secure Certification Authority
     /serialNumber=07969287
 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc.
     /OU=http://certificates.godaddy.com/repository
     /CN=Go Daddy Secure Certification Authority
     /serialNumber=07969287
   i:/C=US/O=The Go Daddy Group, Inc.
     /OU=Go Daddy Class 2 Certification Authority
 2 s:/C=US/O=The Go Daddy Group, Inc.
     /OU=Go Daddy Class 2 Certification Authority
   i:/L=ValiCert Validation Network/O=ValiCert, Inc.
     /OU=ValiCert Class 2 Policy Validation Authority
     /CN=http://www.valicert.com//emailAddress=info@valicert.com
...

Di contoh ini subject (“s”) dari sertifikat server www.GoDaddy.com #0 ditandatangani oleh issuer (“i”) yang merupakan subject dari sertifikat #1, yang juga ditandatangani oleh issuer yang merupakan subject dari certificate #2, yang ditandatangani oleh well-known issuer ValiCert, Inc. Semua sertifikat itu disimpan di built-in certificate base dari peramban.

Jika Anda tidak menambahkan certificate bundle, Anda hanya akan melihat sertifikate server #0.

A single HTTP/HTTPS server

Merupakan langkah yang baik untuk mengkonfigurasi server secara terpisah untuk protokol HTTP dan HTTPS dari sejak awal. Meskipun mungkin fungsionalitas mereka terlihat mirip, tapi ini bisa saja berubah secara signifikan di masa yang akan datang dan menggunakan server yang digabung mungkin akan menjadi masalah. Walau demikian, jika server HTTP dan HTTPS adalah sama, dan Anda tidak ingin berfikir tentang masa yang akan datang, Anda bisa mengkonfigurasi satu server tunggal yang menangani request HTTP dan HTTPS dengan menghapus direktif “ssl on” dan menambahkan parameter “ssl” untuk port *:443

server {
    listen               80;
    listen               443  ssl;
    server_name          www.nginx.com;
    ssl_certificate      www.nginx.com.crt;
    ssl_certificate_key  www.nginx.com.key;
    ...
}

Semenjak versi 0.8.21, nginx hanya membolehkan parameter “ssl” di set pada socket yang di listen dengan parameter “default”:

listen  443  default  ssl;

Name-based HTTPS servers

Biasanya muncul masalah umum ketika mengkonfigurasi dua atau lebih server HTTPS yang listening pada satu alamat IP:

server {
    listen           443;
    server_name      www.nginx.com;
    ssl              on;
    ssl_certificate  www.nginx.com.crt;
    ...
}
 
server {
    listen           443;
    server_name      www.nginx.org;
    ssl              on;
    ssl_certificate  www.nginx.org.crt;
    ...
}

Dengan konfigurasi ini, peramban menerima sertifikat dari default server, misalnya, www.nginx.com tanpa terpengaruh dengan server name yang direquest. Ini disebabkan karena sifat dari protokol SSL. Koneksi SSL terjadi sebelum browser mengirim request HTTP dan nginx tidak akan pernah tahu nama dari server yang direquest. Oleh karena itu, dia hanya akan menawarkan satu sertifikat dari default server.

Cara lama dan yang paling tokcer untuk mengatasi masalah ini adalah dengan membuat alamat IP terpisah untuk setiap HTTPS server:

server {
    listen           192.168.1.1:443;
    server_name      www.nginx.com;
    ssl              on;
    ssl_certificate  www.nginx.com.crt;
    ...
}
 
server {
    listen           192.168.1.2:443;
    server_name      www.nginx.org;
    ssl              on;
    ssl_certificate  www.nginx.org.crt;
    ...
}

Sertifikat SSL dengan beberapa nama

Ada cara lain untuk berbagi alamat IP antara beberapa HTTPS server, meskipun demikian, semuanya memiliki kelemahan. Salah satu cara adalah menggunakan sertifikat dengan beberapa nama pada bagian SubjectAltName di sertifikat. Sebagai contoh misalnya, www.nginx.com dan www.nginx.org. Tapi, bagian SubjectAltName memiliki panjang yang terbatas.

Cara lain adalah menggunakan sertifikat dengan wildcard name, misalnya, *.nginx.org. Sertifikat ini akan cocok dengan www.nginx.org, tapi tidak akan cocok dengan nginx.org dan www.sub.nginx.org. Dua metode tadi, bisa juga dikombinasikan. Sertifikat bisa saja berisikan exact dan wildcard name pada bagian SubjectAltName, misalnya, nginx.org dan *.nginx.org.

Akan lebih baik untuk menyimpan berkas sertifikat dengan beberapa nama dan berkas kunci privatenya pada level http dari berkas konfigurasi, agar di inherit ke semua server dari satu salinan memori.

ssl_certificate      common.crt;
ssl_certificate_key  common.key;
 
server {
    listen           443;
    server_name      www.nginx.com;
    ssl              on;
    ...
}
 
server {
    listen           443;
    server_name      www.nginx.org;
    ssl              on;
    ...
}

Server Name Indication

Solusi yang lebih mendasar untuk menjalankan beberapa server HTTPS pada satu alamat IP tunggal adalah menggunakan TLSv1.1 Server Name Indication extension (SNI, RFC3546), dimana dia membolehkan peramban melanjutkan request server name pada saat SSL handshake, dan selanjutnya, server akan tahu sertifikat yang mana yang harus digunakan untuk koneksi tersebut. Tapi SNI memiliki dukungan peramban yang terbatas. Saat ini dukungan fitur mulai ada di beberapa versi peramban berikut:

Opera 8.0;
MSIE 7.0 (hanya untuk Windows Vista atau versi lebih tinggi);
Firefox 2.0 dan peramban lain yang menggunakan platform Mozilla Platform rv:1.8.1;
Safari 3.2.1 (Versi Windows mendukung SNI pada Vista atau versi lebih baru);
dan Chrome (Versi Windows mendukung SNI pada Vista atau versi lebih baru).

Untuk menggunakan SNI di nginx, ini harus didukung oleh pustaka OpenSSL yang mana saat nginx dibangun juga oleh pustakan yang sedang ditautkan secara dinamik saat dijalankan. OpenSSL sudah mendukung SNI sejak versi 0.9.8f jika dia dibangun dengan opsi konfigurasi “--enable-tlsext“. Sejak OpenSSL 0.8.9j opsi ini diaktifkan secara default. Jika nginx sudah dibangun dengan dukungan SNI, maka nginx akan menampilkan ini ketika dijalankan dengan pilihan “-V”:

$ nginx -V
...
TLS SNI support enabled
...

Akan tetapi, jika nginx yang sudah diaktifkan SNI nya, tapi ditautkan secara dinamik ke pustaka OpenSSl yang tidak memiliki dukungan SNI, ngixn akan menampilkan peringatan:

nginx was built with SNI support, however, now it is linked
dynamically to an OpenSSL library which has no tlsext support,
therefore SNI is not available

Kompatibilitas

The SNI support status has been shown by the “-V” switch since 0.8.21 and 0.7.62.
The “ssl” parameter of the “listen” directive has been supported since 0.7.14.
SNI has been supported since 0.5.32.
The shared SSL session cache has been supported since 0.5.6.
Version 0.8.19 and later: the default SSL protocols are SSLv3 and TLSv1.
Version 0.8.18 and earlier: the default SSL protocols are SSLv2, SSLv3, and TLSv1.
Version 0.8.20 and later: the default SSL ciphers are “HIGH:!ADH:!MD5”.
Version 0.8.19: the default SSL ciphers are “ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM”.
Version 0.8.18 and earlier: the default SSL ciphers are
“ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP”.

Ditulis oleh Igor Sysoev
Diedit oleh Brian Mercer
Diterjemahkan oleh Cecep Mahbub

Yang diperlukan

Pastikan Nginx dikompilasi dengan opsi:

--with-http_ssl_module

Jika Anda menggunakan paket debian atau rpm, Anda bisa memastikannya dengan pertintah:

nginx -V

Selain itu Anda harus sudah menginstal paket openssl.

Membuat Self Sign Certificate

Saya tuliskan lagi secara singkat. Lengkapnya silakan lihat di tulisan sebelumnya, Membuat Self Sign Certificate.

openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 731 -in server.csr -signkey server.key -out server.crt

Anda akan mempunyai 3 berkas baru.

server.crt
server.csr
server.key

Yang akan diguanakan hanya dua, server.crt dan server.key.

Konfigurasi Nginx

Sekarang silakan salin dua berkas tersebut, dan atur hak aksesnya. Asumsi Nginx dijalankan sebagai user www-data.

cp server.crt /etc/ssl/
cp server.key /etc/ssl/
chmod 644 /etc/ssl/server.crt
chmod 640 /etc/ssl/server.key
chown root:www-data /etc/ssl/server.key

Maka konfigurasi Nginx untuk https:

server {
    server_name perusahaan.com;
    listen 443;
    ssl on;
    ssl_certificate /etc/ssl/server.crt;
    ssl_certificate_key /etc/ssl/server.key;
}

Sebelum Anda melanjutkan membaca tulisan ini, ada baiknya Anda tidak melewatkan seri tutorial DNS Server dengan Bind9 (1, 2 dan 3). Karena dalam instalasi zimbra, Anda harus memahami bagaimana cara membuat sebuah hostname bisa di resolve dengan baik dan bagaimana membuat entri mx record.

Saat tulisan ini dibuat, rilis terbaru zimbra untuk versi 6.0, adalah 6.0.1. Dan untuk tutorial kali ini, kita akan menggunakan Ubuntu 8.04 (Hardy Heron). Instalasi ubuntu diasumsikan menggunakan instalasi default ubuntu 8.04 server edition.

Mengkonfigurasi berkas /etc/hosts

Zimbra mensyaratkan hostname bisa diresolve dengan baik, sekarang coba Anda sunting berkas /etc/hosts.

Dari asalnya,

1
2
3
4
5
6
7
8
9
10

127.0.0.1	localhost
127.0.1.1	zimbra
 
# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Menjadi

1
2
3
4
5
6
7
8
9
10

127.0.0.1	localhost
172.16.10.131  zibra.ngadimin.com zimbra
 
# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Disini diasumsikan IP server adalah 172.16.10.131, dan hostnamenya adalah zimbra.ngadimin.com.

Contoh konfigurasi DNS

Hostname & Alamat IP

• hostname: zimbra.ngadimin.com
• ip: 172.16.10.131

Kita akan buatkan alias, dibuatkan hostname yang mencerminkan fungsi dari service/layanan yang diberikan.

• imap.ngadimin.com, untuk akses imap
• pop.ngadimin.com, untuk akses pop3
• smtp.ngadimin.com, untuk akses smtp (mengirim email)
• webmail.ngadimin.com, untuk akses webmail

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

$TTL 7200       ; 2 hours
@       IN SOA  ns1.ngadimin.com. hostmaster.ngadimin.com. (
                                2009101000 ; serial
                                7200       ; refresh (2 hours)
                                3600       ; retry (1 hour)
                                604800     ; expire (1 week)
                                10800      ; minimum (3 hours)
                                )       
                        NS      ns1.ngadimin.com.
                        MX  10  zimbra.ngadimin.com.
 
ns1                     A       172.16.10.131
zimbra                  A       172.16.10.131
 
imap                    CNAME   zimbra
pop                     CNAME   zimbra
smtp                    CNAME   zimbra
webmail                 CNAME   zimbra

Paket-paket yang dibutuhkan untuk instalasi zimbra

Instal paket-paket berikut.

sudo apt-get install libidn11 libpcre3 libgmp3c2 libexpat1 libstdc++6 libstdc++5 sysstat

Untuk memudahkan, kita akan uninstall apparmor (Anda boleh tidak setuju dengan cara ini, tapi ini demi memudahkan instalasi).

sudo dpkg --purge apparmor apparmor-utils

Anda juga harus memastikan tidak ada yg listen di port 25, 80, 110, 143. Untuk memeriksanya, jalankan perintah berikut. Lihat port yang listen di server Anda.

sudo lsof -i -n -P

Instalasi Zimbra

Download source instalasi dari website zimbra. http://www.zimbra.com/community/downloads.html. Pilih paket yang sesuai dengan arsitektur prosesor Anda. Misal, yang saya gunakan Ubuntu 8.04 LTS 32 bit.

wget http://h.yimg.com/lo/downloads/6.0.1_GA/zcs-6.0.1_GA_1816.UBUNTU8.20090911174852.tgz

Ekstrak,

tar zxvf zcs-6.0.1_GA_1816.UBUNTU8.20090911174852.tgz

Lalu jalankan skrip instalasi.

cd zcs-6.0.1_GA_1816.UBUNTU8.20090911174852
sudo ./install.sh

Menginstal logwatch sangatlah mudah. Semudah menginstal aplikasi lainnya dari repositori Ubuntu.

sudo apt-get install logwatch

Konfigurasi

Letak berkas konfigurasi default ada di /usr/share/logwatch/default.conf/logwatch.conf. Silakan Anda amati bagian yang mungkin bisa Anda ubah. Tapi setidaknya Anda harus mengatur baris.

MailTo = root

Ubah menjadi

MailTo = alamat.email@domain.anda.com

Selanjutnya Anda tinggal menunggu. Seharusnya jika semua berjalan dengan baik, esoknya Anda sudah menerima laporan dari LogWatch.

Stress Test sering Dilupakan

Ketika Anda berniat meluncurkan layanan online berbasiskan web, walaupun itu hanya untuk kalangan terbatas, sebaiknya Anda sudah siap dengan jumlah pengakses yang menjadi target layanan itu. Dan dalam kenyataannya banyak pihak yang lupa atau tidak menghitung dengan baik jumlah pengakses layanannnya.

Sebuah sekolah membuka jalur pendaftaran siswa lewat internet. Jadi dengan tujuan untuk memperlancar proses pendaftaran, orang tua siswa disarankan untuk mendaftar via internet. Harapannya dengan proses pendaftaran online via internet tidak ada lagi antrian di meja pendaftaran ataupun kekisruhan di sekolah gara-gara pendaftar yang banyak.

Singkat cerita, layanan mulai dipublikasikan dan orang tua diinformasikan agar menggunakan layanan pendaftaran online via internet tadi. Hasilnya setelah sistem live, ternyata orang tua siswa kesulitan mengakses layanan online tersebut. Jangankan untuk daftar, baru mengakses form pendaftarannya saja sudah sering timeout. Belum lagi saat submit isian form, bukannya sukses malah muncul halaman error yang tidak dimengerti oleh si orang tua tadi.

Itu adalah contoh peluncuran layanan online yang tidak dipersiapkan dengan baik. Masalah di atas bisa banyak faktor yang menjadikan masalah. Pertama, jumlah pengakses dalam satu saat bersamaan banyak. Kedua, mungkin bandwidth yang disediakan kurang memadai dan terakhir mungkin layanan aplikasinya tidak mampu menangani sejumlah pengakses yang cukup banyak dalam satu saat yang bersamaan.

Seharusnya jika pengembang aplikasi web melakukan proses test sebelum live, masalah kapasitas server atau bandwidth yang tidak memadai sudah harus diketahui jauh-jauh hari sebelum sistem live.

Banyak dan Sedikit itu Relatif

1000 pengakses untuk portal seperti detik atau kompas mungkin sangatlah sedikit, bahkan mungkin tidak terasa apa-apa. Tapi buat aplikasi web yang disimpan di server shared hosting mungkin akan terasa berbeda. Apalagi jika aplikasi web itu dibuat sendiri dan tidak didesain dengan baik, sehingga baru diakses oleh puluhan pengakses dalam satu saat bersamaan sudah tidak responsif lagi, bahkan menjadi error.

Jadi angka-angka bukan ukuran yang baku, tapi dengan target user yang akan menggunakan layanan Anda, Anda bisa memprediksi mana yang harus dicermati lebih lanjut (yang artinya Anda harus melakukan test sistem), mana yang bisa diabaikan.

Misal, Anda diminta membuatkan blog untuk teman Anda sesama mahasiswa. Anda tidak perlu repot-repot melakukan optimasi atau benchmark disana-sini. Dengan konfigurasi standard di sebuah server shared hosting, seharusnya tidak akan ada masalah.

Tapi akan berbeda hasil akhirnya, jika mahasiswa si pemilik blog tersebut adalah seoarang selebritis misalnya. Dan jumlah fansnya ratusan ribu sampai jutaan orang. Dan blog si selebritis itu mendapatkan publikasi dari media yang cukup gencar, maka sudah dipastikan blog itu perlu perhatian lebih khusus terkait pengakses blog itu yang mungkin akan banyak.

Contoh lain yang perlu mendapatkan perhatian lebih, saat sistem akan diluncurkan.

• Pendaftaran siswa sekolah via internet/online.
• Pengumuman kelulusan siswa sekolah.
• Pengumuman atau pendaftaran CPNS (calon pegawai negeri sipil).
• Pendaftaran ujian saringan masuk ke perguruan tinggi

Sengaja yang saya contohkan seperti di atas, karena berdasarkan pengalaman contoh-contoh di atas lah yang sering gagal melayani usernya saat sistem diluncurkan. Pada umumnya mereka gagal melayani jumlah user yang banyak di satu saat yang bersamaan, walaupun jumlah pengakses banyak itu hanya untuk tempo waktu yang tidak lama.

Sedangkan contoh lain, misalnya peluncuran portal berita internet pada umumnya sudah mempersiapkan menerima lonjakan jumlah pengakses yang banyak, dan didukung oleh infrastruktur yang lebih baik juga.

Stress Test untuk mengukur Kapasitas Sistem

Stress test harus dilakukan secara bertahap. Mulai dengan sejumlah test kecil, lalu dinaikkan nilainya sampai sistem tidak bisa lagi menangani beban yang diberikan. Hal ini penting, karena Anda harus tahu kapasitas sistem yang Anda kelola. Apakah sistem bisa menangani 100 koneksi secara bersamaan, 200 koneksi atau malah baru puluhan koneksi sudah tidak bisa menangani lagi, misalnya.

Jadi test dilakukan tidak serta merta untuk menguji dengan beban yang besar, tapi juga untuk mengukur seberapa banyak beban bisa ditangani oleh sistem.

Aplikasi untuk Stress Test atau Benchmark Web Server

Untuk melakukan pengujian, banyak aplikasi yang bisa digunakan. Misal, ab (Apache Benchmark), siege atau httperf.

Beberapa tulisan di blog ini yang membahas ab dan siege.

• Benchmark Performa Web Server dengan ApacheBench (ab)
• Benchmark Performa Web Server dengan Siege

Setelah hasil Stress Test didapat

Ini adalah langkah yang paling penting, setelah hasil didapatkan, dan kita mengetahui kira-kira kapasitas sistem yang dikelola, selanjutnya apa yang harus dilakukan.

Jika hasilnya mengecewakan, artinya kapasitas sistem yang Anda kelola dibawah nilai yang Anda harapkan maka langkah selanjutnya adalah melakukan sistem profiling. Mencari tahu bagian mana dari proses aplikasi web Anda yang menyebabkan performa aplikasi menjadi jelek. Lalu perbaiki dan optimasi semuanya sampai mendapatkan nilai yang Anda harapkan.

Selain optimasi konfigurasi, mungkin juga Anda perlu mengupgrade hardware atau bahkan menambah server untuk membagi beban kedalam beberapa server.

Dan setelah semua perbaikan itu dilakukan, lakukan kembali stress test untuk mengetahui kapasitas sistem yang baru Anda optimasi atau baru Anda upgrade/tambah kapasitas hardwarenya.

Tautan

• The C10K problem
• Howto: Performance Benchmarks a Webserver

Instalasi

Di Ubuntu atau Debian, ApacheBench atau ab adalah bagian dari paket apache2-utils. Jadi pastikan paket tersebut terinstall.

sudo apt-get install apache2-utils

Contoh Proses Benchmark

ab -c 20 -n 1000 http://domaincontoh.com/test/

Dimana,

• -c 20 adalah jumlah concurrent connection, sebanyak 20 koneksi secara bersamaan.
• -n 1000 adalah jumlah request yang mau dikirim, sebanyak 1000 request.
• http://domaincontoh.com/test/ adalah url yang mau di test.

Contoh output dari proses benchmark.

This is ApacheBench, Version 2.3 <$Revision: 655654 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/
 
Benchmarking domaincontoh.com (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests
 
 
Server Software:        nginx
Server Hostname:        domaincontoh.com
Server Port:            80
 
Document Path:          /test/
Document Length:        178 bytes
 
Concurrency Level:      20
Time taken for tests:   0.129 seconds
Complete requests:      1000
Failed requests:        0
Write errors:           0
Non-2xx responses:      1000
Total transferred:      371000 bytes
HTML transferred:       178000 bytes
Requests per second:    7738.38 [#/sec] (mean)
Time per request:       2.585 [ms] (mean)
Time per request:       0.129 [ms] (mean, across all concurrent requests)
Transfer rate:          2803.65 [Kbytes/sec] received
 
Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.4      1      11
Processing:     0    1   0.3      1       3
Waiting:        0    1   0.3      1       3
Total:          1    3   1.4      2      13
 
Percentage of the requests served within a certain time (ms)
  50%      2
  66%      2
  75%      2
  80%      3
  90%      3
  95%      3
  98%     11
  99%     12
 100%     13 (longest request)

Dari statistik di atas, yang mungkin menarik untuk dilihat adalah baris Requests per second. Itu adalah nilai dari hasil benchmark. Tapi jangan abaikan juga bagian lain, misalnya Complete requests, Failed requests, atau Write errors. Pastikan tidak ada failed requests atau write errors. Jika ada, maka Anda harus mencari tahu apa yang menyebabkan error tersebut.

Seputar angka-angka

Jumlah request yang dicontohkan di atas, sebanyak 1000 request adalah contoh yang sangat kecil, dalam proses benchmark sesungguhnya angka-angka seperti 20000 atau 50000 mungkin lebih relevan. Dan jumlah concurrent connection sebanyak 20 juga termasuk kecil. Anda mungkin bisa mencoba angka yang lebih besar seperti 100 concurrent connection.

Yang Harus di Perhatikan

• Benchmark ditujukan ke web server yang Anda kelola. Bukan ke web server pihak lain, karena kalau ditujukan ke web orang lain, itu bisa dikategorikan sebagai serangan DOS.
• Benchmark harus dijalankan di komputer terpisah dari web server. Aplikasi benchmark bisa mengambil resource komputer secara agresif, jadi agar data benchmarking lebih valid, aplikasi benchmark harus dijalankan di komputer yang terpisah dari web server yang akan di benchmark.
• Pastikan semua komponen dari web Anda, baik yang dinamik atau statik di benchmark.
• Sebelum proses stress test dijalankan, siapkan aplikasi untuk memonitor seluruh proses benchmarking ini. Terutama yang berkaitan utilisasi hardware server yang di benchmark.

Yang Harus di Monitor

Saat stress test dijalankan, monitor semua aspek yang berhubungan dengan penggunaan resources server. Seperti load average, load processor, input/output atau penggunaan memori server.

Beberapa aplikasi atau tools untuk memonitor.

• ps – untuk memonitor proses yang sedang berjalan.
• top – untuk melihat penggunaan processor, memori dan aplikasi apa saja yang paling banyak menggunakan resources server.
• vmstat
• sysstat (iostat, mpstat, sar, pidstat)
• dstat – aplikasi monitoring yang menggabungkan output dari vmstat, iostat, netstat
• aplikasi untuk monitoring bandwidth

Yang tidak kalah penting dari semua itu, adalah monitoring manual. Maksudnya, saat stress test sedang dilakukan, Anda bisa langsung mencoba mengakses halaman web yang sedang di test. Lalu amati apakah web masih bisa dibuka dengan normal atau mengalami masalah (seperti lambat, tidak responsif atau malah error).

]]> http://ngadimin.com/2009/09/27/benchmark-performa-web-server-dengan-apachebench-ab/feed/ 3 http://ngadimin.com/2009/09/26/benchmark-performa-web-server-dengan-siege/ http://ngadimin.com/2009/09/26/benchmark-performa-web-server-dengan-siege/#comments Sat, 26 Sep 2009 06:47:39 +0000 Cecep Mahbub http://ngadimin.com/?p=1195 Instalasi

Menginstal siege di Ubuntu atau Debian adalah semudah menginstal aplikasi lain dari repositori.

sudo apt-get install siege

Untuk penggunakan CentOS atau RHEL, Anda bisa menginstalnya dari repo RPMForge atau download dari DAG.

Menggunakan Siege untuk Benchmarking

Untuk melakukan proses benchmark, jalankan perintah berikut.

 siege -b -c 20 -t 5M http://nama.domain.com/blog/

Penjelasan:
 
-b = Benchmark, dengan pilihan ini tidak akan ada waktu jeda dari satu test ke test 
     berikutnya (defaultnya ada delay secara acak mulai dari 0 s.d 3 detik).
-c = Banyaknya koneksi secara bersamaan yang akan dijalankan, default 10. 
     Dalam contoh diset 20 koneksi.
-t = Lama test akan dijalankan, dalam contoh di set 5 menit. 
     Anda bisa set waktu berbeda dengan akhiran S utk detik, M untuk menit 
     dan H untuk jam. Misal 60S = 60 detik, 1H = 1 jam.
 
Dan http://nama.domain.com/blog/ adalah URL yang akan di test.

Contoh output:

Transactions:                  43119 hits
Availability:                 100.00 %
Elapsed time:                  92.40 secs
Data transferred:             160.76 MB
Response time:                  0.02 secs
Transaction rate:             466.66 trans/sec
Throughput:                     1.74 MB/sec
Concurrency:                    7.74
Successful transactions:       43119
Failed transactions:               0
Longest transaction:            9.48
Shortest transaction:           0.00

Dari output di atas, Anda perhatikan baris transaction rate. Semakin besar berarti semakin cepat dan semakin banyak client yang bisa ditangani oleh aplikasi web kita.

Perhatikan juga baris failed transactions. Baris ini menunjukkan jumlah koneksi yang gagal saat menjalankan proses benchmark. Dalam kondisi server yang sibuk, biasanya server mulai error dan koneksi dari user pun gagal dilayani dengan baik.

Benchmark Untuk Banyak URL

Dalam contoh di atas kita hanya menggunakan satu URL saja. Jika ingin melakukan benchmark untuk banyak URL sekaligus, kita bisa membuat daftar URL yang akan ditest dan perintahkan siege untuk membacanya.

Buat berkas baru misal url.txt. Isi dengan URL yang mau ditest. Misal seperti di bawah ini,

http://nama.domain.com/
http://nama.domain.com/blog/
http://nama.domain.com/about.php
http://nama.domain.com/kontak.php
http://nama.domain.com/produk.php

Lalu untuk proses benchmark, jalankan perintah berikut.

 siege -b -c 20 -t 5M -f url.txt

Rangkuman

Siege bisa digunakan untuk proses benchmark, sehingga Anda bisa mengukur seberapa banyak kira-kira jumlah client yang bisa ditangani oleh aplikasi web Anda.

Catatan untuk contoh di atas, angka concurrent connection sebanyak 20 koneksi adalah jumlah yang kecil. Silakan Anda mencobanya dengan angka yang lebih besar, misal 100 koneksi. Lalu perhatikan bagaimana aplikasi dan server Anda meresponnya.

Yang perlu diingat, benchmark harus dijalankan ke web Anda sendiri, bukan ke web orang lain. Karena kalau dijalankan ke web orang lain, artinya Anda menyerang atau mengganggu layanan punya orang

]]> http://ngadimin.com/2009/09/26/benchmark-performa-web-server-dengan-siege/feed/ 0 http://ngadimin.com/2009/09/10/kirim-notifikasi-email-ketika-windows-server-di-restart/ http://ngadimin.com/2009/09/10/kirim-notifikasi-email-ketika-windows-server-di-restart/#comments Thu, 10 Sep 2009 05:28:02 +0000 Cecep Mahbub http://ngadimin.com/?p=1152 Buat berkas baru isinya seperti di bawah ini. Simpan sebagai berkas vbs, misalnya C:\mail.vbs

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

strEmailFrom = "noreply@ngadimin.com" strEmailTo = "cecep@ngadimin.com" strEmailSubject = "SERVER REBOOTED" strEmailBody = Now & vbCrLf & "Your server has been rebooted" strSMTP = "localhost" Set objEmail = CreateObject("CDO.Message") objEmail.From = strEmailFrom objEmail.To = strEmailTo objEmail.Subject = strEmailSubject objEmail.Textbody = strEmailBody objEmail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/sendusing") = 2 objEmail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpserver") = "localhost" objEmail.Configuration.Fields.Item ("http://schemas.microsoft.com/cdo/configuration/smtpserverport") = 25 objEmail.Configuration.Fields.Update objEmail.Send

Catatan, silakan atur variabel di atas. Silakan juga ubah localhost menjadi alamat SMTP server yang bisa Anda gunakan untuk mengirim email notifikasi.

Langkah selanjutnya adalah memasukkan skript tersebut ke script startup di server windows Anda. Caranya, dari menu start -> Run… -> ketik gpedit.msc

Lalu di layar Group Policy Editor, masuk ke

Local Computer Policy 
   -> Computer Configuration 
      -> Windows Setting 
         -> Script (Startup/Shutdown)

Masukkan script mail.vbs yangs sudah kita buat sebelumnya ke bagian Startup.

]]> http://ngadimin.com/2009/09/10/kirim-notifikasi-email-ketika-windows-server-di-restart/feed/ 2 http://ngadimin.com/2009/09/01/membuat-ftp-server-di-ubuntu-hardy-dengan-vsftpd/ http://ngadimin.com/2009/09/01/membuat-ftp-server-di-ubuntu-hardy-dengan-vsftpd/#comments Tue, 01 Sep 2009 08:33:47 +0000 Cecep Mahbub http://ngadimin.com/?p=1008 Instalasi

Instalasi vsftpd semudah menginstal aplikasi lain dari repositori Ubuntu.

sudo apt-get install vsftpd

Untuk menjalankan service vsftpd

sudo /etc/init.d/vsftpd start

Untuk mematikan service vsftpd

sudo /etc/init.d/vsftpd stop

Konfigurasi FTP Anonim

FTP anonim artinya user bisa masuk ke ftp server tanpa harus memasukkan login dan password. Biasanya digunakan oleh ftp server yang menyediakan berkas untuk umum, seperti mirror aplikasi atau server penyedia repositori distro linux.

Secara default konfigurasi vsftpd di Ubuntu sudah membolehkan akses ftp anonim. Dan lokasi home direktori untuk user ftp ada di /home/ftp, dan ini adalah tempat menyimpan berkas yang akan diberikan melalui ftp.

Jika Anda berniat untuk memindahkan lokasi tempat menyimpan berkas untuk ftp anonim tadi, Anda tinggal mengganti lokasi home direktori untuk user ftp.

Misal, kita akan pindahkan ke /data/ftp.

sudo mkdir /data/ftp
sudo usermod -d /data/ftp ftp 

Setelah itu, restart service vsftpd

sudo /etc/init.d/vsftpd restart

Konfigurasi FTP untuk User

Jika Anda ingin membolehkan user yang ada di linux server untuk login melalui ftp dan user-user tadi bisa mengupload berkas ke server, buat konfigurasi seperti berikut.

Berkas yang harus Anda sunting adalah /etc/vsftpd.conf

local_enable=YES
write_enable=YES

Setelah itu restart service vsftpd

sudo /etc/init.d/vsftpd restart

Membatasi User di Home Direktori

Secara default user yang bisa masuk melalui ftp, bisa mengakses semua berkas yang ada di server (tentunya dengan hak akses yang sesuai dengan user tersebut). Jika Anda ingin membatasi user yang login melalui ftp hanya bisa mengakses berkas-berkas yang ada di home direktorinya saja, gunakan konfigurasi berikut.

Sunting berkas /etc/vsftpd.conf

chroot_local_user=YES

Atau jika Anda hanya ingin membatasi user tertentu saja, gunakan konfigurasi seperti di bawah ini

chroot_list_enable=YES
chroot_list_file=/etc/vsftpd.chroot_list

Kemudian Anda masukkan user yang ingin dibatasi ke dalam berkas /etc/vsftpd.chroot_list.

Dan jangan lupa, untuk menerapkan konfigurasi tadi, Anda harus merestart service vsftpd.

sudo /etc/init.d/vsftpd restart

]]> http://ngadimin.com/2009/09/01/membuat-ftp-server-di-ubuntu-hardy-dengan-vsftpd/feed/ 4 http://ngadimin.com/2009/08/29/vim-syntax-highlighting-untuk-nginx/ http://ngadimin.com/2009/08/29/vim-syntax-highlighting-untuk-nginx/#comments Sat, 29 Aug 2009 16:55:59 +0000 Cecep Mahbub http://ngadimin.com/?p=988 Download berkas nginx.vim, dan simpan di ~/.vim/syntax/. Kemudian tambahkan baris berikut ke berkas ~/.vim/filetype.vim

au BufRead,BufNewFile /opt/nginx/conf/* set ft=nginx
au BufRead,BufNewFile /opt/nginx/conf/sites-available/* set ft=nginx
au BufRead,BufNewFile /opt/nginx/conf/sites-enabled/* set ft=nginx

]]> http://ngadimin.com/2009/08/29/vim-syntax-highlighting-untuk-nginx/feed/ 0