BAB IV Pembahasan
4.2. Fase Pelaksanaan Eksperimen
4.2.3. Analisa, Intepretasi dan Generalisasi Hasil Eksperimen
Setelah melakukan pengujian pada seluruh parameter yaitu Transaction Throughput, Response Time, RSS Memory, CPU Usage dan Data Throughput maka akan dilakukan intepretasi pada data yang didapatkan dari hasil pengujian tersebebut.
Pengujian Pertama dilakukan untuk mengukur parameter yang termasuk dalam kategori performa system yaitu Transaction Throughput dan Response Time.
Adapun hasilnya dapat dilihat pada tabel dan grafik dibawah ini.
Table IV.3 rata-rata nilai Transaction Throughput per 1 detik
CONCURENCY HTTP THRIFT
20 159.9 315.4
40 130 751.3
60 161 706.9
80 133.4 866.7
42
100 178.9 813.8
120 169.8 765.5
140 164.8 990.2
160 157 896.3
180 134.1 1090.4
200 119.8 1293.3
Average 150.87 848.98
Dari tabel 4.3, dapat dilihat nilai rata-rata Transaction Throughput hasil pengujian dalam satuan per 1 detik pada masing-masing prototipe sistem. Untuk prototipe sistem dengan HTTP REST API memiliki nilai 150.87 TPS dan untuk prototipe sistem dengan Apache Thrift memiliki nilai 848.98 TPS.
Gambar IV.3 Nilai Transaction Throughput per 1 detik
Gambar 4.3 memperlihatkan nilai Transaction Throughput pada kedua protipe system. Nilai Transaction Throughput dikatakan bagus jika nilainya lebih tinggi. Dari grafik pada gambar 4.3, kita dapat melihat bahwa prototipe system dengan Apache Thrift memiliki nilai yang lebih tinggi di banding dengan prototipe system dengan HTTP REST API.
43 Dari tabel 4.3 dan gambar 4.3, dapat disimpulkan bahwa pada parameter Transaction Throughput dalam satuan TPS (Transaction per Second), prototipe system dengan Apache Thrift memiliki nilai TPS yang significant lebih tinggi dibandingkan dengan prototipe system dengan HTTP REST API.
Table IV.4 nilai rata-rata response time dalam satuan milisecond
CONCURENCY HTTP THRIFT
20 49.6 27.2
40 163.8 37.1
60 66.3 231.3
80 296.1 75.4
100 328.8 113.1
120 505.7 200.2
140 542.4 158.9
160 656.1 251.7
180 756.5 195.3
200 780.9 117.9
Average 414.62 140.81
Dari tabel 4.4, dapat dilihat nilai rata-rata Response Time hasil pengujian dalam satuan millisecond pada masing-masing prototipe sistem. Untuk prototipe system dengan HTTP REST API memiliki nilai 414.62 ms dan untuk prototipe sistem dengan Apache Thrift memiliki nilai 414.62 ms
44 Gambar IV.4 Nilai Response Time dalam satuan millisecond
Gambar 4.4 memperlihatkan nilai Response Time pada kedua protipe system. Nilai Response Time dikatakan bagus jika nilainya lebih rendah. Dari grafik pada gambar 4.4, kita dapat melihat bahwa prototipe system dengan Apache Thrift memiliki nilai yang lebih rendah di banding dengan prototipe system dengan HTTP REST API.
Dari tabel 4.4 dan gambar 4.4, dapat disimpulkan bahwa pada parameter Response Time dalam satuan millisecond, prototipe system dengan Apache Thrift memiliki nilai yang significant lebih cepat dan stabil walaupun dengan penambahan jumlah concurrent dibandingkan dengan prototipe system dengan HTTP REST API.
Untuk pengujian kedua dilakukan untuk mengukur parameter yang termasuk dalam kategori kinerja computer yaitu RSS Memory, CPU Usage dan Data Throughput. Adapun hasilnya dapat dilihat pada dan grafik dibawah ini.
45 Gambar IV.5 Grafik RSS Memory
Pada gambar 4.5 memperlihatkan RSS Memory pada kedua protipe system, nilai RSS Memory dikatakan lebih bagus jika nilainya lebih rendah. Dari grafik pada gambar 4.5, kita dapat melihat bahwa prototipe system dengan Apache Thrift (warna ungu) memiliki nilai yang lebih rendah di banding dengan prototipe system dengan HTTP (warna biru).
Gambar IV.6 Most Intensive RSS Memory
Dari gambar 4.6, dapat dilihat nilai rata-rata RSS Memory hasil pengujian dalam satuan MiB (megabytes) pada masing-masing prototipe sistem. Untuk prototipe system dengan HTTP REST API memiliki nilai 128 MiB dan untuk prototipe sistem dengan Apache Thrift memiliki nilai 108 MiB
46 Dari gambar 4.5 dan 4.6, dapat disimpulkan bahwa pada parameter RSS Memory dalam satuan megabytes, prototipe system dengan Apache Thrift memiliki nilai yang lebih kecil dibandingkan dengan prototipe system dengan HTTP REST API.
Gambar IV.7 Grafik CPU Usage
Pada gambar 4.7 memperlihatkan CPU Usage pada kedua protipe system, nilai CPU Usage dikatakan lebih bagus jika nilainya lebih rendah. Dari grafik pada gambar 4.7, kita dapat melihat bahwa prototipe system dengan Apache Thrift (warna ungu) memiliki nilai persentase yang lebih rendah di banding dengan prototipe system dengan HTTP (warna biru).
47 Gambar IV.8 Most Intensive CPU Usage
Dari gambar 4.8, dapat dilihat nilai rata-rata CPU Usage hasil pengujian dalam satuan MiB (megabytes) pada masing-masing prototipe sistem. Untuk prototipe system dengan HTTP REST API memiliki persentase 49.35%dan untuk prototipe sistem dengan Apache Thrift memiliki nilai 27.24 %
Dari gambar 4.7 dan 4.8, dapat disimpulkan bahwa pada parameter CPU Usage, prototipe system dengan Apache Thrift memiliki nilai yang lebih kecil dibandingkan dengan prototipe system dengan HTTP REST API.
Gambar IV.9 Grafik Data Throughput
Pada gambar 4.9 memperlihatkan Data Throughput pada kedua protipe system, nilai Data Throughput dikatakan lebih bagus jika nilainya lebih tinggi. Dari
48 grafik pada gambar 4.9, kita dapat melihat bahwa prototipe system dengan Apache Thrift (warna ungu) memiliki nilai persentase yang lebih rendah di banding dengan prototipe system dengan HTTP (warna biru).
Gambar IV.10 Most Intensive Data Throughput
Dari gambar 4.10, dapat dilihat nilai rata-rata Data Throughput hasil pengujian dalam satuan KiB/s (KiloBytes per Second) pada masing-masing prototipe sistem. Untuk prototipe system dengan HTTP REST API memiliki kecepatan 213 KiB/s dan untuk prototipe sistem dengan Apache Thrift memiliki nilai 244 KiB/s
Dari gambar 4.9 dan 4.10, dapat disimpulkan bahwa pada parameter Data Throughput, prototipe system dengan Apache Thrift memiliki kecepatan yang lebih tinggi, dengan kata lain ukuran paket data yang dikirim antara service dalam prototipe dengan Apache Thrift memiliki ukuran yang lebih kecil disbanding dengan prototipe system dengan Apache Thrift.
Dari seluruh hasil analisa eksperimen menunjukan bahwa implementasi Apache Thrift lebih unggul di semua parameter-parameter yang diujikan dibandingkan dengan implementasi menggunakan HTTP REST API. Seperti yang kita bisa lihat pada tabel dan grafik dibawah ini.
49 Table IV.5 Rangkuman Nilai Seluruh Parameter
Parameter HTTP THRIFT
Transaction Throughput 150.87 848.98
Response Time (lebih kecil, lebih baik) 414.62 180.41
RSS Memory (lebih kecil, lebih baik) 128 108
CPU Usage (lebih kecil, lebih baik) 49.35 27.24
Data Throughput 213 244
Gambar IV.11 Grafik Rangkuman Nilai Seluruh Parameter
Dari hasil diatas, penulis dapat mebuat persentase peningkatan performa pada semua parameter-parameter yang diujikan dengan menjadikan implementasi mengunakan HTTP REST API sebagai baseline-nya dengan mengunakan formula yang sudah digunakan di PT.Midtrans yang didapatkan ketika proses wawancara adalah sebagai berikut:
100 + ℎ%%&'()*+ − %ℎ-./%'()*+ ÷ ℎ%%&'()*+ ×100
50 Adapun persentase peningkatan performa bisa diliat pada tabel dan grafik dibawah ini.
Table IV.6 Table Persentase Peningkatan Performa
Parameter HTTP THRIFT
TPS 100 562.72
Response Time 100 156.48
RSS Memory 100 115.62
CPU Usage 100 144.80
Data Throughput 100 114.55
Gambar IV.12 Grafik Presentase Peningkatan Performa
51 BAB V
Kesimpulan dan Saran
Pada bab ini berisikan kesimpulan dari penelitian yang telah penulis lakukan beserta saran – saran yang bisa digunakan untuk pengembangan penelitian selanjutnya.
5.1. Kesimpulan
Berdasarkan hasil dari pengukuran performa sistem dan kinerja komputer terhadap 2 prototipe sistem PT. XYZ yang masing-masing menggunakan implementasi HTTP REST API dan Apache Thrift dengan menggunakan performance testing tool, maka dapat ditarik kemsimpulan bahwa pengukuran dalam penelitian ini dapat diujikan. Berdasarkan 5 parameter yang diujikan yaitu Transaction Throughput, Response Time, RSS Memory, CPU usage, dan Data Throughput, berikut adalah kesimpulan dari pengukuran yang telah dilakukan:
1) Pada parameter Transaction Throughput dalam kategori performa sistem, prototipe sistem dengan implementasi Apache Thrift unggul dengan nilai
848.98 TPS yang berarti implementasi ini menghasilkan performa lebih baik dalam hal berapa banyak request yang bisa ditangani oleh sistem secara bersamaan dalam setiap satu detiknya. Secara presentase implementase Apache Thrift meningkatkan Transaction Throughput sebanyak 5 kali lebih banyak atau 562.722874 % dibanding dengan implementasi HTTP REST API yang hanya menghasilkan 150.87 TPS.
52 2) Untuk parameter Response Time, implementasi Apache Thrift menghasilkan nilai 180.41 millisecond, implementasi Apache Thrift ini 2 kali lipat atau 229.8209634 % lebih cepat dibandingkan dengan implementasi HTTP REST API yang hanya memperoleh nilai 414.62 millisecond dalam hal processing time ketika menangani request yang dibuat pengguna.
3) Pada parameter RSS Memory, implementasi Apache Thrift unggul di angka 108 MB atau 18% dibandingkan dengan implementasi HTTP REST API yang memperoleh nilai 128 MB, hal ini menunjukan bahwa memory management pada Apache Thrift lebih efesien dibandingkan dengan implementasi HTTP REST API.
4) Pada parameter CPU Usage, Implementasi Apache Thrift masih lebih unggul dengan memperoleh nilai 27.24 % atau hampir setengah dari nilai implementasi HTTP REST API yang memperoleh nilai 49.35 %. Sama dengan parameter RSS Memory, semakin kecil nilai yang didapat dapat diartikan penggunaan CPU dalam implementasi Apache Thrift lebih efesien dibandingkan dengan HTTP REST API.
5) Untuk parameter Data Throughput, Implementasi Apache Thrift menghasilkan angka yang lebih cepat yaitu 213 kbps lebih unggul 14.5539906% lebih cepat debandingkan dengan implementasi HTTP REST API yang memperoleh nilai 244 kbps, hal ini menunjukan ukuran paket data yang ditransfer antar servis mempunyai pada implementasi Apache Thrift memiliki ukuran yang lebih kecil di bandingkan dengan HTTP REST API.
53 5.2. Saran
Berdasarkan hasil pengujian dan pengukuran yang dilakukan pada penelitian ini, untuk mendapatkan hasil yang lebih baik maka peneliti menyarankan:
1) Penambahan parameter pengujian seperti Disk I/O, Disk space , application error rate dll.
2) Melakukan pengukuran untuk parameter kinerja Komputer dalam keadaan idle.
3) Penambahan perlakuan pengujian seperti endurance test atau stress test.
4) Penggunaan resource sungguhan pada prototipe sistem seperti penggunaan MySQL, Redis, RabbitMQ dll .
5) Menggunakan Framework RPC dengan binary protocol lainnya seperti ProtoBuff
6) Menggunakan arsitektur microservice yang lebih lebih besar, dalam hal jumlah servis didalamnya.
54 Daftar Pustaka
Aigner, M., & Baumgartner, A. (2010). Google Go!. Retrieved September 03, 2016, from http://go-lang.cat-v.org/talks/slides/seminar-aus-informatik- aigner-baumgartner.pdf
Babović, J., Raičević, V., & Carić, M. (2012). Benchmarking as a function of competitiveness and efficiency in business. Econ Agric, 59, 115-126.
Birrell, A. D., & Nelson, B. J. (1983). Implementing Remote procedure calls.
ACM SIGOPS Operating Systems Review SIGOPS Oper. Syst. Rev., 17(5), 3. doi:10.1145/773379.806609
Boettiger, C. (2015). An introduction to Docker for reproducible research. ACM SIGOPS Operating Systems Review SIGOPS Oper. Syst. Rev., 49(1), 71- 79. doi:10.1145/2723872.2723882
Bui, T. (2015). Analysis of docker security. arXiv preprint arXiv:1501.02967.
Clark, K. L., & McCabe, F. G. (2004). Go!—a multi-paradigm programming language for implementing multi-threaded agents. Annals of Mathematics and Artificial Intelligence, 41(2-4), 171-206.
Datadog, Inc. (n.d.). Getting Started with the Agent. Retrieved September 03, 2016, from http://docs.datadoghq.com/guides/basic_agent_usage/
Elmuti, D., & Kathawala, Y. (1997). An overview of benchmarking process: A tool for continuous improvement and competitive advantage.
Benchmarking Qual Mgmt & Tech Benchmarking for Quality Management & Technology, 4(4), 229-243.
doi:10.1108/14635779710195087
Flanagan, D., & Matsumoto, Y. (2008). The Ruby programming language.
Beijing: O'Reilly.
Florent Bruneau (2013). Memory – Part 2: Understanding Process memory.
Retrieved September 03, 2016, from
https://techtalk.intersec.com/2013/07/memory-part-2-understanding- process-memory/.
Halili, E. H. (2008). Apache JMeter: A practical beginner's guide to automated testing and performance measurement for your websites. Birmingham: Packt Pub.
Hussain, S., Wang, Z., Toure, I. K., & Diop, A. (2013). Web service testing tools: A comparative study. arXiv preprint arXiv:1306.4063.
Ian Molyneaux (2009). The Art of Application Performance Testing. Auckland:
O'Reilly Media.
55 Jeff Atwood (2008). Understanding User and Kernel Mode. Retrieved September
03, 2016, from https://blog.codinghorror.com/understanding-user-and- kernel-mode.
Kamburugamuve, S., Fox, G., Leake, D., & Qiu, J. (2013). Survey of Apache Big Data Stack (Doctoral dissertation, Ph. D. Qualifying Exam, Dept. Inf.
Comput., Indiana Univ., Bloomington, IN).
Lenz, P. (2008). Simply Rails 2. SitePoint.
Massé, M. (2012). REST API design rulebook. Sebastopol, CA: O'Reilly.
Matthias, K., & Kane, S. P. (2015). Docker: Up and running. Sebastopol, CA:
O’Reilly
Meade, P. (1998). A guide to benchmarking. Dunedin, N.Z.: University of Otago.
Nevedrov, D. (2006). Using JMeter to Performance Test Web Services.Published on dev2dev (http://dev2dev. bea. com/).
Slee, M., Agarwal, A., & Kwiatkowski, M. (2007). Thrift: Scalable Crosslanguage Services Implementation.
Tate, B. (2006). From Java to Ruby: Things every manager should know. Raleigh, NC: Pragmatic Bookshelf.
Thomas, D., & Hunt, A. (2001). Programming in Ruby. Dr. Dobb’s Journal, 5.
Tilkov, S., & Vinoski, S. (2010). Node.js: Using JavaScript to Build High-
Performance Network Programs. IEEE Internet Computing, 14(6), 80-83.
doi:10.1109/mic.2010.145
Turnbull, J. (2014). The Docker book. James Turnbull.
Watson, G. H. (1993). Strategic benchmarking: How to rate your company's performance against the world's best. New York: J. Wiley and Sons
56
Lampiran A
Surat Keterangan Bimbingan
Skripsi
57
58
Lampiran B
Hasil Wawancara
59 Narasumber : John Doe (Nama Alias)
Jabatan : Software Engineer Tanggal : 24 Februari 2016
Tempat : Ruang Meeting 1 PT. XYZ
Tujuan : Mengetahui Arsitektur sistem didalam PT. XYZ dan aspek apa yang bisa diimprovisasi didalamnya.
Pertanyaan 1 : Arsitektur sistem apa yang di terapkan didalam keseluruhan sistem PT. XYZ ?
Jawaban 1 : Sebenarnya secara desain pertama sejak awal perusahaan ini dibangun oleh CEO kita, nggak pernah ada omongan kalau kita pakai arsitektur A, B atau C, kita jalan aja dengan kerangka dasar sistem yang sudah ada. namun seiring berjalanya waktu, sistem kami terus berevolusi menyesuaikan dengan terapan teknologi yang terus berkembang sampai pada akhirnya keadaan sistem kami saat ini yang biasanya disebut dengan arsitektur microservice.
Pertanyaan 2 : Mengapa arsitektur tersebut cocok bagi organisasi anda ?
Jawaban 2 : Kalau dibilang cocok, saya hanya mau tegaskan, saat ini kami cocok dengan arsitektur ini, tapi bukan berarti kami akan terus implement arsitektur ini tanpa
60 mempertimbangkan perkembangan teknologi di kemudian hari. kalau mengapa cocok saat ini?, hmmm ... mungkin karena kebutuhan bisnis yang sangat cepat, yang mana kadang kala dalam hal bisnis kita butuh experimen. karena hal itu kami butuh sistem yang dapat mudah menerapkan eksperimen tersebut. untuk dapat membuat yang seperti itu, kami perlu membagi atau memecah domain-domain masalah menjadi lebih kecil, semakin kecil domain masalahnya semakin kecil solusinya, semakin kecil effort nya dan semakin kecil pula juga resikonya terhadap keseluruhan sistem.
disamping itu dengan microservice kita tidak terikat dengan satu stack ataupun bahasa pemrograman, kita bisa pilih bahasa pemrograman atau stack apa saja yang paling sesuai untuk menjadi solusi bagi domain masalah tersebut. ditambah semakin polyglot kita semakin mudah kami merekrut talent, karena kami menerima banyak bahasa pemrograman hahaha.
Pertanyaan 3 : Keuntungan apa yang ada dapatan dengan mengimplementasikan arsitektur microservice yang tidak di dapat dari arsitektur lainya?
Jawaban 3 : Seperti yang saya jelaskan barusan, untuk hal yang lebih technical lagi, dengan arsitektur microservice
61 karena yang nature sifatnya memecahkan domain masalah menjadi lebih kecil, maka dengan automatis semakin kecil juga scope masalah yang harus kita perbaiki ketika terjadi incident dalam sistem kita.
perumpamaan saja sebuah mesin motor, kalau saja mesin motor itu tidak modular semisal fungsi piston dan karburator itu terdapat dalam satu modul katakan saja modul A, maka apabila karburator tidak berfungsi dengan baik maka yang akan kita perbaiki adalah si modul A. memperbaiki modul A dengan tujuan membuat karburator kembali berfungsi dengan baik kita harus tetap memperhatikan fungsi piston juga, karena fungsi pisto dan karburator dalam contoh ini berada dalam satu modul yang saling terikat. untungnya di dunia nyata tidak begitu, karburator dan piston adalah modul yang terpisah yang bisa kita optimalkan masing-masing, menurut saya itulah microservice dalam contoh sehari-hari.
Pertanyaan 4 : Menurut anda adakah kelemahan dari arsitektur ini ?
Jawaban 4 : No rose without thorn, media komunikasi salah satunya, karena setiap service dalam arsitektur ini saling berkomunikasi antar service lainya, dimana
62 hampir semua pasti berkomunikasi over network, dan ketika kita bicara soal network ada latency dan lain sebagainya. sebagus atau seoptimal apapun sevice yang dibuat akan tetap underperform secara the whole system apabila komunikasinya tidak optimal. dan disini kami umumnya dan bisanya memilih HTTP untuk media komunikasi antar sevice dengan pendekatan REST API
Pertanyaan 5 : Mengapa HTTP dengan REST API menjadi pilihan populer sebagai media komunikasi dalam sistem yang organisasi anda kembangkan ?
Jawaban 5 : karena konsep HTTP adalah konsep paling umum dan dasar menurut saya ya. semua backend engineer pasti tau bagaimana konsep HTTP, karena ini diterapkan dimana-mana kan, di browser, mobile dan lain sebagainya.
Pertanyaan 6 : Menurut anda apa yang bisa di maximalkan dari arsitektur sistem yang organisasi anda kembangkan
?
Jawaban 6 : Pastinya media komunikasi, semakin optimal performa media komunikasinya sudah pasti otomatis semakin optimal sistem kita perform secara keseluruhan. sebagai contoh HTTP, sesuai namanya HyperText Transfer
63 Protocol. media ini menggunakan format text yang mana secara ukuran paket data dalam network lebih besar jika dibandingkan dengan protocol dengan format lain, semisal Apache Thrift dengan binary protocol- nya.
Pertanyaan 7 : Parameter apa saja yang bisa dijadikan ukuran untuk sebuah media komunikasi dalam arsitektur sistem yang organisasi and kembangkan ?
Jawaban 7 : Hmm ... pertanyaan bagus. pastinya harus cepat, untuk cepat pastinya harus memiliki ukuran packet data over network yang kecil, low CPU dan memory usage, dan pastinya meningkatkan response time secara keseluruhan sistem dan juga semakin banyak jumlah transaksi dalam satu detik yang dapat diprosess sistem secara bersamaan atau kami biasa sebut TPS (transacion per second).
64
Lampiran C
Hasil Pengamatan Eksperimen
65
66 Lampiran JMeter – Response Time untuk 10 Concurrency
Lampiran JMeter – Throughtput untuk 10 Concurrency
67 Lampiran JMeter – Response Time untuk 20 Concurrency
Lampiran JMeter – Throughtput untuk 20 Concurrency
68 Lampiran JMeter – Response Time untuk 40 Concurrency
Lampiran JMeter – Throughtput untuk 40 Concurrency
69 Lampiran JMeter – Response Time untuk 60 Concurrency
Lampiran JMeter – Throughtput untuk 60 Concurrency
70 Lampiran JMeter – Response Time untuk 80 Concurrency
Lampiran JMeter – Throughtput untuk 80 Concurrency
71 Lampiran JMeter – Response Time untuk 100 Concurrency
Lampiran JMeter – Throughtput untuk 100 Concurrency
72 Lampiran JMeter – Response Time untuk 120 Concurrency
Lampiran JMeter – Throughtput untuk 120 Concurrency
73 Lampiran JMeter – Response Time untuk 140 Concurrency
Lampiran JMeter – Throughtput untuk 140 Concurrency
74 Lampiran JMeter – Response Time untuk 160 Concurrency
Lampiran JMeter – Throughtput untuk 160 Concurrency
75 Lampiran JMeter – Response Time untuk 180 Concurrency
Lampiran JMeter – Throughtput untuk 180 Concurrency