> > On Jan 4, 2008 10:48 AM, Andre Prasetya <[EMAIL PROTECTED]> wrote: > > Soal hosting, kl di indo memang nggak mungkin untuk bisa host ruby saat > ini tapi di luar negeri, hostgator saja punya paket hosting murah buat > ruby, kl gak salah skitar usd 9 per bulan, sementara kalau mau java > application server ya pasti VPS, dan di luar negeri untuk tomcat saja > min usd 20 per bulan (memori 192 MB) dan untuk jboss usd 30 per bulan > (memori 384 MB). > Ini ngomongin shared-hosting ya? Baru "ngeh" saya.
Shared-hosting yang udah mendukung Rails SELALU menggunakan Apache + FastCGI. Model deployment Rails seperti ini akan terasa sama seperti model deployment PHP. Tinggal drop Rails app di /var/www/data dan jalan. Sisanya hanya urusan bermain symlink sehingga kita hanya perlu edit file di public_html kita. Meski praktis dan murah, Apache FastCGI nggak direkomendasikan untuk aplikasi Rails yang kritikal. fcgi spawn sering mampus secara tiba-tiba dan random. Anda bisa saja bersih2 fcgi zombie ini pake script/reaper, tapi biasanya pihak shared hosting menjalankan scriptnya sendiri untuk bersih2 fcgi zombie. Jadi Rails di shared hosting => Single instance Apache + ratusan/ribuan fcgi spawn (960 spawn by default jika saya tidak salah ingat). Untuk Java jelas nggak bisa pake mekanisme shared-hosting. Masa masing-masing user dikasih akses admin ke Tomcat instance? Ada sih cara akal-akalan. Saya pernah hosting applikasi Java (Struts2) di shared hosting tapi ribet ngurusi classpath *.jar dan juga nggak bisa "shared" *.jar dg menempatkan *.jar di $CATALINA_HOME/lib. (Hints: JRuby on Rails membutuhkan JDBC connector ditempatkan di $APP_SERVER_HOME/lib). Jadinya untuk Java, solusi paling praktis ya pake VPS. You own your own Tomcat. I address it as "ono rego ono rupo" application deployment framework :d > Untuk multi threading sih saya belum coba kl di ruby > soalnya sejauh ini pemakaiannya sebatas di rails, dan untuk itu sih > masih belum perhatikan gimana multi threading api di ruby sementara kl > di java pakainya buat distributed application dan untuk itu saya memilih > untuk ndak pakai JMS (Java Messaging Service) sehingga mau nggak mau > harus pakai ThreadPool yg mana dah disediakan oleh Java5 dan sejauh ini > performance sih bagus. > Err.. memilih antara JMS dan ThreadPool atas dasar apa toh? Dua mainan ini jelas barang yang beda. Ruby sudah punya padanan ThreadPool, jika itu yang anda maksud. Tapi thread di Ruby MRI 1.8 tetep suck karena masih green thread. thread di Ruby 1.9, however, akan mudah mengalahkan threading di JVM baik dari sisi kemudahan penggunaan dan performa. Ok. Untuk performa mungkin masih menunggu Ruby 2.0. You know what I mean lah. Kalo alternatif JMS di Ruby mah banyak: * Tetap pake Messaging dengan ActiveMessaging + Stomp atau memakai Message-Driven Beans yang dibungkus JRuby (I did these both). * Asynchronous Processing 4 Ruby (ap4r). * RailsCron. * BackgroundDRb. Seperti DRb (Distributed Ruby, think RMI-IIOP). Bedanya BDRb bisa kita schedule di background. Saya sendiri menaruh harapan besar di ap4r dan BackgroundDRb. Menjalankan Rails dengan backend ActiveMQ + Stomp + EJB3 MDBs seperti memiliki darah mudblood. Untuk menjadi pureblood, saya ingin mendepak semua MDB pake ap4r nantinya hehe... > > Kalau di ruby, library buat thread pool nya apa ? atau sudah ada bawaan > ruby ? saya pakai ruby 1.8.x bawaan ubuntu 7.04 server kalau lg di > windows, saya mengandalkan netbeans di dalamnya dah ada jruby on rails ^^ > Untuk production, saya sarankan pake Ruby 1.8.6 patchlevel 111. Problem threading problem sudah lumayan diperbaiki disitu (mongrel udah ga butuh fastthread dan multipart_cgi_eof_fix sepertinya optional). -- http://andryshuzain.com [Non-text portions of this message have been removed]
