Analisis Web Performance dan Load Test Studi Kasus: Topologi Cloud Microsoft Azure Test Rig pada I-banking Bank XYZ

Analisis Web Performance dan Load Test Studi Kasus: Topologi Cloud Microsoft Azure Test Rig pada I-banking Bank XYZ

Guntoro 1 , Dana Sulistyo Kusumo, Ph.D 2 , Dr. Adiwijaya 3

1103104185,02780291-1,00740196-1

1,2,3 Teknik Informatika, Telkom School of Computing, Universitas Telkom, Bandung, Indonesia

Abstrak – Dewasa ini peran Internet Banking

diakses dari mana saja baik itu dari HP, komputer,

memegang peranan penting dalam suatu perbankan.

PDA dan sebagainya.

Bank XYZ adalah salah satu Bank yang sedang

Pada awal tahun 2014 ini Bank XYZ baru saja

berkembang proses bisnisnya, begitu juga dengan

selesai membangun sistem I-banking versi

segi teknologi yang digunakannya. Dalam upaya

terbarunya. Maka dari itu sebelum digunakan oleh

pencapaian tujuan Bank XYZ menjadi lebih baik,

nasabah dan juga untuk mengetahui kapasitas

diperlukannya sistem I-banking untuk melayani

maksimum operasi I-banking Bank XYZ serta

semua kebutuhan dari nasabah. Sistem I-banking

adanya kemacetan (bottlenecks) yang

yang powerfull menjadi salah satu kunci untuk mendapat kepercayaan yang tinggi dari nasabah.

menyebabkan degradasi, diperlukannya untuk melakukan pengujian beban pada sistem I-banking.

Untuk mengetahui kapasitas maksimum operasi I-

Pengujian dilakukan dalam perangkat lunak

banking Bank XYZ serta adanya kemacetan

maupun perangkat keras (server) dengan cara

(bottlenecks) yang menyebabkan degradasi,

melakukan stress test pada sistem I-banking. Proses

sangatlah diperlukan untuk melakukan pengujian

pengujian harus melalui Cloud atau melalui jaringan

beban pada sistem I-banking. Maka dari itu

Internet karena untuk dapat mensimulasikan

diperlukannya pembangunan Test Rig dalam Cloud

seolah-olah user asli saat

Microsoft Azure untuk melakukan Web Performance

membuka web I-banking tersebut. Hal ini berarti

dan Load Test pada I-banking Bank XYZ, dengan

dibutuhkannya Cloud Computing yang mana

skenario dan target user sesuai yang dibutuhkan.

memanfaatkan sumber daya teknologi komputer

Sehingga dapat

(komputasi) berbasis internet [1]. Dari data-data

mengidentifikasi faktor penyebab performansi dan

yang dihasilkan dapat dengan mudah untuk

skalabilitas bottleneks dari web I-banking tersebut.

menganalisis faktor-faktor mana sajakah yang

Kata Kunci: I-banking, Test Rig, Cloud Microsoft

mempengaruhi performansi sistem I-banking Bank

Azure, Web Performance, Load Test, Bottlenecks.

XYZ.

Hanya saja untuk mendukung proses pengujian di atas, dibutuhkannya infrastruktur yang sangat

I. PENDAHULUAN

komplek seperti mesin virtual dengan spesifikasi yang tinggi, bandwidth konektifitas dengan

Internet Banking, untuk selanjutnya di sebut I- jaringan yang besar, Test Agent, Test Controller banking merupakan suatu layanan perbankan yang dan lain-lain [2]. Maka dari itu diperlukannya melalui jaringan Internet dengan menggunakan layanan yang menyediakan infrastruktur di mana website milik Bank sebagai perantaranya. pengguna dapat membangun satu atau lebih mesin

virtual sesuai yang dibutuhkan. Semua komponen Penyelenggaraan I-banking merupakan penerapan di atas yang saling terkait dinamakan Test Rig. aplikasi teknologi informasi yang terus Saat melakukan proses pengujian, dibutuhkan

berkembang dan dimanfaatkan untuk menjawab juga sistem pemantau performansi Test Rig seperti keinginan nasabah perbankan yang menginginkan pelayanan cepat, aman, nyaman, murah dan dapat berkembang dan dimanfaatkan untuk menjawab juga sistem pemantau performansi Test Rig seperti keinginan nasabah perbankan yang menginginkan pelayanan cepat, aman, nyaman, murah dan dapat

2.3. Software Performance

konektifitas jaringan internet Test Rig berdasarkan Software Performance adalah kualitas dari

response time , throughput dan error rate nya. sistem perangkat lunak yang mana semuanya saling Sehingga ketika menghasilkan laporan pengujian mempengaruhi dari perangkat lunak itu sendiri akan mendapatkan nilai yang terbaik tanpa ada untuk semua lapisan dasar seperti sistem operasi, faktor masalah internal dari Test Rig.

middleware, perangkat keras, jaringan komunikasi, Semua layanan yang dibutuhkan untuk

dan lain-lain [6].

membangun Test Rig tersedia pada platform Microsoft Azure yang mendukung pemakaian

Topologi Cloud Microsoft Azure Test Rig. Oleh

2.4. Software Testing

karena itu berdasarkan permasalahan di atas, akan Software Testing adalah proses mengeksekusi

lebih mudah dan cepat jika pembangunan Test Rig sistem perangkat lunak untuk menentukan apakah dilakukan pada platform Microsoft Azure untuk itu cocok spesifikasinya dan mengeksekusi ke melakukan proses pengujian pada sistem I-banking dalam lingkup sistem yang ditargetkan [7]. Bank XYZ.

2.5. Software Performance Testing

Software Performance Testing adalah suatu

II. TINJAUAN PUSTAKA

proses pengujian untuk mengukur kinerja perangkat lunak. Tes kinerja ini meliputi berbagai

macam pengujian, masing-masing memiliki tujuan Cloud Computing merupakan tren teknologi dan metode pengawasan.

2.1. Cloud Computing

terbaru yang mempunyai tujuan untuk memenuhi

tuntutan sumber daya informasi teknologi dengan

2.5.1. Web Performance Test

pemanfaatan teknologi komputer (komputasi) Web Performance Test adalah serangkaian berbasis Internet [3].

proses pengujian untuk mengukur kemampuan dari suatu website. Dalam Rekaya Perangkat lunak,

Performance Testing adalah suatu pengujian yang dilakukan untuk menentukan bagaimana sistem melakukan respon dan stabilitas di bawah beban kerja tertentu (degradasi kinerja), sehingga dengan melakukan pengujian akan dihasilkan data yang dapat di pakai untuk menyelidiki, mengukur, memvalidasi atau memverifikasi dari atribut kualitas sistem tersebut [8] [9].

Dengan Web Performance Test dapat dengan

mudah membangun sebuah kerangka kerja tes untuk

Gambar 2-1 Arsitektur Cloud Computing [3]

dilakukan secara berulang yang dapat membantu

dalam menganalisis kinerja aplikasi website dan

mengidentifikasi hambatan potensial. Microsoft Azure adalah sebuah platform yang

2.2. Microsoft Azure

menyediakan komputasi awan dan infrastruktur

2.5.2. Load Test

yang dibuat oleh Microsoft untuk membangun, Load Test adalah bentuk sederhana dari

menempatkan dan mengelola aplikasi dan layanan Performance Testing , sebuah uji beban yang melalui jaringan global pusat data yang dikelola dilakukan untuk memahami perilaku sistem di Microsoft dan mendukung kebutuhan layanan bawah beban yang diharapakan secara spesifik [8]. khusus dari pengembangan Tim, pelanggan dan

Pengujian ini akan memberikan sebuah respon pengguna [4].

dan data dari semua traksaksi yang dilakukan sesuai skenario, sehingga dapat dengan mudah mencari dan data dari semua traksaksi yang dilakukan sesuai skenario, sehingga dapat dengan mudah mencari

III. PERANCANGAN SISTEM PENGUJIAN performansi dari suatu sistem yang telah diuji. Load Testing ini biasa digunakan bersamaan

3.1. Gambaran Umum Sistem

dengan Web Performance Test untuk melakukan Gambaran umum sistem dengan menggunakan

kombinasi pengujian, beban, pengujian stress Topologi Cloud Microsoft Azure Test Rig untuk aplikai website.

melakukan Web Performance dan Load Test pada Web Server I-banking Bank XYZ sebagai berikut:

2.6. Test Agent dan Controller

Saat menjalankan pengujian jarak jauh (remote) pada beberapa mesin virtual, atau untuk

Loca l Ma chine

mengumpulkan data dan mendiagnosa hasil dari pengujian jarak jauh diperlukannya Test Agent dan

Test Controller. Test Controller berjalan sebagai

sebuah layanan dan memberikan tugas kepada Test

Tea m Founda tion Server Online

Agent untuk menjalankannya (skenario pengujian).

Sedangkan Test Agent yang melakukan pengujian, mengumpulkan data hasil pengujian, dan

Test Agent

menyimpannya pada SQL di Test Controller [10].

– VM1 Test Agent – VM2 Test Agent – VM3 Test Agent – VM4

2.7. Topologi Cloud Microsoft Azure Test Rig

Load Ba lancer

Ketika membangun Test Rig pada Cloud Microsoft Azure , perlu digunakannya Topologi Test

Web Server 1 Rig, yang terdiri dari Test Agent dan Test I-banki ng XYZ Web Server 2 I-banki ng XYZ Web Server 3 I-banki ng XYZ Web Server 4 I-banki ng XYZ

Controller. Media komunikasi antara Test Agent dan Test Controller menggunakan Windows Azure

Gambar 3-1 Gambaran umum sistem ketika melakukan

Connect . Berikut gambaran Topologinya:

Testing

Pada gambar di atas terlihat ada 4 Virtual Machines yang digunakan dalam melakukan pengujian ini. Dengan tujuan agar web server yang digunakan oleh sistem I-banking akan berkerja/aktif semua. Sehingga mendapatkan hasil pengujian yang maksimal ketika melakukan stress test pada sistem I-banking Bank XYZ.

Selain itu komputer lokal digunakan untuk menjalankan semua konfigurasi seperti pembuatan

skenario pengujian, kustomisasi jumlah user, tipe

Gambar 2-2 Topologi Test Rig Menggunakan Cloud

load test , dan lain-lain. Test Controller berfungsi

Microsoft Azure [2]

untuk meneruskan permintaan dari pengguna pada

Test Agent untuk melakukan testing sesuai dengan

2.8. Team Foundation Server

skenario yang telah di buat dan menyimpan semua Team Foundation Server adalah produk server hasil dari pengujian ke dalam SQL. Test Agent dapat

terpisah yang dirancang khusus untuk tim rekayasa disebut sebagai end-point dari Test Rig, yang perangkat lunak seperti pengembang, penguji, berfungsi sebagai pembuat user virtual untuk arsitek, manajemen proyek, analis bisnis dan orang melakukan request pada sistem I-banking sesuai yang berkontribusi terhadapar rilis pengembangan skenario yang telah diatur. perangkat lunak/proyek [11].

3.2. Langkah Pengujian

b. Team Foundation Server Online Team Foundation Server Online digunakan

untuk dapat melakukan sharing file

Studi Literatur: Azure,

Sistem I-banki ng, dll pengujian pada setiap Virtual Machines.

c. Internet Explorer versi 9.0 Web browser yang digunakan adalah Internet

Ta wa p Awal

Melak ukan Pengecekan da n

Explorer versi 9.0. Internet Explorer

memverifika si sis tem

I-banki ng merupakan satu-satunya web browser yang mendukung untuk dapat melakukan record skenario pada web performance test dalam

Visual Studio, dengan versi yang paling

Setup Enviro nment

Proses

pada Azure Pemba ngunan

rendah adalah 9.0.

3.4. Skenario Pengujian

Membuat skena rio pengujia n dan

Pada penelitian ini skenario yang akan dipakai

mela kukan taha p Proses pengujia n pada s istem Pengujian

hanya proses Transaction History dan Balance

Inquiry karena pada skenario lainnya harus

I-banki ng

membutuhkan keamanan token I-banking untuk melakukan proses transaksi pengujian dan ada

Analisa dan

beberapa data yang bersifat privasi. Dalam web performance test terdapat skenario pengujian yang akan dilakukan, berisi langkah- langkah user ketika mengakses website I-banking

Pembua tan Lapora n Ta hap Akhir

Gambar 3-2 Diagram Blok Langkah Pengujian

Bank XYZ dan terekam ke dalam file .webtest pada Microsoft Visual Studio. Maka dari itu akan dibuat

Gambar 3-2 di atas adalah sebuah diagram blok

2 file .webtest (web performance testing) yang

yang menjelaskan langkah pengujian. Ada 4 berisi skenario Transaction History dan skenario tahapan/proses yang akan dilakukan di antaranya: Balance Inquiry . Pengujian (web performance test) Proses tahap awal (studi literature, checking), proses ini akan dilakukan jika record dari setiap skenario pembangunan (setup environment pada Azure), berhasil dilakukan. proses pengujian dan proses tahap akhir (Analisa dan pembuatan laporan).

Setelah selesai melakukan web performance test selanjutnya adalah tahap pengujian (load testing).

Dalam tahap ini ada beberapa parameter pengujian Dalam melakukan pengujian pada sistem I- yang akan dimasukan ke dalam test case (seperti banking Bank XYZ ini dilakukan yang sudah dijelaskan pada bagian Bab menggunakan beberapa tools di antaranya:

3.3. Testing Tools

3.2.3), diantaranya:

 Penggunaan Think Time selama 10 seconds.

a. Microsoft Visual Studio 2013 Ultimate Think Time adalah waktu penundaan antara Microsoft Visual Studio 2013 versi Ultimate

setiap permintaan (request). Hal ini merupakan merupakan sebuah perangkat lunak (tools)

yang dapat yang dapat digunakan untuk melakukan Web

mensimulasikan kebiasaan user asli ketika Performance dan Load Test. Versi ultimate

membuka web I-banking Bank XYZ. adalah satu-satunya versi produk Visual

 Pada tahap Load Pattern menggunakan tipe Studio yang mendukung untuk melakukan

constant load atau concurrent user sebanyak Web Performance dan Load Test.

1000 user pada setiap Virtual Machines. Sehingga total request 4000 user dalam melakukan pengujian ini. Dengan 1000 user pada setiap Virtual Machines. Sehingga total request 4000 user dalam melakukan pengujian ini. Dengan

IV. EKSEKUSI PENGUJIAN DAN ANALISIS membuat beban server menjadi berat, sehingga

HASIL

akan mudah terlihat bottlenecks yang terdapat pada sistem I-banking Bank XYZ.

4.1. Eksekusi Pengujian

 Test Record yang digunakan adalah file Hal yang perlu diperhatikan sebelum TransactionHistory .webtest

dan melakukan pengujian adalah penempatan Virtual BalanceInquiry .webtest yang sebelumnya di

Machines pada Microsoft Azure harus yang buat ketika melakukan web performance test.

terdekat dengan web server pada sistem I-banking

 Penggunaan Internet dalam melakukan load Bank XYZ, sehingga konektifitas jaringan internet

tidak akan mempengaruhi hasil dari pengujian yang testing ini menggunakan konektifitas dari akan dilakukan. Pemilihan lokasi cloud server yang Virtual Machines (LAN) yang terhubung terdekat adalah pada zona Regional South East Asia

dengan jaringan Internet pada Microsoft Azure - Singapore. ketika melakukan pengujian pada sistem I-

Sebelum melakukan pengujian dilakukan banking Bank XYZ.

warming up terlebih dahulu dengan cara melakukan

 Web browser yang digunakan dalam pengujian load testing pada sistem I-banking Bank XYZ

ini menggunakan Internet Explorer versi 9.0 selama 30 menit. Hal tersebut untuk memastikan yang merupakan satu-satunya web browser semua Virtual Machines dapat terhubung dengan yang mendukung untuk dapat melakukan baik pada sistem I-banking dalam melakukan record skenario pada web performance test pengujian ini. dalam Visual Studio, dengan versi yang paling

rendah adalah 9.0.

4.2. Web Performance Testing

Web Performance Test dilakukan untuk

mengetahui seberapa responsif sistem I-banking Dalam melakukan pengujian pada sistem I- Bank XYZ dan memastikan tidak ada kesalahan

3.5. Rencana Eksekusi Pengujian

banking akan dilakukan setelah jam kerja Bank (errors) dalam skenario pengujian. XYZ selesai yaitu pukul 16:00 WIB yang mana

Pada pengujian ini dilakukan dengan cara

sistem I-banking tidak dipakai oleh karyawan Bank menjalankan file TransactionHistory.webtest dan XYZ. Sehingga penggunaan resource sistem I- BalanceInquiry .webtest pada Microsoft Visual banking akan maksimal difokuskan untuk Studio dan selajutnya menganalisa hasil datanya. pengujian ini.

Berikut hasil rata-rata nilai Response Time dari Pengujian (Load Test) pada kasus Transaction

hasil Web Performance Test pada skenario

History akan dilakukan sebanyak 40.000 kali Transaction History dan Balance Inquiry I-banking dengan maksimal 4000 user dan pada kasus Balance Bank XYZ, diantaranya: Inquiry akan dilakukan selama 20 menit dengan maksimal 4000 user juga. Dengan tujuan untuk

4.2.1. Transaction History

mengetahui apakah ada hasil pengujian yang sangat Dalam pengujian (web performance test) pada

berbeda antara batas penggunaan menggunakan skenario Transaction History ini dilakukan dengan waktu dan batas jumlah target transaksi pengujian.

3 kali percobaan, berikut hasil datanya:

dilakukannya warming up pada sistem I-banking Bank XYZ selama (minimal) 30 menit, untuk memastikan semua Virtual Machines dapat terhubung dengan baik pada sistem I-banking dalam melakukan pengujian ini.

adalah ketika proses login dengan nilai 19.7 detik

Table 4-1 Hasil Data Web Performance Test

dan rata-ratanya 16.0 detik. Berbeda dengan

(Transaction History)

skenario sebelumnya (Trasaction History) yang mana halam login tidak terlalu lama dibandingkan

Transaction History proses ketika membuka halama home. Akan tetapi

rata-ratanya waktunya tidak jauh berbeda dari kedua

Pages

proses ini. Proses logout merupakan proses yang

memiliki nilai waktu transaksi paling kecil juga

Home

20.6 24 21.9 dalam proses pengujian ini, karena hanya menghilangkan cookies pada web browser klien.

Login

IBTranscationHistory

6.1 18.8 11.5 4.3. Load Testing

1 11.5 6.1 Sebelum melakukan pengujian ini (load testing ) dilakukan warming up terlebih dahulu

Logout

dengan menggunakan skenario yang telah di buat selama 30 menit. Tujuannya adalah untuk

Pada hasil di atas, dapat disimpulkan proses memastikan semua sistem bekerja dengan baik dan eksekusi yang memiliki nilai waktu pengujian memastikan pengujian (load testing) siap paling tinggi skenario Transaction History adalah dijalankan. Pengujian ini dilakukan setelah jam ketika proses masuk pada halaman Home dengan kerja Bank XYZ selesai (di atas jam 16:00), nilai 24 detik dan rata-ratanya 21.9 detik. Hal ini sehingga penggunaan resource sistem I-banking dapat disebabkan karena ketika membuka halaman akan maksimal difokuskan untuk pengujian ini. depan terdapat berbagai macam tipe file seperti,

gambar, css, js dan lain-lain. Proses logout

4.3.1. Skenario Transaction History

merupakan proses yang memiliki nilai waktu Ada beberapa kategori hasil pengujian utama

transaksi paling kecil atau halaman yang paling yang akan didapatkan dari Visual Studio, di ringan dalam proses pengujian ini, karena hanya antaranya: (Test Result, Error Details, Request

Files dan Test Rig). Berikut ini hasil data yang menghilangkan cookies pada web browser klien. didapatkan ketika melakukan pengujian (load

4.2.2. Balance Inquiry

testing ) pada skenario Trasaction History:

Dalam pengujian (web performance test) pada

Test Run Information:

skenario Balance Inquiry ini dilakukan dengan 3 kali percobaan juga, berikut hasil datanya:

 Scenario : Transaction History  Think Time : 10 seconds

Table 4-2 Hasil Data Web Performance Test (Balance

 Load Test Type : Conccurent Load

Inquiry)

 Total Users : 4000 users (1000 users /

VM) Balance Inquiry  Duration : 10.000 request / VM (+- 55

 Start Time : 4:48:03 PM

Pada hasil di atas, dapat disimpulkan proses eksekusi yang memiliki nilai waktu pengujian paling tinggi dalam skenario Balance Inquiry

Timeout 965

1) Test Result

WebException 1

Hasil pengujian pada kategori Test Result dalam skenario Transaction History sebagai berikut:

No Information 1,244 Table 4-3 Hasil Data Load Testing (Transaction

History)

Table 4-6 Informasi Error Details pada VM 3 (Transaction History) VM 1 VM 2 VM 3 VM 4 Total Req 10,000 10,000 10,000 10,000

VM 3

Passed 4,105 3,975 2,406 2,387 Type Count

Errors 5,895 6,025 7,594 7,613 ExtractHiddenFields 1,000

SocketException 2) Error Details 1,000

ValidateResponseUrl 1,000 Hasil pengujian pada kategori Error Details dalam skenario Transaction History sebagai berikut:

WebTestException 1,000 Timeout 1,000

Table 4-4 Informasi Error Details pada VM 1 (Transaction History)

No Information 2,594

VM 1

Table 4-7 Informasi Error Details pada VM 4 Type Count (Transaction History)

Type Count ExtractHiddenFields 1,000

WebTestException 1,000 WebException 38 Timeout 1,000

No Information 917

WebException 1 No Information 2,612

Table 4-5 Informasi Error Details pada VM 2

(Transaction History)

Informasi detail ‘Type’:

VM 2

 ExtractHiddenFields: Redirect page Type Count http://110.35.82.210/PaninWeb/Core/system

ExtractHiddenFields 1,000

Unavailable.html  SocketException: Koneksi terputus di tengah

SocketException 815

pengujian (per Transaction)

 ValidateResponseURL: Hasil respon halaman

ValidateResponseUrl 1,000

selanjutnya tidak sesuai

WebTestException 1000

 WebTestException: Respon post parameter

data tidak ditemukan

 Timeout: Request Time Out

Core.DateExtensions.js

 WebException: Permintaan (request)

panin_logo.png

dibatalkan

ArrowRight.gif

Dari 4 tabel di atas, hasil data errors pada skenario

Trasaction History 228 ini pada setiap Virtual Machines hampir memiliki nilai errors yang sama,

blank.gif

ArrowLeft.gif

akan tetapi kesalahan itu berasal dari sistem I- banking Bank XYZ semua, bukan berasal dari Test

Error.gif

Rig. Hasil data error details yang dapat direkam

DESGetFiles.aspx

oleh Microsoft Visual Studio 2013 maksimal 1000 data.

Js

3) Request Files

jquery-ui.css

WebResource.axd

Hasil pengujian pada kategori Request Files dalam skenario Transaction History sebagai berikut:

TrueStampImageHandler.ashx

Table 4-8 Hasil Data Request Files saat Pengujian

24,000 108 (Transaction History)

LandingPage.aspx{GET}

Logout.aspx

Request (Files) Total Failed

40,000 76 IBTransactionHistory.aspx{POST} 120,000 48,284

IBTransactionHistory.aspx{GET}

SystemUnavailable.aspx

systemUnavailable.html

timeout.js

login.aspx{POST}

LandingPage.aspx{POST}

LandingPage.js

Login.aspx

coolite.js

ImageHandler.ashx

BasicDatePicker.js

ScriptResource.axd

588 date-id-ID.js

ajax-loader.gif

544 calendar.gif

paninStyleNew.css

CombineScripts.axd

Dari table di atas dapat di simpulkan, 5 request

CategorizationRules.css

files yang memiliki errors paling banyak pada skenario Transaction History (selain request pada

fg-menu.css

file “systemUnavailable.html”) disebabkan karena

PMMActivity.css

adanya trasaksi yang melibatkan banyak perangkat keras (sistem), seperti penggunaan database (post

Memorization.css

method ) ketika melakukan login atau mengambil data yang tersimpan dalam database.

global.css

Penggunaan file .css juga mempunyai banyak

login.aspx{GET}

errors hal ini dapat di sebabkan karena tidak melakukan pengkompresan file, biasanya di sebut

Calendar.gif

minify css atau disebabkan karena tidak melakukan teknik caching (cache computing). Teknik minify css atau disebabkan karena tidak melakukan teknik caching (cache computing). Teknik

“error details” sebelumnya (Table 4.4). Dari data

di atas terlihat error rates paling besar pada

4) Test Rig

skenario Transaction History adalah 76.13%. Error rates di sini adalah jumlah trasnaksi yang gagal

Hasil pengujian pada kategori Test Rig dalam selama pengujian berlangsung. Akan tetapi data skenario Transaction History sebagai berikut:

errors di atas, semuanya disebabkan oleh pihak sistem I-banking, yang mana telah dipaparkan pada

Table 4-9 Hasil Data Throughput Rate Setiap Detik

bagian hasil data “error details” sebelumnya.

(Transaction History)

Semakin kecil errors maka semakin baik.

Throughput Rate / Pages (Per Sec)

Table 4-12 Informasi Kapasitas Memori yang Tersedia

Saat Pengujian (Transaction History)

31 34 27 26 Average (Available Memory)

VM1

1.3GB

Hasil data Throughput Rate pada skenario

VM2

1.3GB

Transaction History paling kecil adalah 26

pages/sec . Throughput Rate di sini adalah

VM3

1.4GB

banyaknya pages yang terseksekusi ketika

VM4

1.5GB

melakukan pengujian dalam setiap detik. Semakin

besar Throughput maka semakin baik.

Ketika melakukan pengujian, penggunaan memory pada virtual machines akan semakin besar.

Table 4-10 Hasil Data Avg. Response Time Setiap

Ini disebabkan karena virtual machines dalam test

Halaman (Transaction History)

rig mencoba untuk membuat user-user virtual untuk Avg. Response Time (Sec) melakukan pengujian terhadap sistem I-banking. Data di atas merupakan rata-rata jumlah resource

VM1 VM2 VM3 VM4

memory yang tersisa ketika melakukan pengujian

4.43 4.29 6.59 6.67 pada skenario Trasaction History. Selama pengujian penggunaan resource memory pada setiap Virtual

Machines masih tersisa, berarti penggunaan

Hasil data pada table di atas terlihat bahwa response memory sebesar 7GB sudah layak untuk melakukan time setiap halaman pada skenario Transaction pengujian. History paling besar adalah 6.67 sec/pages.

Response Time di sini adalah selisih waktu antara

Table 4-13 Informasi Threshold Penggunaan Processor

permintaan request dengan respon yang di berikan > 75% (Transaction History) oleh server pada sistem I-banking. Semakin kecil

Threshold Processor

Response Time maka semakin baik.

VM 1 VM 2

Table 4-11 Hasil Data Error Rates dari Pengujian

(Transaction History)

Error Rates (%)

VM1

VM2

VM3

VM4

77.24 VM 3 VM 4 0:04:30

76.05 Ketika melakukan pengujian, sama halnya penggunaan processor pada virtual machines akan

88.23 semakin besar juga. Ini disebabkan karena virtual

82.61 machines dalam test rig mencoba untuk membuat user-user virtual untuk melakukan pengujian

77.05 terhadap sistem I-banking. Pada pengujian ini, terpasang peringatan (warning) yang akan di rekam

oleh test rig ketika penggunaan resource processor oleh test rig ketika penggunaan resource processor

Table 4-15 Informasi Error Details pada VM 1 (Balance

penggunaan resource processor ketika melebihi

Inquiry)

ambang batas 75% dalam melakukan pengujian

pada skenario Trasaction History. Selama pengujian VM 1 penggunaan resource processor pada setiap Virtual

Type Count

Machines tidak pernah mencapai nilai 100%, ExtractHiddenFields sehingga penggunaan 4 cores pada Virtual 1,000

Machines dalam Microsoft Azure sudah cukup

SocketException 1,000

untuk melakukan pengujian. ValidateResponseUrl 1,000

4.3.2. Skenario Balance Inquiry

WebTestException 1,000

Ada 5 kategori hasil pengujian utama yang

Timeout 325

akan didapatkan dari Visual Studio, di antaranya: (Test Result, Error Details, Request Files, Pages

WebException 5

dan Test Rig). Berikut ini hasil data yang

No Information 894

didapatkan ketika melakukan pengujian (load

testing ) pada skenario Balance Inquiry:

Test Run Information:

Table 4-16 Informasi Error Details pada VM 2 (Balance

Inquiry)

 Scenario : Balance Inquiry  Think Time : 10 seconds

VM 2

 Load Test Type : Conccurent Load Type Count  Total Users : 4000 users (1000 users /

VM)

ExtractHiddenFields 1,000

 Duration : 20 minutes SocketException  Start Time : 5:35:35 PM 834

ValidateResponseUrl 1,000

1) Test Result

WebTestException 1,000

Hasil pengujian pada kategori Test Result dalam

Timeout 292

skenario Balance Inquiry sebagai berikut: WebException 4

Table 4-14 Hasil Data Load Testing (Balance Inquiry) No Information 1,137

VM 1 VM 2 VM 3 VM 4

Total

5,642 5,966 5,041 5,803 Req Table 4-17 Informasi Error Details pada VM 3 (Balance

Errors 5,224 5,267 4,595 5,477 Type Count

ExtractHiddenFields 1,000

2) Error Details

SocketException 1,000

Hasil pengujian pada kategori Error Details dalam

ValidateResponseUrl 1,000

skenario Balance Inquiry sebagai berikut:

WebTestException 1,000 Timeout 423

WebException

4 Table 4-19 Hasil Data Request Files saat Pengujian

No Information

(Balance Inquiry)

Request (Files) Total Failed Table 4-18 Informasi Error Details pada VM 4 (Balance

8,389 Inquiry) 8,389

systemUnavailable.html

login.aspx{POST}

VM 4 LandingPage.aspx{POST}

Type Count Login.aspx

ExtractHiddenFields 1,000

ScriptResource.axd

SocketException 905

SystemUnavailable.aspx

ValidateResponseUrl 1,000

panin_logo.png

WebTestException 1,000

ajax-loader.gif

Timeout 465

CombineScripts.axd

WebException 14

No Information 116

Core.DateExtensions.js

Error.gif

Informasi detail 103 ‘Type’:

blank.gif

 ExtractHiddenFields: Redirect page 103 http://110.35.82.210/PaninWeb/Core/system

Calendar.gif

ArrowLeft.gif

Unavailable.html

 SocketException: Koneksi terputus di tengah 97 pengujian (per Transaction)

paninStyleNew.css

 ValidateResponseURL: Hasil respon halaman 91 selanjutnya tidak sesuai

ArrowRight.gif

fg-menu.css

 WebTestException: Respon post parameter

data tidak ditemukan 86  Timeout: Request Time Out

PMMActivity.css

 WebException: Permintaan (request) 84 dibatalkan

CategorizationRules.css

DESGetFiles.aspx

Memorization.css

Dari 4 tabel di atas, hasil data errors pada skenario 80 Balance Inquiry ini pada setiap Virtual Machines

hampir memiliki nilai errors yang sama, akan tetapi kesalahan itu berasal dari sistem I-banking Bank

WebResource.axd

XYZ semua, bukan berasal dari Test Rig. Hasil data

error details yang dapat direkam oleh Microsoft Visual Studio 2013 maksimal 1000 data.

global.css

AccountPortfolio.aspx

GetUnreadMessagesCount

3) Request Files 11

login.aspx{GET}

Hasil pengujian pada kategori Request Files dalam skenario Balance Inquiry sebagai berikut:

Logout.aspx

Table 4-21 Hasil Data Avg. Response Time Setiap

ImageHandler.ashx

2 Halaman (Balance Inquiry)

LandingPage.js

1 Avg. Response Time (Sec)

TrueStampImageHandler.ashx

1 VM1 VM2 VM3 VM4 errorNew.png

jquery-ui.css

Hasil data pada table di atas terlihat bahwa response

LandingPage.aspx{GET}

0 time setiap halaman pada skenario Balance Inquiry paling besar adalah 6.67 sec/pages. Response Time

di sini adalah selisih waktu antara permintaan

Dari table di atas dapat di simpulkan, 5 request files request dengan respon yang di berikan oleh server yang memiliki errors paling banyak pada skenario pada sistem I-banking. Semakin kecil Response Balance Inquiry ( selain request pada file Time maka semakin baik. “systemUnavailable.html”) disebabkan karena adanya trasaksi yang melibatkan banyak perangkat

Table 4-22 Hasil Data Error Rates dari Pengujian

keras (sistem), seperti penggunaan database (post

(Balance Inquiry)

method ) ketika melakukan login atau mengambil

Error Rates (%)

data yang tersimpan dalam database.

Penggunaan file .css juga mempunyai banyak errors hal ini dapat di sebabkan karena tidak melakukan

pengkompresan file, biasanya di sebut minify css

atau disebabkan karena tidak melakukan teknik caching (cache computing) . Teknik pengkompresan Hasil data error rates ini didapatkan dari table file dan caching juga berlaku pada file bergambar “error details” sebelumnya (Table 4.20). Dari data atau javascript.

di atas terlihat error rates paling besar pada skenario Balance Inquiry adalah 95.38%. Error

4) Test Rig

rates di sini adalah jumlah trasnaksi yang gagal selama pengujian berlangsung. Akan tetapi data

Hasil pengujian pada kategori Test Rig dalam errors di atas, semuanya disebabkan oleh pihak skenario Balance Inquiry sebagai berikut:

sistem I-banking, yang mana telah dipaparkan pada bagian hasil data

“error details” sebelumnya.

Table 4-20 Hasil Data Throughput Rate Setiap Detik

Semakin kecil errors maka semakin baik.

(Balance Inquiry)

Throughput Rate / Pages (Per Sec) Table 4-23 Informasi Kapasitas Memori yang Tersedia

Saat Pengujian (Balance Inquiry)

29 31 30 26 Avarage (Available Memory)

VM1

1.4GB

Hasil data Throughput Rate pada skenario Balance

VM2

1.4GB

Inquiry paling kecil adalah 26 pages/sec.

VM3

1.4GB

Throughput Rate di sini adalah banyaknya pages yang terseksekusi ketika melakukan pengujian

VM4

1.5GB

dalam setiap detik. Semakin besar Throughput

maka semakin baik.

Ketika melakukan pengujian, penggunaan memory

VM 3 VM 4

pada virtual machines akan semakin besar. Ini

disebabkan karena virtual machines dalam test rig mencoba untuk membuat user-user virtual untuk

melakukan pengujian terhadap sistem I-banking.

Data di atas merupakan rata-rata jumlah resource memory yang tersisa ketika melakukan pengujian

pada skenario Balance Inquiry. Selama pengujian

penggunaan resource memory pada setiap Virtual Machines masih tersisa, berarti penggunaan

memory sebesar 7GB sudah cukup untuk melakukan

76 0:05:45 95.55 Table 4-24 Informasi Threshold Penggunaan Processor

88.64 0:07:00 35.01 > 75% (Balance Inquiry)

84.72 0:09:00 85.31 Threshold Processor

Ketika melakukan pengujian, sama halnya

penggunaan processor pada virtual machines akan

96.86 semakin besar juga. Ini disebabkan karena virtual

95.71 machines dalam test rig mencoba untuk membuat user-user virtual untuk melakukan pengujian

97.74 terhadap sistem I-banking. Pada pengujian ini,

95.89 terpasang peringatan (warning) yang akan di rekam oleh test rig ketika penggunaan resource processor

88.93 lebih dari 75%. Data di atas merupakan informasi

91.03 penggunaan resource processor ketika melebihi ambang batas 75% dalam melakukan pengujian

79.95 pada skenario Balance Inquiry. Selama pengujian

86.76 penggunaan resource processor pada setiap Virtual Machines tidak pernah mencapai nilai 100%,

78.59 sehingga penggunaan 4 cores pada Virtual

85.16 Machines dalam Microsoft Azure sudah cukup untuk melakukan pengujian.

95.83 4.4 Analisi Hasil Pengujian

Berdasarkan hasil data dari pengujian yang telah

89.74 dilakukan di atas, dapat dijadikan acuan untuk

85.65 menjawab pertanyaan Research Question yang ada di Bab pertama pada bagian perumusan masalah

79.93 (1.2) yang berisi sebagai berikut:

RQ 1: Bagaimana membangun Test Rig yang mensimulasikan kebiasaan user dalam melakukan

optimum untuk dapat melakukan Web

permintaan (request) dan mendapatkan respon dari Performance dan Load Test pada I-banking sistem I-banking pada tahap pengujian

Bank XYZ?

Hal yang perlu diperhatikan dalam penempatan Virtual Machine, harus dekat dengan Web Server

Sebagaimana yang telah diterangkan untuk dapat sistem I-banking Bank XYZ, sehingga konektifitas membangun Test Rig dalam Cloud Microsoft Azure jaringan internet tidak akan mempengaruhi hasil dan dapat melakukan web performance dan load test pengujian. Pemilihan lokasi cloud server yang diperlukannya

melakukan terdekat adalah pada zona Regional South East Asia pengaturan/pembangunan pada 4 hal utama, - Singapore. diataranya: Team Foundation Server Online,

Selain itu setiap Virtual Machine harus mempunyai Virtual Machine , Test Agent/Test Controller dan Static IP Address yang terdaftar pada Firewall penggunaan Static IP Address. Load Balancer sistem I-banking Bank XYZ,

Team Foundation Server Online akan digunakan sehingga dapat melakukan multiple/bulking request untuk menyimpan file testing yang terdapat dalam dan mengijinkan multiple cookies melalui HTTP Microsoft Visual Studio dan saling berbagi Port . (sharing) sesama 4 Virtual Machine lainnya.

RQ 2: Bagaimana performansi Test Rig saat

Virtual Machine yang digunakan saling terhubung melakukan proses pengujian pada I-banking dengan jaringan lokal Microsoft Azure dan Bank XYZ, berdasarkan penggunaan processor, terhubung dengan Team Foundation Server Online memory dan parameter evalusi response time, melalui jaringan Internet. Setiap Virtual Machine throughput, error rate?

menggunakan sistem operasi Windows Server 2012

R2, terdapat Visual Studio 2013 Ultimate, dan Dari hasil pengujian (Load Testing) pada bagian browser Internet Explorer versi 9.0.

“Test Rig” (Bab 4.3.1) dengan menggunakan 4 Berdasarkan yang sudah dijelaskan pada pagian Virtual Machines dapat disimpulkan sebagai

Bab 3.2.2, digunakannya 4 Virtual Machines berikut: dengan menggunakan paket A3 (4 cores processor dan 7 GB memory) pada Cloud Microsoft Azure. Penggunaan processor di setiap Virtual Machine Karena batas jumlah maksimal cores processor tidak pernah mencapai 100%, walaupun dalam yang dapat dipakai dalam 1 User ID adalah 20 beberapa waktu processor terpakai lebih dari 75% cores . Maka dari itu paket A3 yang akan dipakai dan Penggunaan memory (RAM) masih selalu untuk

karena tersedia lebih dari 1 GB, sehingga penggunaan

penguji/tester hanya mempunyai 1 User ID dan hardware dengan spesifikasi 4 cores processor dan membutuhkan 4 Virtual Machines. Selain itu juga

7 GB memory RAM sudah layak untuk melakukan

membutuhkan spesifikasi yang tinggi, sehingga pengujian pada sistem I-banking Bank XYZ sesuai performansi VM tidak akan mempengaruhi pada dengan yang diharapkan. hasil pengujian. Digunakananya 4 virtual machines mempunyai Sedangkan berdasarkan parameter evaluasi tujuan lain yaitu agar web server yang digunakan

response time, throughput dan error rate didapatkan oleh sistem I-banking akan berkerja/aktif semua.

hasil sebagai berikut: Besar response time pada

Sehingga mendapatkan hasil pengujian yang setiap Virtual Machines dalam melakukan maksimal ketika melakukan stress test pada sistem pengujian maksimal sebesar 6 detik, dengan I-banking Bank XYZ.

(minimal) throughput sebanyak 6 pages per detik dan error rates (terbesar) adalah 94% (akan tetapi

Test Agent dan Test Controller terpasang di setiap semua errors ini disebabkan oleh sistem I- banking Virtual Machine dan saling terhubung dengan SQL Bank XYZ, seperti yang dipaparkan dalam Bab Server Agent di setiap Virtual Machines untuk

4.3.1 dan 4.3.2 pada bagian Error Details), sehingga dapat menyimpan hasil data pengujian yang telah penggunaan konektifitas jaringan internet pada dilakukan. Selain itu berfungsi untuk menghasilkan setiap Virtual Machines dengan kecepatan user-user virtual yang seolah-olah dapat download sebesar +-289 Mbps dan kecepatan 4.3.1 dan 4.3.2 pada bagian Error Details), sehingga dapat menyimpan hasil data pengujian yang telah penggunaan konektifitas jaringan internet pada dilakukan. Selain itu berfungsi untuk menghasilkan setiap Virtual Machines dengan kecepatan user-user virtual yang seolah-olah dapat download sebesar +-289 Mbps dan kecepatan

V. KESIMPULAN DAN SARAN

RQ 3: Apa saja faktor yang mempengaruhi performansi (bottlenecks) dari web I-banking

5.1. Kesimpulan

Bank XYZ?

Adapun kesimpulan yang dapat ditarik dari hasil penetian dan pengujian ini adalah sebagai berikut:

Dari hasil pengujian (Load Testing) pada bagian Bab 4.3.1 dan 4.3.2 terutama pada hasil data “Error

1. Hal yang paling utama dalam membangun Test Details

Rig ”, “Request Files” dan “Pages” dapat di dalam Cloud Microsoft Azure untuk dapat simpulkan 5 faktor yang paling mempengaruhi

melakukan web performance dan load testing performasi dari web I-banking Bank XYZ adalah:

pada sistem I-banking Bank XYZ adalah melakukan pengaturan/pembangunan pada:

a. Server tidak sanggup menerima banyak Team Foundation Server Online, 4 Virtual request (dalam pengujian ini ada 4000 request

Machine, Test Agent/Test Controller dan secara bersamaan dalam target waktu tertentu) akan

penggunaan Static IP Address. tetapi proses request sudah sampai pada server,

Paket Virtual Machines yang di ambil dalam tidak timeout. Hal tersebut terlihat lebih dari 4000

Microsoft Azure adalah A3 (4 cores processor dan 7 GB memory). Paket resource VM ini

pengujian yang di arahkan ke halaman systemUnavailable.html atau error pag

e “503”. cukup untuk dapat membangun 1000 user

b. Ada lebih dari 8000 request yang terputus virtual (per VM), terbukti tidak adanya dan tidak mendapatkan respon dari server ketika

penggunaan processor atau memory yang melakukan pengujian. Kasus ini bisa terjadi karena

melebihi threshold lebih dari 100% ketika beban server yang tinggi ketika merespon dari

melakukan pengujian. Penggunaan static IP permintaan (request) sebelumnya atau konektifitas

Address dalam setiap Virtual Machines harus jaringan Internet server terlalu kecil atau kurang

dilakukan untuk dapat dimasukan kedalam cukup untuk menampung semua request dari user-

whitelist atau diijinkan untuk menembus user virtual.

firewall load balancer sistem I-banking.

c. Ada lebih dari 4000 request yang hasil Terutama untuk melakukan spamming/bulking respon parameternya berbeda (WebTestException

request dan multiple cookies. Penempatan Type) dari hasil record. Hal ini disebabkan karena

Virtual Machine juga harus dekat dengan Web ketika melakukan proses request metode post,

Server sistem I-banking Bank XYZ, sehingga sistem I-banking tidak memberikan respon

konektifitas jaringan internet tidak akan parameter yang valid atau bisa saja tidak ada respon

mempengaruhi hasil pengujian. sama sekali yang diberikan. Hal tersebut juga dapat

terjadi karena terdapat (bottlenecks) pada sistem

2. Performansi Test Rig dalam melakukan database Bank XYZ, karena metode post yang

pengujian yang menggunakan resource 4 cores dilakukan dalam pengujian ini selalu melibatkan

Processor dan 7 GB memory dalam setiap pengambil data pada database sistem I-banking

Virtual Machines untuk membangun 1000 user Bank XYZ.

virtual, dengan kecepatan Internet download +- 289 Mbps / upload +- 82 Mbps dalam

d. Pada bagian hasil data Request Files (Tabel 4-8 dan 4-24) ada 5 hal yang paling sering

mengakses sistem I-banking, sudah layak untuk menimbulkan errors respon dan semuanya selalu

melakukan pengujian pada sistem I-banking berkaitan dengan metode

“POST”, yang sesuai yang diharapkan. Hal ini terbukti tidak melibatkan penggunaan database (post method).

adanya penggunaan processor atau memory Sehingga dapat disimpulkan terdapat (bottlenecks)

yang melebihi threshold lebih dari 100% ketika pada sistem database Bank XYZ dalam kasus

melakukan pengujian.

tersebut.

3. Hal yang paling banyak menyebabkan errors gambar yang menimbulkan banyak errors, ini bisa

e. Selain itu ada banyak file .css, .js dan file

dalam pengujian ini adalah faktor dari server I- dalam pengujian ini adalah faktor dari server I-

"The Future of Software Performance menampung semua request dari user, resource

of Software server yang kurang baik (kecil) dan masih

banyaknya file-file website yang tidak [7] J. A. Whittaker, "What is Software Testing? dikompres (minify) atau tidak menggunakan

And Why is It So Hard," Software, IEEE, teknik caching. Sehingga nilai errors dalam

2000.

pengujian ini sangat besar. [8] M. Gousset, B. Keller and M. Woodward,

Professional Application Lifecycle

5.2. Saran

Di akhir laporan tugas akhir ini, penulis Management with Visual Studio 2012,

memberikan saran kepada pihak yang membaca Indiana USA: John Wiley & Sons, Inc., penelitian ini sebagai berikut:

2012.

[9]

E. J. Weyuker, S. Member, IEEE and F. I.

Penggunaan Test Agent yang dipasang langsung Vokolos, "Experience with Performance pada pihak sistem yang akan diuji, seperti Testing of Software System: Issues, an

penempatan pada Database server atau Web Server Approach, and Case Study," Software dalam sistem I-banking belum diimplementasikan

Engineering, 2000.

pada penelitian ini, pengujian yang dibantu dengan

pemasangan Test Agent pada target pengujian (dalam kasus di sini sistem I-banking) akan dapat menghasilkan parameter hasil uji yang lebih detail,

sehingga akan mengetahui lebih dalam faktor yang [10] Microsoft Developer Network Support, mempengaruhi performasi (bottleneks) dari sistem "Setting Up Test Machines to Run Tests or tersebut.

Collect Data," Microsoft, 2013. [Online]. Available: http://msdn.microsoft.com/en-

us/library/dd293551.aspx. [Accessed 18

REFERENSI

October 2014]. [11] E. Blanker, M. Woodward, G. Holliday and

B. Keller, Proffesional Team Foundation [1] C. Hewitt, "ORGs for Scalable, Robust,

Server 2012, Indianapolis: John Wiley & Privacy-Friendly Client Cloud Computing,"

Sons, Inc., 2013.

IEEE Internet Computing, 2008. [12] J.-L. David, M. Gousset and E. Gunvaldson, [2] T. Arora, "Part 1 - Load Testing In The

Professional Team Foundation Server, Cloud," 29 June 2013. [Online]. Available:

Indianapolis: Wiley Publishing, Inc., 2007. http://geekswithblogs.net/TarunArora/archi

[13] Microsoft Developer Network, "Setting Up ve/2011/11/20/part-1---load-testing-in-the-

Test Controllers in Lab Environments," cloud.aspx. [Accessed 18 October 2014].

Microsoft, 2013. [Online]. Available: [3] C. Vecchiola, X. CHU and R. Buyya,

http://msdn.microsoft.com/en- "Aneka: a Software Platform for .NET based

us/library/hh546460.aspx. [Accessed 24 11 Cloud Computing," High Speed and Large

2014].

Scale Scientific Computing, 2009. [4] Tata Consultancy Services, "Windows

Azure - The Cloud Computing Platform," High Tech, 2011.

[5] Azure Team Support, "What is Azure?," Microsoft, 2014. [Online]. Available: http://azure.microsoft.com/en- us/overview/what-is-azure. [Accessed 1 October 2014].

Dokumen yang terkait

Penerapan dan Analisis Perhitungan Orang dengan Chromatic Color Model Studi Kasus : Perhitungan orang dalam sebuah antrian Implementation and Analysis of People Counting with Chromatic Color Model Case Study: Calculation of People In a Queue

0 1 13

Analisis dan Penerapan Perhitungan Orang Menggunakan Metode Histogram Of Oriented Gradients-Local Binary Pattern Dengan Deteksi Kepala-Bahu Studi Kasus: Perhitungan Orang Dalam Kelas Analysis and Implementation Of People Counting Using Histogram Of Orient

0 2 13

Analisis dan Implementasi Graph Indexing Pada Graph Database Menggunakan Algoritma GraphGrep Analysis and Implementation of Graph Indexing for Graph Database Using GraphGrep Algorithm

0 0 6

Implementasi dan Analisis Degree Centrality Berbasis Konten menggunakan Metode Opsahl

0 0 7

Analisis dan Implementasi Scale Invariant Feature Transform (SIFT) pada Sistem Autentikasi Menggunakan Pembuluh Vena

0 1 9

Pengenalan Ekspresi Wajah Manusia dengan Metode Local Directional Pattern dan Artificial Immune Recognition System

0 0 6

Prediksi Perkembangan Kondisi Pasien Terapi HIV dengan Menggunakan Representasi ALE-index sebagai Invariant Nucleotida sequence dan Support Vector Machine

0 0 12

Aplikasi Pendukung Keputusan untuk Pemilihan Produk Asuransi dengan Metode Entropy dan Vikor pada AJB Bumiputera 1912 Jepara

0 0 12

Analisis Penggunaan Algoritma Delay Scheduling terhadap Karakteristik Job

0 0 8

Analisis Sentimen pada Twitter untuk Menilai Performansi Program Televisi dengan Kombinasi Metode Lexicon-Based dan Support Vector Machine

0 1 11