Pada tahun 2019, gw mendapatkan kesempatan untuk menjadi lead di project myorder di tiket.com. Menurut gw project ini lumayan riweh karena pada dasarnya gw join belakangan trus dapat sisaan. Hanya saja dari project ini gw lumayan belajar mengenai mysql pooling, mysql query optimization dan yang terakhir adalah embedded server / servlet container. Jadi gampangnya, ketika menjalankan aplikasi springboot, biasanya ada servlet yang nempel didalamnya, dan kebetulan yang dipakai di tiket.com defaultnya adalah tomcat. Tetapi bukan hanya tomcat yang akan kita bahas, ada jetty dan juga undertow.
Balik lagi ke tahun 2019, waktu mengadakan performance test untuk mengukur kemampuan myorder yang baru, VP infra sempat bertanya ke gw mengenai kenapa hari gini masih menggunakan tomcat. Jujur waktu itu gw juga gatw, emang selain tomcat ada barang yang lain ya. Setelah proses panjang di myorder, gw menyempatkan diri untuk melihat-lihat barang yang lain itu yakni jetty dan undertow. Jujur aja, untuk saat ini untuk microservice yang gw pegang di tiket, sebagian besar sudah gw pindahkan dari menggunakan tomcat menjadi undertow. Tetapi tetap masih ada yang menggunakan tomcat karena yang gw pindahin hanya untuk microservice yang menggunakan springboot 2 / webflux.
Jadi bagaimana dengan implementasi tomcat itu sendiri? Karena pada dasarnya tomcat adalah default servlet container bawaan jadi tidak perlu konfigurasi khusus apa-apa. Untuk dependency versi gradlenya sebagai berikut.
|
1 |
implementation (group: 'org.springframework.boot', name: 'spring-boot-starter-web', version: '2.1.9.RELEASE') |
Untuk versi mavennya sebagai berikut :
|
1 2 3 4 |
<dependency> <groupid>org.springframework.boot</groupid> <artifactid>spring-boot-starter-web</artifactid> </dependency> |
Nah untuk mengecek aplikasi yang dibuat sudah jalan dengan menggunakan tomcat bisa melalui log ketika dijalankannya aplikasi. Seperti berikut ini :
Lanjut ke servlet berikutnya yakni jetty. Sebenarnya dulu gw sering ketuker-tuker antara netty dan jetty. Bahkan sempet minta anak tim gw untuk cari tau gimana cara pakai jetty dan netty. Padahal itu 2 barang yang berbeda, yang satu servlet yang satu lg async framework. Oke lanjut saja ke bagaimana cara pakainya di gradle :
|
1 2 3 4 5 |
implementation (group: 'org.springframework.boot', name: 'spring-boot-starter-web', version: '2.1.9.RELEASE') { exclude module: 'spring-boot-starter-tomcat' } implementation 'org.springframework.boot:spring-boot-starter-jetty' |
Nah untuk cara pakainya di maven :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
<dependency> <groupid>org.springframework.boot</groupid> <artifactid>spring-boot-starter-web</artifactid> <exclusions> <exclusion> <groupid>org.springframework.boot</groupid> <artifactid>spring-boot-starter-tomcat</artifactid> </exclusion> </exclusions> </dependency> <dependency> <groupid>org.springframework.boot</groupid> <artifactid>spring-boot-starter-jetty</artifactid> </dependency> |
Untuk cek apakah jetty berhasil telah dijalankan bisa liat bentuk lognya seperti berikut :
Oke, lanjut ke part yang terakhir yakni undertow. Sebenarnya dari semua servlet container, gw paling suka pake undertow karena cara menghitung threadpoolnya sangat straightforward dan konon katanya, responses time dan performancenya paling baik diantara dua yang gw sebutkan diatas. untuk cara pakainya di gradle sebagai berikut :
|
1 2 3 4 5 |
implementation (group: 'org.springframework.boot', name: 'spring-boot-starter-web', version: '2.1.9.RELEASE') { exclude module: 'spring-boot-starter-tomcat' } implementation 'org.springframework.boot:spring-boot-starter-undertow' |
Untuk di maven mirip dengan yang jetty cuma diganti aja starternya dari jetty ke undertow. Lalu setelah diimplement maka hasil lognya akan seperti berikut :
Setelah memahami cara implementasinya, yang paling penting dari semua ini adalah bagaimana cara setup threadpoolnya. Dengan melakukan setup threadpool yang benar maka kita akan menghindari yang namanya out of memory akibat kehabisan thread atau rejected task karena threadnya busy terus. Masing-masing punya cara implementasi yang berbeda dan hitungan yang beda juga. Secara pribadi gw lebih suka pakai undertow karena cara hitungnya gampang dan propertiesnya juga sedikit. Mungkin gw akan mulai dari undertow terlebih dahulu ya.
|
1 2 |
server.undertow.io-threads= (number of cpu) * 2 server.undertow.worker-threads= (number of cpu) * 10 |
Gampang banget bukan? Ga perlu pusing-pusing mikir ini itu karena undertow sudah membereskan semua. Undertow menggunakan XNIO berbeda dengan 2 temannya si jetty dan tomcat yang menggunakan NIO. Untuk penampakan threadnya di visualVM seperti berikut :
Lalu yang berikutnya adalah tomcat. Untuk tomcat sendiri, gw uda coba nyari-nyari setupnya yang benar begimana namun tetap gak ketemu. Langsung aja setupnya tomcat.
|
1 2 3 4 5 |
server.tomcat.threads.max=50 server.tomcat.threads.min-spare=10 server.tomcat.accept-count=10 server.tomcat.connection-timeout=1 server.tomcat.max-connections=15 |
Nah untuk tomcat, threadpoolnya dihitung berdasarkan min-spare dan max. Jadi kalau gampangnya, jika tidak ada sedang mengerjakan task maka thread yang ada akan berjumlah 10 kalau ada task yang banyak maka akan membuat thread sejumlah max threadnya yakni 50. Untuk accept-count sendiri adalah kapasitas queue yang diterima ketika thread sedang busy. Yang perlu diingat adalah max-connection dan connection timeout karena max-connection perlu hati-hati setupnya jika masih menggunakan BIO (Blocking I/O), hanya saja gw yakin saat ini sudah menggunakan NIO jadi tidak terlalu pusing. Untuk connection-timeout adalah waktu yang dibutuhkan untuk menunggu sebuah request di release.
Untuk penampakan threadnya di visualVM sebagai berikut :
Yang terakhir akan gw bahas adalah jetty. Untuk setup threadpoolnya jetty juga agak njelimet model-model tomcat. Btw ketika mencoba jetty dengan jmeter, gw juga menemukan bahwa dibanding undertow dan tomcat secara performance lebih baik tomcat daripada jetty (undertow tetap the best). Cuma balik lagi, beberapa bilang jetty lebih better dari tomcat. Nah untuk setup threadpoolnya sebagai berikut.
|
1 2 3 4 5 |
server.jetty.threads.idle-timeout=6000 //in miliseconds server.jetty.threads.max=500 server.jetty.threads.max-queue-capacity=50 server.jetty.threads.min=50 server.jetty.threads.selectors= (number of cpu - 1) |
Nah jetty secara setup mirip dengan tomcat, cuma dia ada hitungan pastinya model undertow. Biasanya untuk setup threadpool min dan max nya dikisaran 50 < x < 500. Nah ini gw gatw gimana cara hitungnya, cuma info dari sumbernya di jetty. Sedangkan queue capacity adalah kalau thread sedang sibuk, jumlah yang masuk queue seberapa besar. Untuk selector (belum tahu gunanya buat apa) hitungannya seperti yang gw share diatas. Terakhir untuk idle timeout adalah kalau thread sedang idle maka akan dikill setelah 6 s (hati-hati karena biasanya menggunakan second tapi di jetty pake miliseconds).
Untuk penampakannya di visualVM sebagai berikut :
Ok, demikian sedikit pengenalan mengenai tomcat, jetty dan undertow. Jika mungkin ada sanggahan dari kalian bisa ngobrol ya di komen. Untuk sumbernya akan gw cantumkan dibawah.
- https://netflixtechblog.com/tuning-tomcat-for-a-high-throughput-fail-fast-system-e4d7b2fc163f
- https://papweb.wordpress.com/2010/10/30/understanding-tomcat-executor-thread-pooling/
- https://docs.spring.io/spring-boot/docs/current/reference/html/appendix-application-properties.html
- https://www.eclipse.org/jetty/documentation/current/high-load.html
- https://examples.javacodegeeks.com/enterprise-java/spring/tomcat-vs-jetty-vs-undertow-comparison-of-spring-boot-embedded-servlet-containers/
- https://www.baeldung.com/spring-boot-servlet-containers
- https://stackoverflow.com/questions/14248172/configuring-jetty-for-high-request-volume/14248381
- http://undertow.io/undertow-docs/undertow-docs-1.4.0/index.html
- https://stackoverflow.com/questions/23263074/tomcat-server-xml-connection-timeout-configuration
- https://stackoverflow.com/questions/39644830/what-are-acceptcount-maxconnections-and-maxthreads-in-tomcat-http-connector-con
- https://stackoverflow.com/questions/24678661/tomcat-maxthreads-vs-maxconnections