Seminar Nasional Pascasarjana IX ITS, Surabaya 12 Agustus 2009

ISBN No.

Gateway Transaksi Realtime Dengan Agen Web Server dan

Agen MultiPorting

Sunaryono Dwi, Lianto Joko

Jurusan Informatika, Fakultas Teknologi Informasi, Institut Teknologi Sepuluh Nopember

Kampus ITS, Jl. Raya ITS, Sukolilo Surabaya 60111, Indonesia
Tel. + 62 31 5939214, Fax. + 62 31 5913804
email : dwi@its-sby.edu , joko@its-sby.edu

Abstrak
Transaksi realtime mengandalkan pada teknologi komputasi terdistribusi antara lain RPC
(Remote Procedure Calls), RMI (Remote Method Invocation), DCOM (Distributed Component Object
Model), dan CORBA (Common Object Request Broker Architecture). Dasar teknologi tersebut bersifat
client-server yang dedicated antara client dan server nya sehingga mengalami hambatan dalam cross
platfrom antara teknologi satu dengan lainnya. Teknologi web service merupakan sebuah teknologi
lanjutan dari komputasi terdistribusi yang mampu cross platform. Teknologi cross platform lain adalah web
server. Transaksi realtime pada web server dapat diteliti untuk memberikan alternatif pilihan pada
penggunaan teknologi transaksi realtime. Tantangan transaksi realtime pada web server menjadi bahan yang
penting untuk diteliti. Selain itu , apakah web server mampu menjadi gateway transaksi realtime ?
Pada penelitian ini dirancang sebuah arsitektur gateway yang menggambarkan keterlibatan
sebuah agen yang terpasang pada web server dan sebuah agen multiporting untuk penanganan transaksi
secara pararel yang menjadi syarat transaksi realtime. Pengukuran transaksi realtime adalah waktu
layanan yang diukur dalam transaction per second (tps). Web Server menangani permintaan port dengan
membuat session per masing-masing permintaan, kemudian masing-masing session ditangani oleh
proses bisnis yang menjadi wilayah agen multiporting, di situ telah terbuka port-port secara pararel. Satu
port agen menjamin satu transaksi yang terhubung ke database transaksi. Arsitektur pada penelitian ini,
akan diuji coba untuk mengetahui performansi sistem. Uji coba dilakukan dengan melakukan penambahan
jumlah server dan request dari sejumlah komputer client yang mencerminkan transaksi secara terus
menerus.
Hasil uji coba arsitektur sistem yang dirancang, berhasil memenuhi tps tertinggi dari uji
labolatorium 259,59. Dari uji lapangan sistem selama 7 bulan pengamatan, maka sistem telah teruji di
lapangan berjalan tanpa henti dengan tps tertinggi 202,63.

kata kunci: web server, agen , multiport, realtime, load balancing.

1. Pendahuluan bersifat client server yang dedicated antara client

Respon time adalah salah satu indikator
kunci kepuasan dari end user dalam
menggunakan layanan web. Pengakses web
mempunyai aneka pilihan terhadap waktu respon
ini, dan hanya akan mengambil layanan web
yang respon time-nya tidak melebihi ambang
batas yang bisa diterima (Watson T.J ; Jason
Nieh, 2007). Pengelolaan respon time ini
difokuskan pada kontrol respon time dari web
server saat individu URL meminta layanan web
server (Olshefski D.; J. Nieh ; D. Agrawal, 2004).
Pada perkembangannya, layanan web
server berbentuk dua jenis yaitu halaman statis
dan halaman dinamis. Halaman dinamis,
pengelolaan respon time banyak dipengaruhi
waktu akses I/O khususnya ketika berkaitan
dengan database. (Holmes Victor P.; Wilbur R.
Johnson, David J. Miller, 2008)
Pada perkembangannya program
desktop base dikembangkan pada teknologi
komputasi terdistribusi antara lain RPC (Remote
Procedure Calls), RMI (Remote Method
Invocation), DCOM (Distributed Component
Object Model), dan CORBA (Common Object
Request Broker Architecture). Sama dengan
desktop base, basis dari teknologi tersebut
dan servernya sehingga mengalami hambatan
dalam cross platfrom antara teknologi satu
dengan lainnya (Tsai, W.T. Fan, Chun. Chen,
Yinong. Paul, Raymond. Chung, Jen-Yao., 2006)
Transaksi yang bersifat terbuka,
sebagaimana konsep internet yang dapat diakses
di sembarang platform, dapat menjadikan
transaksi tersebut diikuti oleh client dengan
keragaman platform.
Sebuah transaksi realtime pada web
server umumnya memakai teknologi SOAP
(Simple Object Access Protocol). SOAP adalah
protokol untuk pertukaran informasi yang
terdesentralisasi dan terdistribusi. SOAP
dibangun dengan menggunakan protokol
komunikasi HTTP. Karena HTTP didukung oleh
semua browser dan server, maka SOAP dapat
berkomunikasi dengan berbagai aplikasi
meskipun terdapat perbedaan sistem operasi,
teknologi, dan bahasa pemrogramannya.
Klaim dari model SOAP tersebut adalah
Transaksi realtime dirancang untuk memberikan
respon terhadap permintaan dengan memenuhi
syarat, status klaim atau informasi otorisasi.
Umumnya (permintaan dengan satu client
tunggal), rata-rata respon waktu harus dalam 15
 Seminar Nasional Pascasarjana IX ITS, Surabaya 12 Agustus 2009
detik. Waktu respon bergantung atas aktivitas
transaksi realtime (Highmark, Inc, 2008).
Variasi dari arsitektur SOAP yaitu dengan
memakai arsitektur OO (Object Oriented) yang
terdistribusi seperti yang terlihat pada gambar
1.2. (Van der Mei ,R.D.; W.K. Ehrlich; P.K.
Reeser; J.P. Francisco, 2000)
Gambar 1.2 Web Server dalam berbagai lingkungan
terdistribusi
Pada gambar 1.2 menunjukkan sejumlah client
mengakses sebuah web server, kemudian oleh
web server, client diteruskan (forward) ke
sebuah aplikasi yang terdistribusi atau remote
aplication. Web server akan menunggu beberapa
saat sampai jawaban dari aplikasi tiba kembali
ke web server. Pada lingkungan web sever
dengan aplikasi terdistribusi, didapatkan jumlah
tps adalah 177 (Van der Mei ,R.D.; W.K. Ehrlich;
P.K. Reeser; J.P. Francisco, 2000).
Pada penelitian ini, masalah cross
platform dan transaksi realtime akan dijadikan
fokus utama untuk diteliti. Masalah cross
platform dijawab oleh pemilihan teknologi web
server, kemudian masalah realtime ditangani
agen multiporting .
2. Definisi Software Agent
Di dalam kamus Websters New World
Dictionary [Guralnik, 1983], agent didefinisikan
sebagai: A person or thing that acts or is capable
of acting or is empowered to act, for another.
Agen mempunyai kemampuan untuk
melakukan suatu tugas/pekerjaan.
Agen melakukan suatu tugas/pekerjaan
dalam kapasitas untuk sesuatu, atau
untuk orang lain.
3. Web Server
Web server adalah software yang
menjadi tulang belakang dari world wide web).
Web server menunggu permintaan dari client
yang menggunakan browser seperti Netscape
Navigator, Internet Explorer, Modzilla, dan
program browser lainnya. Jika ada permintaan
dari browser, maka web server akan memproses
permintaan itu kemudian memberikan hasil
prosesnya berupa data yang diinginkan kembali
ke browser. Data ini mempunyai format yang
standar, disebut dengan format SGML standar
general markup language).
Web server, untuk berkomunikasi
dengan client-nya (web browser) mempunyai
protokol sendiri, yaitu HTTP (hypertext tarnsfer
protocol). Dengan protokol ini, komunikasi antar
web server dengan client-nya dapat saling
ISBN No.
dimengerti dan lebih mudah (Lu Jijun ; Swapna
S. Gokhale, 2005).
4. HTTP
Pada RFC 2616 didefinisikan : The
Hypertext Transfer Protocol (HTTP) is an
application-level protocol for distributed,
collaborative, hypermedia information systems.
HTTP dimulai digunakan oleh WWW
pada tahun 1990 dengan versi HTTP/0.9,
dikembangkan menjadi HTTP/1.0 dengan
RFC1945, yang memungkinkan dokumen
diformat MIME. HTTP juga merupakan protokol
yang digunakan antara user agent dengan
proxy/gateway ke sistem internet lain, misal
SMTP, FTP, NNTP, FTP, Gopher dan WAIS
(Bellamy William Jr,2002).
4. Socket
Socket erat kaitannya dengan port, yaitu
salah satu cara untuk komunikasi antar
komputer, umumnya lewat network atau internet.
Socket biasa digunakan untuk pemrograman
berbasis client-server yang dapat menggunakan
socket TCP/IP atau socket UDP (Spero Simon E,
tanggal akses 5/5/2009). Pada penelitian ini agen
multiporting memakai mekanisme socket dalam
bahasa java untuk membuat port terbuka
5. Arsitektur Sistem Gateway Transaksi
Pada penelitian ini, sistem dibuat
berbasis web sebagai gateway transaksi.
Kemampuan web server yang cross platform
merupakan pilihan yang cocok untuk mengatasi
berbagai macam vendor dengan berbagai
macam platform. Masing-masing vendor akan
mengakses gateway untuk mendapatkan
transaksi.
Pertama kali vendor akan melakukan
inquiry untuk melihat sebuah transaksi dalam port
80 (port web server), kemudian permintaan tsb di
kirim ke gateway. Di sisi server (sebagai
gateway) permintaan tsb diterima oleh agen web
server (yang listen pada port 80), kemudian oleh
agen web server dibuat session per masing-
masing permintaan. Oleh Agen web server,
permintaan tsb diteruskan (forward) ke sebuah
load balancer (1:N).
Sifat dari load balancer (1 port untuk
input dan N port untuk output) mencerminkan
bahwa agen web server meneruskan ke dalam
satu port load balancer untuk kemudian oleh
load balancer dipilihkan port yang masih tersedia
(idle) dalam range sejumlah port (1..N).
Setelah port yang sesuai telah
dipilihkan, maka proses permintaan oleh vendor
dilanjutkan dalam port tsb, dimana masing-
masing port (1..N port) yang telah dibuka
sebelumnya. Port (1..N) . Saat proses permintaan
oleh vendor tiba dalam sebuah port yang sesuai,
maka agen multiporting telah pula siap dengan
sejumlah aturan proses bisnis maupun koneksi
ke database yang bersifat selalu open (secara
random akan reset dalam jumlah beberapa kali
transaksi). Setelah permintaan vendor masuk ke
dalam agen multiporting, maka sintak transaksi
 Seminar Nasional Pascasarjana IX ITS, Surabaya 12 Agustus 2009
(inquiry) yang telah disepakati dalam transaksi
akan diubah oleh agen multiporting kedalam
sintak pemanggilan sebuah store procedure yang
telah disimpan dalam database.
Kemudian database mengirimkan hasil
inquiry tersebut ke agen multiporting sebagai
sebuah text panjang dengan pembatas (delimiter)
yang telah disepakati antara gateway dengan
vendor (dalam hal ini adalah tanda ~)
Setelah agen multiporting menerima
hasil text tersebut, maka agen meneruskan hasil
tsb ke agen web server yang kemudian oleh
agen web server dikirimkan sebagai respon dari
permintaan inquiry. Arsitektur rancangan sistem
secara garis besar ditunjukkan pada gambar 6.1
Gambar 6.1 Arsitektur Sistem Gateway Transaksi
Dari gambar 6.1 terlihat urutan request ke dalam
web server, kemudian diterima oleh load
balancer dalam 1 port input dan N port output
6.1. Agen Web Server
Sebuah agen web server merupakan
program servlet berupa program java yang
terpaket dalam ekstensi .jar (java archive) dan
sudah dalam bentuk bytecode. Hal ini berbeda
dengan program script (jsp) biasa yang harus
diubah terlebih dahulu ke dalam bentuk servlet
agar dapat berjalan
Agen dalam bentuk byte code hanya
berisi pattern atau pola dari permintaan untuk
kemudian diteruskan ke agen web service yang
terlebih dahulu melalui sebuah balancer port.
Dari balancer itulah penugasan akses port
didapatkan
Pertama kali permintaan muncul, maka
secara otomatis web server akan membuat
sebuah session dan menangani session tersebut.
Session itu dimuat dalam memori, sehingga
semakin besar halaman web dan semakin
komplek program yang ditangani, maka semakin
besar pula memori untuk session tsb yang
dicadangkan.
Pengelolaan web server sebagai
sebuah agen, membuat session yang relatif kecil
(dilihat dari kode program) dan tidak terbebani
oleh akses I/O, sehingga penanganan atas
permintaan dapat semakin responsif dan dalam
jumlah penanganan permintaan yang relatif
cukup besar secara bersamaan.
Kemudian agen akan meneruskan
session tsb ke web service yang telah menunggu
sebagai pintu yang terbuka untuk melayani
transaksi dengan bukaan pintu (multiport) yang
cukup banyak (tergantung dari jumlah memori
dan kecepatan komputer didatabase servernya).
Dari konsep inilah, maka suatu session tidak
ISBN No.
perlu menunggu atau antri terhadap layanan
yang tersedia, karena agen web service sudah
dibiakkan hingga sejumlah memori yang optimal
6.2. Agen Multiporting
Agen multiporting berada pada
komputer yang terpisah dan secara khusus
menangani proses bisnis. Agen ini dibiakkan
hingga sejumlah layanan dengan membuka
layanan pada sejumlah port (multiport) yang
bergantung pada jumlah memori yang tersedia
dan kecepatan akses database server
Saat pertama dijalankan, maka agen
multiporting adalah sebuah program dalam
bahasa python yang ringan (light) dengan sedikit
aturan dalam menangani permintaan transaksi.
Program dijalankan dengan dibiakkan sejumlah
layanan yang secara otomatis membuka
beberapa port yang disediakan. Agar agen web
server mengenali port tsb, maka dipasang
sebuah port balancer yang berfungsi mirip
multiplexer, dimana port in adalah sebuah pintu
masuk dan port out adalah sejumlah layanan
yang telah dibiak-kan (multiport) untuk
menangani pendelegasian tugas secara pararel.
Masing-masing layanan telah terkoneksi
ke database transaksi lewat sebuah agen
transaksi berupa program/fungsi pl/sql dalam
database, sehingga untuk update maupun insert
data, maka agen web service tidak melakukan
sintak pl/sql dari database, melainkan hanya
memanggil fungsi tsb dengan parameter dari
pattern yang telah disepakati
6.3. Database Transaksi
Database transaksi adalah sebuah
program pl/sql yang ditanam dalam database
dimana dalam penelitian ini dipakai adalah
lingkungan database oracle. Dua jenis transaksi
yang selama ini sering dilakukan pada transaksi
online adalah
1. permintaan data
2. update data
7. Ujicoba
Pelaksanaan uji coba ini adalah untuk
mengetahui keberhasilan jalannya program mulai
dari input data sampai output data. Ujicoba
dilakukan dalam dua kelompok yaitu ujicoba
labolatorium dan ujicoba lapangan (live)
7.1. Ujicoba Labolatorium
Uji coba pertama dari arsitektur sistem adalah
dengan melakukan konfigurasi jumlah server.
7.1.1 Ujicoba satu server
Konfigurasi Hardware adalah Server
Xeon, dengan memori 4 G , sedangkan client
sejumlah 7 komputer PC yang melakukan
request masing-masing sebanyak 50.000. Port
yang dibuka adalah 10 buah per masing-masing
server. Hasil ujicoba terlihat pada gambar 7.1
dan gambar 7.2.
 Seminar Nasional Pascasarjana IX ITS, Surabaya 12 Agustus 2009
ISBN No.

51,71/10 = 5,171 request. Pada waktu tersebut

berarti port yang ter-reset sejumlah 9 port secara
bersamaan dan hanya ada 1 port saja yang
masih terbuka.
Pada tabel 7.1, dapat disimpulkan bahwa terjadi
reset koneksi secara bersamaan, jika jumlah
request <= 5 (rata-rata kemampuan satu port).
Dari 1664 data uji terdapat satu kali reset,
Gambar 7.1 Grafik hasil ujicoba satu server pukul sehingga peluang terjadinya reset koneksi
00.20-00.34 bersamaan sebesar 1/1664 = 0,000600962.

Analisa uji statistik

Hipotesis awal dan Alternatif dapat diringkas
sebagai berikut ini:
H0 : = 177 tps
H1 : < 177 tps
Menguji hipotesis dengan uji t, memasukkan
parameter H0 dengan = 177 dan level
keyakinan 0.95.
Gambar 7.2. Grafik hasil ujicoba satu server pukul Kesimpulan dari uji t ini menunjukkan bahwa H0
00.34-00.48 ditolak karena p-value < nilai alpha, sehingga H1
diterima, artinya bahwa tps dari arsitektur sistem
Semua catatan log diambil sampel untuk ini tidak sama dengan 177, namun lebih kurang
dianalisa, sampel tersebut diambil antara range dari dari 177 tps. Perhitungan dengan sampel
waktu 00:20 sampai 00:48, kemudian diatas, tingkat kepercayaan 95%, nilai tengah tps
dikelompokkan per-detik. Hasil pengelompokan adalah 51,72.
tersebut diperlihatkan pada gambar 7.3.
7.1.2. Ujicoba dua server
Detil konfigurasi tetap seperti konfigurasi
jumlah_request
100 satu server, dan server dibagi tugas antara
80
penanganan agen-agen dan penanganan
60
40 database. Hasilnya pada gambar 7.4 dan 7.5.
20
0
0:21:14
0:22:34
0:23:53
0:25:12
0:26:31
0:27:50
0:29:09
0:30:28
0:31:47
0:33:06
0:34:26
0:35:45
0:37:04
0:38:23
0:39:42
0:41:01
0:42:20
0:43:39
0:44:58
0:46:17
0:47:36
0:48:55

Gambar 7.3. Grafik tps satu server

Sisi koordinat y adalah jumlah transaksi

dan sisi koordinat x adalah waktu ujicoba sampai
seluruh transaksi diselesaikan.
Hasil sampel pada gambar 7.3
menunjukkan adanya titik maksimum dan titik Gambar 7.4 Grafik hasil ujicoba dua server pukul 23:22-
minimum dari jumlah request yang ditangani. Titik 23:36
maksimum merupakan angka tertinggi yang
mampu dilayani oleh sistem, sedangkan titik
minimum diakibatkan adanya mekanisme reset
koneksi database oracle untuk membebaskan
memori buffer agar dapat dipakai lagi, dari
masing-masing 10 port yang terbuka, sistem
secara random akan me-reset koneksi. Dengan
demikian sistem diharapkan tidak reset secara
bersamaan. Gambar 7.5 Grafik hasil ujicoba dua server pukul 23:37-
23:51.
Catatan reset terendah dari sampel adalah Hasil pengelompokan tersebut diperlihatkan pada
sebagai berikut ini : gambar 7.6.

Tabel 7.1 Satu server dengan jumlah request <=5

jumlah_request
400
waktu jumlah_request 300
200
0:21:24 5 100
0
23:37:00

23:37:50

23:38:40

23:39:30

23:40:20

23:41:10

23:42:00

23:42:54

23:43:46

23:44:36

23:45:30

23:46:20

23:47:10

23:48:00

23:48:52

23:49:46

23:50:38

23:51:28

Tabel 7.1. menunjukkan jumlah request yang

paling rendah, dibandingkan dengan rata-rata
jumlah request sekitar 51,72. Hal itu berarti
kemampuan 10 port secara rata-rata menangani Gambar 7.6. Grafik tps dua server
 Seminar Nasional Pascasarjana IX ITS, Surabaya 12 Agustus 2009
ISBN No.

Hasil sampel pada gambar 7.6, dibandingkan

dengan grafik satu server di gambar 7.3,
menunjukkan titik maksimum yang lebih tinggi,
namun terdapat titik titik minimum yang lebih
banyak dibandingkan dengan konfigurasi satu
server
Gambar 7.7.. Grafik hasil ujicoba tiga server pukul
01:13-01:27
Analisa uji statistik
Hipotesis awal dan Alternatif dapat diringkas
sebagai berikut ini:
H0 : = 177 tps
H1 : > 177 tps
Kesimpulan dari uji t ini menunjukkan
bahwa H0 ditolak karena p-value < nilai alpha,
sehingga H1 diterima, artinya bahwa tps dari
arsitektur sistem ini tidak sama dengan 177,
namun lebih tinggidari dari 177 tps. Perhitungan
dengan sampel diatas, tingkat kepercayaan 95%,
nilai tengah tps adalah 251,98 Gambar 7.8. Grafik hasil ujicoba tiga server pukul
01:27-01:41
Catatan reset terendah dari sampel
adalah sebagai berikut ini : Sampel tersebut diambil antara range
waktu 23:22 sampai 23:51, kemudian
Tabel 7.2 Dua server dengan jumlah request 25 dikelompokkan per-detik. Hasil pengelompokan
tersebut diperlihatkan pada gambar 7.9.
waktu jumlah_request
23:49:50 1
23:51:51 1
23:50:05 2
23:47:15 3
23:50:07 4
23:40:54 6
23:50:32 8
Gambar 7.10. Grafik tps tiga server
23:43:59 9
Tabel 7.2. menunjukkan jumlah request Hasil sampel pada gambar 7.10, dibandingkan
yang paling rendah, dibandingkan dengan rata- dengan grafik satu server di gambar 7.3,
rata jumlah request sekitar 251,98. Hal itu berarti menunjukkan titik maksimum yang lebih tinggi,
kemampuan 10 port secara rata-rata menangani namun terdapat titik titik minimum yang lebih
251,98/10 = 25,19 request. Pada saat waktu banyak dibandingkan dengan konfigurasi satu
tersebut berarti port yang ter-reset sejumlah 9 server.
port secara bersamaan dan hanya ada 1 port Analisa uji statistik
saja yang masih terbuka.
Pada tabel 5.2, dapat disimpulkan Hipotesis awal dan Alternatif dapat diringkas
bahwa terjadi reset koneksi secara bersamaan sebagai berikut ini:
,jika jumlah request <= 25 (rata-rata kemampuan H0 : = 177 tps
satu port). Dari 881 data uji terdapat 8 kali reset , H1 : > 177 tps)
sehingga peluang terjadinya reset koneksi
bersamaan sebesar 8/881 = 0,00908059. Kesimpulan dari uji t ini menunjukkan bahwa H0
Pada dua server kemampuan port ditolak karena p-value < nilai alpha, sehingga H1
meningkat menjadi 25,19 dan peluang reset diterima, artinya bahwa tps dari arsitektur sistem
koneksi secara bersamaan juga semakin ini tidak sama dengan 177, namun lebih tinggidari
membesar (0,00908059), dibandingkan dengan dari 177 tps. Perhitungan dengan sampel diatas,
satu server yang kemampuan port hanya 5,171, tingkat kepercayaan 95%, nilai tengah tps adalah
namun peluang terjadinya reset (0,000600962) 259,59
lebih rendah dibanding dua server.

7.1.3. Ujicoba tiga server

Detil konfigurasi tetap seperti konfigurasi satu
server, dan server dibagi tugas antara
penanganan agen-agen dan penanganan
database, hasilnya pada gambar 7.7 dan 7.8
 Seminar Nasional Pascasarjana IX ITS, Surabaya 12 Agustus 2009
Catatan reset terendah dari sampel adalah
sebagai berikut ini :
Tabel 7.3 Tiga server dengan jumlah request 12
waktu jumlah_request
1:21:06 2 rata-rata
1:21:08 3
1:38:33 4
1:29:38 6
1:32:48 7
1:32:42 9 7.2. Ujicoba Lapangan
1:35:56 11
1:16:24 12
1:20:09 12
Tabel 7.3. menunjukkan jumlah request
yang paling rendah, dibandingkan dengan rata-
rata jumlah request sekitar 259,59. Hal itu berarti
kemampuan 20 port secara rata-rata menangani
259,59/20 = 12,97 request. Pada saat waktu
tersebut berarti port yang ter-reset sejumlah 9
port secara bersamaan dan hanya ada 1 port
saja yang masih terbuka.
Pada tabel 7.3, dapat disimpulkan
bahwa terjadi reset koneksi secara bersamaan,
jika jumlah request <= 25 (rata-rata kemampuan
satu port). Dari 1606 data uji terdapat 9 kali reset
, sehingga peluang terjadinya reset koneksi
sebesar 9/1606 = 0,005603985.
Pada tiga server port yang dibuka lebih
banyak 2 kali lipat sebesar 20, sedangkan jumlah
request yang diberikan tetap, sebesar 7x50.000
= 350.000, sehingga rata-rata penanganan
request yang masuk terbagi ke 20 port menjadi
12,97. Namun peluang terjadinya reset secara
bersamaan mengalami penurunan. Penurunan
peluang terjadinya reset secara bersamaan pada
tiga server adalah (0,005603985-0,00908059)/
0,00908059= -0,38286113, atau sebesar 38,28%
dari peluang terjadinya reset secara bersamaan
dengan dua server.
Kesimpulan dari ujicoba labolatorium
terhadap jumlah server dapat diringkas pada
tabel 5.4
Tabel 7.4 Ringkasan ujicoba jumlah server
Jumlah Server tps peluang reset
1 51,72 0,00060096
2 251,98 0,00908059
3 259,59 0,00560398
Dari tabel 7.4, menunjukkan bahwa
implementasi arsitektur sistem ini dapat dipilih
sesuai dengan tps yang di-inginkan. Pada
penelitian sebelumnya, didapatkan jumlah tps
adalah 177 (Van der Mei ,R.D.; W.K. Ehrlich; P.K.
Reeser; J.P. Francisco, 2000). Nilai 177 dapat
dilampaui oleh sistem dengan arsitektur ini saat
jumlah server berjumlah 2 atau 3
Penurunan peluang terjadinya reset
secara bersamaan pada tiga server sebesar
38,28% dari dua server, menunjukkan sistem
yang aman untuk arsitektur ini adalah tiga server.
Ketika terjadi request yang cukup banyak pada
satu saat, maka peluang ditolak oleh server
ISBN No.
karena penutupan port secara bersamaan, pada
tiga server lebih rendah dibandingkan dengan
dua server, seperti diperlihatkan pada tabel 7.5.
Tabel 7.5 Rata-rata request per Port
Jumlah Server port request
1 10 5,171
2 10 25,19
3 20 12,97
Setelah dilakukan ujicoba laboratorium,
maka sistem di uji di lapangan untuk mengetahui
respon yang sesungguhnya. Ujicoba secara live
ini melibatkan pihak eksternal sebanyak 9
switcher yang merupakan perusahaan ataupun
perbankan penyedia pembayaran realtime. Detil
konfigurasi ujicoba lapangan mengacu pada hasil
ujicoba labolatorium yaitu server sebanyak tiga
buah :
Server 1: Agen Web server digabung
dengan Agen multiporting dengan 10
buah port yang terbuka.
Server 2: Agen multiporting dengan 10
buah port yang terbuka.
Server 3: Database dengan 1 listener.
Total port yang dibuka pada agen
multiporting sebanyak 2 server atau 20 port yang
tersedia untuk melayani pengelolaan proses
bisnis. Jumlah client yang terhubung sejumlah 9
switcher (penyedia jasa pembayaran on-line yang
memiliki komputer-komputer downline di loket-
loket pembayaran). Data-data transaksi dari
pencatatan log di server sejak mulai request
sampai close koneksi, terbagi menjadi data
bulanan, harian, jam, menit. Hasil log tersebut
diambil dan di analisa untuk mencari kemampuan
sistem, titik tertinggi tps permasing-masing
transaksi
1. Hasil uji lapangan secara bulanan
Log yang dicatat oleh sistem dikelompokkan
berdasarkan periode bulanan. Log menunjukkan
jumlah request yang di respon oleh sistem
ditunjukkan pada tabel 7.6.
Tabel 7.6: Jumlah request bulanan.
Bulan Jumlah Request
200901 8.519.970
200902 10.551.884
200903 17.303.344
200904 25.362.884
200905 24.187.845
200906 24.563.121
200907 20.186.882
Hasil uji lapangan perbulan menunjukkan
bahwa sistem mampu menangani request
tertinggi bulan april-2009 (30 hari * 24 jam * 60
menit * 60 detik = 2.592.000 detik, rata-rata
tps=25.362.884/2.592.000=9,79 tps)
Angka 9,79 tps adalah angka rata-rata
dengan asumsi setiap detik terjadi transaksi 24
jam tanpa henti. Secara kumulatif, total transaksi
januari 2009 sampai bulan juli 2009 sebesar
130.675.930 dan tps rata-rata dicapai
 Seminar Nasional Pascasarjana IX ITS, Surabaya 12 Agustus 2009
130.675.930/(2.592.000*7) = 7,2 tps. (asumsi
setiap detik ada transaksi). Dari jangka waktu
selama uji lapangan selama 7 bulan, maka dapat
disimpulkan bahwa sistem telah teruji bekerja
online tanpa henti, hasil ini diperoleh tanpa harus
mengubah arsitektur ataupun menambah
perangkat keras tambahan.
2. Hasil uji lapangan secara harian
Log yang dicatat oleh sistem di kelompokkan
berdasarkan periode harian. Log pencatatan
transaksi dianalisa dan didapatkan kelompok
harian dengan transaksi tertinggi mencapai
2.325.145 terjadi pada tanggal 20-04-2009. Log
tersebut digambarkan pada grafik harian yang
ditunjukkan pada gambar 7.11.
Gambar 7.11 Grafik jumlah request harian
Hasil uji lapangan harian menunjukkan
bahwa sistem mampu menangani request dalam
periode hari sejumlah 2.325.145. Perhitungan
dari tps pada hari itu dengan mengasumsikan
setiap detik terjadi transaksi tanpa henti,
2.325.145 / 24*60*60=26,91 tps. Nilai tps harian
ini mengindikasikan bahwa sebaran angka pada
hasil uji lapangan secara bulanan sebesar 7,2 tps
(lihat perhitungan hasil uji lapangan secara
bulanan dibahasan sebelumnya), pada tanggal
20-04-2009 melonjak naik menjadi 26,91 tps. Hal
ini dikarenakan sebaran waktu transaksi yang
tidak merata. Pada tanggal-tanggal tertentu atau
tanggal awal atapun akhir periode pembayaran,
maka transaksi cenderung meningkat
dibandingkan transaksi pada hari-hari biasa..
3. Hasil uji lapangan secara per jam
Setelah di ketahui bahwa sistem mampu
menangani respon harian tertinggi mencapai
2.325.145, maka di detilkan kedalam periode
jam. Log catatan dianalisa sampai ditemukan
jumlah request tertinggi adalah 325.706 perjam
transaksi, terjadi pada jam 8 pagi tanggal 11-07-
2009.
ISBN No.
Gambar 7.12 Grafik jumlah request per-jam
Hasil uji lapangan per jam menunjukkan
bahwa sistem mampu menangani request dalam
periode jam sejumlah 325.706. Perhitungan dari
tps pada jam itu dengan mengasumsikan setiap
detik terjadi transaksi tanpa henti, 325.706 /
60*60=90,47 tps. Nilai tps per jam ini
mengindikasikan bahwa sebaran angka pada
hasil uji lapangan secara harian bulanan sebesar
26,91 tps, pada tanggal 11-07-2009 melonjak
naik menjadi 90,47 tps. Hal ini dikarenakan
sebaran waktu transaksi yang tidak merata. Pada
malam hari transaksi cenderung berkurang
dibandingkan di siang hari..
4. Hasil uji lapangan secara per menit
Setelah di ketahui bahwa sistem mampu
menangani respon per jam tertinggi mencapai
325.706, maka data tersebut dicari dan didetilkan
kedalam periode menit untuk mengetahui tps
sebagai tujuan utama dari penelitian ini. Setelah
dilakukan pengolahan dan analisa terhadap log
data, maka didapatkan request tertinggi 12.158
terjadi pada menit 40 jam 02 tanggal 24-01-2009.
Gambar 7.13 Grafik jumlah request per-menit
Perhitungan tps tertinggi yang ditunjukkan
pada grafik 5.18 adalah 12.158/60=202,63 tps.
Nilai tps inilah yang menjadi tujuan dari penelitian
ini. Perhitungan dari tps pada menit itu dengan
mengasumsikan setiap detik terjadi transaksi
tanpa henti. Nilai tps per menit ini
mengindikasikan bahwa sistem mampu
melakukan transaksi sampai sebesar 202,63 tps.
Detil hasil ujicoba dilihat pada halaman lampiran
hasil ujicoba.
Kesimpulan uji coba lapangan (live) pada
arsitektur sistem ini, antara lain
1. Sistem mampu berjalan secara nonstop
(tanpa henti), hal ini terlihat selama 7
bulan uji lapangan, sistem tidak pernah
mati (down).

2. Terdapat nilai tps yang dihitung
berdasarkan kelompok periode bulan,
hari, jam dan menit yang menunjukkan
adanya waktu transaksi yang sibuk dan
ada waktu yang senggang. Daftar tps
secara periode ditunjukkan tabel 5.7.
Tabel 7.7: Daftar tps per periode.
Periode tps
Bulanan
Harian
Jam
Menit 202,63
3. Sistem mampu melakukan transaksi
tertinggi sejumlah 202,63 tps. Angka
202,63 didapat pada uji lapangan yang
dilakukan pengamatan selama 7 bulan
transaksi.
9. Kesimpulan
Dari ujicoba, maka dapat disimpulkan :
1. Konfigurasi server antara satu server,
dua server dan tiga server,
menunjukkan bahwa beban server yang
terbagi antara agen web server, agen
multiporting dan database transaksi.
2. Pada uji labolatorium, konfigurasi tiga
server adalah ideal karena jumlah tps
sebesar 259,59 dan peluang reset
koneksi secara bersamaan sebesar
0,005603985, nilai tsb lebih rendah
dibandingkan dengan konfigurasi dua
server.
3. Sistem mampu berjalan secara nonstop
(tanpa henti), hal ini terlihat selama 7
bulan uji lapangan, sistem tidak pernah
mati (down).
4. Pada uji lapangan, terdapat nilai tps
yang dihitung berdasarkan kelompok
periode bulan, hari, jam dan menit yang
menunjukkan adanya waktu transaksi
yang sibuk dan ada waktu yang
senggang.
5. Sistem mampu melakukan transaksi
tertinggi sejumlah 202,63 tps. Angka
202,63 didapat pada uji lapangan yang
dilakukan pengamatan selama 7 bulan
transaksi.
Dari kesimpulan diatas, maka tujuan dari
penelitian ini dapat dinyatakan tercapai dan
arsitektur sistem dapat diterima, sebab arsitektur
sistem memiliki tps yang lebih tinggi dari
penelitan sebelumnya. Penelitian sebelumnya tps
sebesar 177 (Van der Mei ,R.D.; W.K. Ehrlich;
P.K. Reeser; J.P. Francisco, 2000). Dari uji
labolatorium tps sistem ini sebesar 259,59 dan
dari uji lapangan angka tps tertinggi sebesar
202,63.
Dari uji lapangan memperlihatkan sistem
secara stabil mampu menangani jumlah request
yang ditunjukkan pada grafik bulanan, harian,
perjam dan permenit
Seminar Nasional Pascasarjana IX ITS, Surabaya 12 Agustus 2009
ISBN No.
Daftar Pustaka
1. Allan Tony,(2001), Performance
measurement for ntier Web Applications,
CMGA 2001 Seminar
2. Arlitt Martin; Carey Williamson ,(2004), An
Analysis of TCP Reset Behaviour on the
Internet. Department of Computer Science
University of Calgary.
7,2 3. Bellamy William Jr,(2002)., TCP Port 80 -
26,91 HyperText Transfer Protocol (HTTP) Header
90,47
Exploitation,
4. Caglayan A., Colin Harrison, Alper Caglayan,
and Colin G. Harrison, (1997 ),Agent
Sourcebook: A Complete Guide to Desktop,
Internet, and Intranet Agents, John Wiley &
Sons Inc., January 1997.
5. Guralnik David B.,(1983), Webster'sNew
World Dictionary, Prentice Hall School
Group.
6. Highmark, Inc,(2008), Real-Time Inquiry
Connectivity Specifications,
7. Holmes Victor P.; Wilbur R. Johnson, David
J. Miller,(2008), Integrating Web Service and
Grid Enabling Technologies to Provide
Desktop Access to High-Performance
Cluster-Based Components for Large-Scale
Data Services., Sandia National Laboratories
P.O. Box 5800, Albuquerque, NM 87185
USA
8. Lu Jijun ; Swapna S. Gokhale, (2005), Web
Server Performance Analysis, Department of
Computer Science and
Engineering,University of Connecticut,
Storrs, CT 06269, USA.
9. Olshefski D.; J. Nieh ; D. Agrawal,,(2004),.
Using Certes to Infer Client Response Time
at the Web Server, ACM TOCS, 22(1):49
93, February 2004.
10. Spero Simon E, (tgl akses 5/5/2009),
Analysis of HTTP Performance problems ,
http://www.ibiblio.org/mdma-release/http-
prob.html
11. Tsai, W.T. Fan, Chun. Chen, Yinong. Paul,
Raymond. Chung, Jen-Yao.,(2006)
Architecture classification for SOA-based
applications. Paper presented at the
Objectand Component-Oriented Real-Time
Distributed Computing,. ISORC 2006.Ninth
IEEE International Symposium. Arizona
State Univ., Tempe, AZ, USA.2006
12. Watson T.J.; Jason Nieh,(2007),
Understanding the Management of Client
Perceived Response Time, Research Center
19 Skyline Drive Hawthorne, NY 10532
13. Van der Mei ,R.D.; W.K. Ehrlich; P.K.
Reeser; J.P. Francisco, (2000), A Decision
Support System for Tuning Web Servers in
Distributed Object Oriented Network
Architectures