kalau dibaca tulisan paul tyma, di bagian comment, dia mengakui bahwa akhirnya ada convergence antara long connection dengan thread per connection model. masalahnya, dia bilang nio lebih lambat, yang dia bela bukan scalability dari thread per connection model > multiple connection per thread-nya nio. dia cuma bilang kalau pake nio bisa lebih lambat dari connection oriented socket dalam hal pemroresan packet. sebenarnya itu tergantung underlying os-nya, dan dia tidak bicara bagaimana dia melakukan tuning untuk nio buffer-nya, jalankan di os apa.
nah, masalahnya dengan thread per connection model adalah, jumlah service yang bisa dijalan dalam satu waktu terbatas terhadap jumlah thread maksimum yang boleh dialokasi, sementara dengan asynchronous socket keterbatasan itu hanya terjadi di level operating system-nya dan resource yang kita memory alokasikan seberapa besar untuk masing2 server handler. by default, koneksi http 1.1 itu akan dipateng terus, tidak seperti pendahulunya http 1.0. 2009/9/17 Daniel Baktiar <dbakt...@gmail.com> > who says, nio is faster. nio is more scalable <> faster. > > 2009/9/16 uud ashr <uuda...@gmail.com> > >> >> >> FYI, tentang NIO (asynchronous IO) sempetada orang yang nyangkal nih, >> namanya Paul Tyma, lengkapnya bisa dibaca di -> >> http://paultyma.blogspot.com/2008/03/writing-java-multithreaded-servers.html >> >> http://mailinator.blogspot.com/2008/02/kill-myth-please-nio-is-not-faster-than.html >> >> >> 2009/9/16 Daniel Baktiar <dbakt...@gmail.com> >> >>> >>> >>> tomcat pakai thread pooling, begitu juga semua application server >>> lainnya. >>> >>> waktu tomcat start up, dia akan memiliki sejumlah worker thread, di >>> samping beberapa thread lain yg digunakan secara internal. >>> jumlah thread seharusnya bisa diatur melalui konfigurasi. >>> >>> idealnya jumlah worker thread disesuaikan dengan resource (memory, cpu, >>> heap, stack, socket/file descriptor) yang tersedia, karena apabila >>> berlebihan akan membuat kinerja sistem turun. >>> >>> untuk application server yang memiliki fitur ejb dan jms, biasanya >>> masing2 container tersebut akan memiliki pool dari worker thread-nya >>> sendiri. >>> >>> application server j2ee tradisional menggunakan 1 request dilayani oleh 1 >>> thread (misal tomcat dengan coyote connector - konfigurasi standar). >>> >>> apa yang membuat application server yang menggunakan thread pooling ini >>> tidak scalable adalah karena setiap request perlu di-assign thread sendiri. >>> sehingga untuk membuatnya scalable, biasanya dilakukan clustering. >>> >>> dengan menggunakan asynchronous socket, kita bisa membuat request >>> diterima oleh network layer (biasanya ada pada sistem operasi), dan hanya >>> berespon apabila ada event seperti packet network baru tersedia. dengan >>> demikian satu thread dapat melayani lebih dari satu request. worker thread >>> akan mendaftarkan suatu method callback, yang akan dipanggil/dinotifikasi >>> oleh layer network o/s apabila suatu packet selesai dikonstruksi. >>> notifikasi itu dapat direspon oleh thread tersebut segera atau kemudian bila >>> pekerjaan yang dikerjakan sedang selesai. >>> >>> masalah yang dihadapi dengan asynchronous socket adalah server perlu >>> mendeteksi apakah request sudah selesai atau belum (tidak seperti >>> synchronous socket dimana server dapat tahu request selesai dengan >>> ditutupnya koneksi oleh client). >>> >>> setau saya, pionir penggunaan asynchronous socket untuk web server adalah >>> grizzly connector di glassfish (grizzly connector awalnya adalah sub project >>> glassfish). sudah ada grizzly connector untuk jetty, dan sekarang pun sudah >>> ada untuk tomcat, tetapi bukan merupakan konfigurasi standar tomcat. >>> >>> 2009/9/16 Ifnu bima <ifnub...@gmail.com> >>> >>>> >>>> >>>> > untuk kasus yang arif katakan, kita bisa juga pertimbangkan untuk >>>> menggunakan asynchronous socket yang lebih scalable, dengan thread pooling, >>>> tanpa menggunakan MQ. kita baru benar2 perlu MQ kalau tidak boleh ada >>>> message yg hilang. >>>> >>>> Thread pooling ini sebenernya secara implementatif gimana ya? tomcat >>>> pake ga yah? >>>> >>>> gw baca2 satu masalah ini bisa jadi PHD topic >>>> >>>> http://www.eecs.harvard.edu/~mdw/proj/seda/ >>>> >>>> Secara konsep nggak terlalu susah sih, cuma untuk dapetin parameter >>>> yang tepat sepertinya perlu intuisi. Nah daripada intuisi nyarinya >>>> lama ada ga sih panduan "aman" untuk setting thread pool dengan >>>> parameter sistem seperti ini : >>>> tps : 10 >>>> server : Pentium 4 4ghz, memory 2gb >>>> load per message : light (nggak berat2 sampe query ke table yang >>>> gede, rata2 cuma ngedump data saja) >>>> >>>> -- >>>> Senior Engineer @ ArtiVisi Intermedia >>>> Java Training Center >>>> See our course @ artivisi.com >>>> >>>> http://ifnu.artivisi.com >>>> +62 856 9211 8687 >>>> regards >>>> >>>> >>> >>> >>> -- >>> Daniel Baktiar >>> Senior JEE* Monkey -- willing to work hard in the Java beans brewery for >>> a big bunch of bananas (http://dbaktiar.wordpress.com) >>> >>> >> >> > > > > -- > Daniel Baktiar > Senior JEE* Monkey -- willing to work hard in the Java beans brewery for a > big bunch of bananas (http://dbaktiar.wordpress.com) > -- Daniel Baktiar Senior JEE* Monkey -- willing to work hard in the Java beans brewery for a big bunch of bananas (http://dbaktiar.wordpress.com)
