Reverse Proxy — GAGAL!

Ditulis pada tanggal 30 Juli 2011

Sekitar setahun yang lalu, aku pernah pasang reverse proxy untuk sedikit mendongkrak performa dua web yang sudah terprediksi akan mengalami "serbuan akses" pada tanggal X dan Y. Reverse proxy itu pake squid, dan benar-benar dipasang sebagai keisengan belaka, karena sebenarnya perangkat layanan web yang kala itu tersedia yang cukup mewah (baca: spek servernya lumayan dempal) dan banyak, jadi aku bisa bikin tiga server web + dua server database yang seluruhnya bisa bekerja dengan indah. Aplikasinya punya sistem caching yang cukup bagus, begitu pun databasenya. Penambahan sebuah reverse proxy kala itu sekedar dilakukan untuk meningkatkan utilisasi jaringan DRC yang terletak beberapa ratus kilo meter dari pusat jaringan. Kebetulan waktu itu ada jaringan privat yang menghubungkan kedua lokasi itu dengan kecepatan 100 mbps, dan site DRC itu sendiri punya konektivitas internet sekitar 20 mbps. Baru-baru ini dengan kondisi lapangan yang sedikit berbeda, aku mencoba mengulang kembali pasang squid sebagai reverse proxy, dan gagal.

Sekitar tiga atau empat minggu yang lalu ada kawan lama yang pernah jadi salah satu guru jaringanku minta tolong supaya aku sedikit bantu dia untuk ngembalikan nafas salah satu layanan web yang dia punya, yang sudah selama 2 minggu jalan sangat berat, megap-megap, dan tentunya mengancam kelanjutan hidup web itu. Ketika servernya masih sehat, menurut Google Analytics pengunjungnya cukup tinggi, rata-rata antara 35-40 ribu visits per day. Ketika sedang sakit-sakitan jumlah pengunjungnya jatuh sampai tinggal 20% saja. Kesempatan istirahatnya web itu cuma hari Sabtu Minggu. Posisi servernya ada di Intiland jadi akses ke dalam servernya cuma bisa dilakukan via SSH. Ada dua server Xen, masing-masing njalankan beberapa VM. Untuk web yang aku ikut bantu-bantu sedikit ini terdiri atas dua VM yang kebetulan secara fisik terpisah. Server web (namanya Onta) dapet 1 processor dengan memori 2GB, sedangkan server db (namanya Merpati) dapet 4 processor dengan memori 8GB.

Kalau dilihat pakai htop, server database tampaknya bekerja cukup keras. Keempat processornya sangat sering mentok di angka 100%. Kalau server webnya sih tampaknya santai santai saja. 1 processor cukup, memori cukup lengang, tapi mabukan. Berhubung dalemnya si Onta sudah ruwet persis kayak benang mbulet saklemari gara-gara ada instalasi virtualmin atau apa lah namanya, aku minta si Onta diinstall ulang bersih dari nol, karena untuk roll-back ke kondisi bersih sudah terlalu sulit. Virtualmin nginstall berbagai paket ini itu dan anu-anu yang aku udah muales banget ngelihatnya.

Urusan sisanya pada awalnya kelihatan enak, tapi ternyata runyam di belakang. Karena di internet buanyak sekali yang bilang bahwa nginx + fastcgi + php jauh lebih baik (efisiensi sumber daya + kecepatan) daripada apache, kupasanglah tiga makhluk itu. Lima-sepuluh menit pertama jalannya kelihatan baik-baik saja. Selanjutnya, entah kenapa, fastcgi sepertinya terlalu lama memproses script PHP yang ada. Buntutnya bisa ditebak: Nginx ndak bisa ngontak fastcgi yang akhirnya di browser cuma kelihatan tulisan "Bad Gateway". Penggantian interface nginx-fastcgi dari tcp/ip socket menjadi unix socket juga ndak membantu, hasilnya persis sama. Dalam kondisi seperti itu penggunaan memori Onta meningkat mendekati 90%. Si Merpati sendiri masih bisa diakses, masih bisa diquery, walau memang juga terasa agak berat.

Setelah sudah merasa cukup muntah dengan nginx + fastcgi, baliklah aku ke model setup blo'on seperti biasanya: apache + modul php. Klasik. Persetan apa kata orang di seluruh penjuru internet. Hasilnya: Mantab Djaja. Selama beberapa hari setelahnya jalannya baik-baik saja, sampai akhirnya terasa berat lagi yang dicurigai akibat kekurangan benwit. Setelah providernya nambah jatah benwit (dari 10 jadi 15 mbps) jalannya web itu jadi lancar lagi. Hardware masih tetap sama, dengan rata-rata tampilan /server-status apache seperti ini:



Tampaknya baik-baik saja, ndak ada masalah. Kucoba install squid, bikin reverse proxy, siapa tau bebannya memang benar-benar turun. Asumsi awalnya sih kalau beban kerja apache bisa turun, mestinya ada potensi untuk memberikan layanan lebih besar ke lebih banyak orang sekaligus. Hampir semua referensi di internet bilang bahwa squid bisa membantu urusan itu. Setelah squid jalan, rata-rata tampilan /server-status jadi seperti ini:



Weh, ternyata memang ngefek lumayan banyak. Penggunaan CPU dan memori juga cukup menurun, terutama dari sisi CPU server MySQL. Tapi tunggu. Bahagia itu hanya hidup sekejab. Beberapa jam kemudian kondisinya jadi seperti ini:



Kemudian beberapa menit kemudian begini:



Dan W terus tumbuh hingga akhirnya MaxClients tercapai dan mabuklah server itu. Restart squid dan apache memang membantu, layanannya jadi jalan lagi selama beberapa jam ke depan sampai akhirnya ketemu kondisi seperti itu lagi.

Setelah squid dimatikan (apache berhadapan langsung dengan client) masalah itu jadi hilang. Kira-kira aku salah di mananya ya? Buta beneran, ndak tau musti nyari ke mana.

 

 

Timpalan tulisan

Timpali tulisan

Nama
Komentar
  [Kode Huruf] Ndak bisa dibaca? klik di sini.
  Tuliskan kode di atas di isian ini:
Seharusnya situs ini kelihatan bagus kalo anda lihat menggunakan layar monitor
Kalau dilihat dari kuku jempol... Ah... Dunia khayal...

Ha? Apa? XHTML? Halah prek! Gelem wacanen, ndak gelem tinggalen :P