Baru nyadar kenapa validasi user dan password waktu sudah login gak bisa dimasukkan ke variable session PHP. Ternyata feature ‘remember me’ jadi gak berguna. Sebab session gak bisa hidup terus, jadinya percuma simpan cookie user dan pass untuk expired 1 tahun.

Solusinya ya, terpaksa dibedain/dikeluarin dari variable session. Bikin data store sendiri (masih pake memcached) dengan menyimpan user dan password. Jadi kalo diset expired lama, memcached ini masih bisa. Konsekuensinya juga di memcached tidak selamanya data disimpan. Hm.. jadi tricky. Semakin lama, semakin jauh dari kondisi ideal. Dan kerjaan masih ada lagi. Terpaksa deh pending.. weh… sedih kalo muncul masalah lain.

…. lagi bad mood hari ini …..

admin General

Setelah mendeploy arsitektur baru blogdetik di mesin server yang baru, masih ada kendala yang dihadapi. Yang awal tampak adalah penggunaan session di WPMU. Session disimpan di server memcached dengan model replication, dimana jika salah satu server mati, akan switch fail over ke server satunya. Sebenarnya alokasi server memcached ini aslinya akan dipakai untuk aplikasi lainnya yang membutuhkan cache data, tapi untuk sementara ini dipakai buat blogdetik. Perkiraan awal meleset karena fail over menggunakan ucarp masih belum pas. Jika server master proses mati, tidak akan mentrigger fail over ke server slave. Untuk itu, harus dikendalikan sendiri dari sisi aplikasi. Untuk itu, harus ada tambahan script untuk menghandle session store diluar default session store milik memcache.

Disela-sela development, ditemukan masalah lain yang berhubungan dengan session. Salah satunya adalah plugin LDAP untuk authentication. Ada sedikit vulnerability dari validasi user. Cookie yang dibuat untuk validasi (wordpressuser dan wordpresspass) masih rentan terhadap serangan. Setelah memantau di kodenya, rupanya cookie pass diset menggunakan md5 username dan md5 ldap cookie marker, yang jelas kelihatan rentan untuk ditembus. Seharusnya representasi password benar-benar dari entitas password itu sendiri. Seperti di standar WPMU, validasi menggunakan md5 password yang dipassing ke cookie. Jadi setiap pemanggilan URL ke aplikasi, validasi dilakukan dengan pengecekan md5 password yang tersimpan diserver. Standar WPMU menyimpannya di file cache. Ini juga menimbulkan pertanyaan, kenapa tidak bermain-main dengan variable session. Disini penulis mulai mengupas pemakaian session di WPMU.

Ditemukan lagi pertanyaan, kenapa untuk masing-masing subdomain dari blogdetik harus membuat session lagi ? Kenapa gak dijadikan satu saja ? Disini lagi-lagi penulis coba untuk melihat penyebabnya. Dan… gak ketemu pastinya, tapi secara default WPMU rupanya tidak terlalu fokus untuk masalah ini. Okelah, sepertinya sekalian aja dirapikan untuk masalah session ini. Penulis berusaha menggunakan fasilitas variabel session yang ada di PHP. Untuk lebih meningkatkan sekuriti, akhirnya dipakailah variabel session untuk menyimpan md5 password (ini untuk meminimalisir load pengecekan ke database LDAP setiap pemanggilan URL).

Oh, ya; sebelumnya juga ditemukan masalah di plugin firestats. Plugin ini rupanya membuat mekanisme handling session sendiri diluar standar. Firestats memakai file based session, yang untuk sementara direktori dialihkan ke NFS server untuk sentralisasi. Akhirnya untuk sekalian menyeregamkan pemakaian session, penulis juga harus merubah management session ke satu bentuk management session di memcached.

Hasilnya, session management dibuat fasilitas fail-over. Dengan tambahan jika memang kedua server memcached sedang bermasalah, akan dialihkan ke cadangan file based session yang disimpan di direktori NFS mounted. Metode persistent connection gak berjalan mulus di server memcached. Ini ada hubungannya dengan php-cgi dalam menghandle exception untuk koneksi memcached yang bermasalah. Setelah mengganti ke bentuk non persistent, error gateway time out dikarenakan php-cgi yang bermasalah tidak terjadi lagi. Tapi konsekuensinya adalah banyaknya status koneksi time-wait. Untuk menghindarinya, set 1 ke parameter kernel tcp_tw_recycle & tcp_tw_reuse.

Selain itu semua subdomain di blogdetik menggunakan satu domain (.blogdetik.com). Dengan begitu sesi cookie akan kelihatan lebih bersih aja dibandingkan sebelumnya. Firestats plugin mendukung variabel memcached-based session.

Beberapa perbaikan kecil juga dilakukan di konfigurasi nginx.conf. Yakni masalah pemanggilan direktori (seperti wp-admin) tanpa “/”, yang mengakibatkan kesalahan pembuatan link di administrator panel. Solusinya harus redirect URL dengan penambahan “/” diakhir, jika URL memang adalah direktori. Masalah lain adalah set default comment_registration saat create user baru, untuk mencegah spam comment untuk non-user blogdetik. Feature supercache dan wp-cache juga di ulas kembali untuk kasus kontak. Penyelesainnya dengan cara memasukkan URL tersebut di daftar excluded URL di administrasi supercache dan wp-cache.

Berikut file-file yang mengalami perubahan dengan detil masalahnya:

1. remove redundant session (wp-config.php) => change index.php, captca.php, kontak.php, wp-cache-config.php (add kontak.php as no cache)
2. fix nginxmu.conf for redirecting directory access.
3. fix password cookie (wp-settings.php (avoid clears GLOBAL var), ldap_auth.php(authorization/update pass;set session), wp-login.php (logout;clear session and sessionid)).
4. create session memcached failover file based (failover seem trouble, cause persistent connection from memcache) => use manual if both servers down => use non persistent, then no need manual failover for file.
5. session firestats used default php session => plugin/firestats/php/session.php
6. set comment_registration 1 as default (wp-admin/includes/schema.(original|innodb).php)

Tapi masih ada todo list untuk masalah lainnya yang masih belum selesai, yakni:

1. php-cgi fault.
2. captca vulnerability.
3. unknown directory created.
4. yahoo mail problem.
5. software monitoring.
6. mobile themes.

admin General, Server

Di blogdetik.com sudah terinstall xcache. Cuman waktu itu gak ngeliat performance enhancement yang significant. Karena lagi nganggur, coba-coba testing lagi pake ab dengan jumlah request 100000 dan konkurensi 1. Konkurensi gak diset banyak, karena memang buat ngecek dari sisi loading script php-nya aja, apa bener sih opcode cache benar-benar bekerja maksimal. Waktu pertama ditest tanpa xcache, memori yang dikonsumsi webserver hanya 9-10Mbs (php-cgi). Hasil benchmark ab-nya:

Concurrency Level:      1
Time taken for tests:   12344.642804 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      1460381792 bytes
HTML transferred:       1398600000 bytes
Requests per second:    8.10 [#/sec] (mean)
Time per request:       123.446 [ms] (mean)
Time per request:       123.446 [ms] (mean, across all concurrent requests)
Transfer rate:          115.53 [Kbytes/sec] received

Sedangkan kalo dipasang xcache, memori yang dikonsumsi webserver 12-22Mb (php-cgi). Hasil benchmark-nya:

Concurrency Level:      1
Time taken for tests:   5754.861240 seconds
Complete requests:      100000
Failed requests:        0
Write errors:           0
Total transferred:      1460381652 bytes
HTML transferred:       1398600000 bytes
Requests per second:    17.38 [#/sec] (mean)
Time per request:       57.549 [ms] (mean)
Time per request:       57.549 [ms] (mean, across all concurrent requests)
Transfer rate:          247.82 [Kbytes/sec] received

admin Benchmark, Server

Yah, hari ini ngerjain session management via memcached. Karena gak yakin kalo server ini bila dipake lebih dari satu aplikasi webserver gak akan crash key (session_id) yang dipake, maka satu-satunya cara adalah nambahin parameter web_id di php.ini bagian session.save_path. Biar tiap aplikasi assign web_id sendiri-sendiri. Jadi kemungkinan tiap aplikasi web server yang generate session_id (yang dipake sebagai key di memcached) + web_id gak akan pernah sama. Berikut sedikit patch di source memcache_session.patch.

admin Server

Kalo dipikir-pikir, secara teori sih kecepatan transfer antara tcp dan unix socket, masih cepetan unix socket. Abis liat blog orang tentang perbandingan pake socket sama pake tcp, juga membuktikan kalo socket lebih cepat (di comment juga ada yang bilang sebaliknya). Aku coba buat konfigurasi yang sama untuk Nginx (nambah directive upstream dengan masing-masing unix socket yang di-create), dan merubah sedikit file cgi_main.c (php-5.2.5/sapi/cgi), dengan begitu instance child yang di-create akan mempunyai unix socket sendiri. Sebenarnya bisa dibuat instance php-cgi sendiri-sendiri sejumlah yang kita inginkan, terlepas dari cara spawn dari parent sejumlah PHP_FCGI_CHILDREN. Namun aku pikir nantinya akan ada masalah dengan modul xcache, karena xcache sharing opcode cache-nya pake shared memory file yang hanya bisa diliat di anak-anaknya php-cgi. Ya sudah, terpaksa ubah-ubah sedikit source php cgi_main.patch.

Dan ternyata hasilnya masih mengecewakan, gak ada penambahan performance, justru ada beberapa request dari hasil benchmark pakai ab yang failed. Yah….. gak sesuai harapan deh. Gak papa lah, paling gak hasil sedikit kerja bisa ada manfaatnya. Jadi kesimpulannya, pakai tcp socket aja…… (hm.. kalo pake pipe lebih cepet gak ya )

admin Benchmark, Server