PENGEMBANGAN SISTEM INFORMASI AKADEMIK

PONDOK PESANTREN SUMBER BAROKAH KARAWANG

UNTUK MENINGKATAN KECEPATAN MODUL
ADMINISTRASI KEUANGAN

TESIS

Oleh :
Herianto Saputra
NIM : 1911601126

PROGRAM STUDI MAGISTER ILMU KOMPUTER

FAKULTAS TEKNOLOGI INFORMASI
UNIVERSITAS BUDI LUHUR

JAKARTA
GENAP 2020/2021

i
 PENGEMBANGAN SISTEM INFORMASI AKADEMIK
PONDOK PESANTREN SUMBER BAROKAH KARAWANG
UNTUK MENINGKATAN KECEPATAN MODUL
ADMINISTRASI KEUANGAN

TESIS

Diajukan untuk memenuhi salah satu persyaratan memperoleh gelar

Magister Ilmu Komputer (MKOM)

Oleh :
Herianto Saputra
NIM : 1911601126

PROGRAM STUDI MAGISTER ILMU KOMPUTER

FAKULTAS TEKNOLOGI INFORMASI
UNIVERSITAS BUDI LUHUR

JAKARTA
GENAP 2020/2021

ii
iii
 ABSTRAK
Analisis Komparasi Terhadap Respon Time Database Management System Pada
Sistem Informasi Administrasi Pondok Pesantren
Herianto Saputra (1911601126)

Sistem Informasi diharapkan dapat memberikan kemudahan bagi suatu

perusahaan dalam pengelolaan data. Sistem informasi yang lambat akan
mempengaruhi kinerja operasional dan akan menimbulkan masalah baru, untuk itu
perlu dilakukan perancangan yang baik dan analisa kembali yang dapat
mempengaruhi kecepatan dari akses suatu sistem informasi. Metode yang akan
dipakai adalah menggunakan metode penelitian komparatif kuantitatif. Tujuan
Penelitian ini adalah untuk mengoptimasi aplikasi Administrasi Pondok Pesantren
Sumber Barokah Karawang terutama pada transaksi pembayaran. Penelitian ini
membandingkan kecepatan respontime Aplikasi lama yang menggunakan database
Mysql/MariaDB menggunakan webserver Apache dengan aplikasi baru yang
menggunakan database MongoDB dan webserver Nginx.
Kata kunci: database, mariadb, postgresql, responsetime, mongodb, web server,
Apache, Nginx.

iv
 ABSTRACT
Analisis Komparasi Terhadap Respon Time Database Management System Pada
Sistem Informasi Administrasi Pondok Pesantren
Herianto Saputra (1911601126)

Information systems are expected to provide convenience for a company in

data management. A slow information system will affect operational performance
and will cause new problems, for that it is necessary to do a good design and re-
analysis that can affect the speed of access to an information system. The method
that will be used is a quantitative comparative research method. The purpose of this
study was to optimize the application for the administration of the Sumber Barokah
Islamic Boarding School in Karawang, especially in payment transactions. This
study compares the response time of the old application using the Mysql/MariaDB
database using the Apache webserver with the new application using the MongoDB
database and the Nginx webserver.
Keywords: database, mariadb, postgresql, responsetime, mongodb, web server,
Apache, Nginx.

v
 KATA PENGANTAR

Alhamdulillahirobbil`alamiin, puji syukur penulis sampaikan kehadirat

Allah SWT karena atas rahmat dan hidayah-Nyalah penulis dapat menyelesaikan
proposal tesis yang berjudul Analisis Komparasi Terhadap Respon Time Database
Management System Pada Sistem Informasi Administrasi Pondok Pesantren.
Tujuan dari penulisan proposal tesis ini adalah sebagai salah satu syarat untuk
Menyusun tesis pada Program Studi Magister Ilmu Komputer, Universitas Budi
Luhur Jakarta.
Ucapan terima kasih penulis persembahkan kepada semua pihak yang telah
membantu penulis dalam penyusunan proposal tesis ini :
1. Bapak Dr. Ir. Wendi Usino, M.Sc., M.M selaku Rektor Universitas Budi
Luhur dan Dosen mata kuliah Metodologi Penelitian, yang telah
membimbing penulis dalam penyusunan proposal tesis ini.
2. Dr. Deni Mahdiana, S.Kom., M.M., M.Kom selaku Dekan Fakultas
Teknologi Informasi
3. Dr. Rusdah, S.Kom., M.Kom selaku ketua program Magister Ilmu
Komputer Universitas Budi Luhur.
4. Seluruh Dosen dan Staff Universitas Budi Luhur.
5. Kepada kedua orangtua dan semua keluarga penulis yang telah memberikah
dukungan dan motivasi.
6. Kepada rekan-rekan mahasiswa Universitas Budi Luhur.
Penulis menyadari bahwa proposal tesis ini masih banyak kekurangannya untuk itu
kritik dan saran konstruktif sangatt diharapkan untuk kesempurnaan proposal tesis
ini.

Karawang, 30 Agustus 2021

Penulis

vi
 DAFTAR ISI

LEMBAR PENGESAHAN ............................................................................. iii

ABSTRAK ........................................................................................................ iv
KATA PENGANTAR....................................................................................... vi
DAFTAR ISI .................................................................................................... vii
DAFTAR TABEL ............................................................................................. vii
DAFTAR GAMBAR......................................................................................... ix

BAB I PENDAHULUAN
1.1 Latar Belakang .......................................................................... 2
1.2 Masalah Penelitian
1.2.1 Identifikasi Masalah ......................................................... 2
1.2.2 Pembatasan Masalah ....................................................... 2
1.2.3 Rumusan Masalah ........................................................... 2
1.3 Tujuan Penelitian ...................................................................... 2
BAB II LANDASAN TEORI DAN KAJIAN TEORITIS
2.1 Landasan Teori dan Kajian Teoritis ......................................... 3
2.2 Kajian Literatur ........................................................................ 13
2.3 Hipotesis ................................................................................... 28
2.4 Kerangka Pemikiran .................................................................. 28
BAB III METODOLOGI DAN RANCANGAN PENELITIAN
3.1 Jenis Penelitian ......................................................................... 29
3.2 Tempat dan Waktu Penelitian .................................................. 29
3.3 Tahapan Analisi Kebutuhan ..................................................... 29
3.4 Tahapan Perancangan dan Desain Sistem ................................. 30
3.5 Tahapam Skenario Pengujian .................................................... 30
3.6 Tahapan Pengujian .................................................................... 31
3.7 Evaluasi Sistem ......................................................................... 31
BAB IV PEMBAHASAN HASIL PENGUJIAN
4.1 Hasil Wawancara....................................................................... 33
4.2 Use Case Diagram .................................................................... 34
4.3 Activity Diagram ....................................................................... 35
4.4 Desain User Interface ................................................................ 42
4.5 Pengujian dengan Apache Jmeter ............................................ 47
4.6 Evaluasi Pengujian Aplikasi ..................................................... 61

BAB V PENUTUP
5.1 Kesimpulan .............................................................................. 63
5.2 Saran ........................................................................................ 63

DAFTAR PUSTAKA ........................................................................................ 64

vii
 DAFTAR TABEL
Tabel 2.1 Kajian Literatur Web Server ........................................................... 16
Tabel 2.2 Kajian Literatur Framework Backend ............................................ 22
Tabel 2.3 Kajian Literatur Database ............................................................... 27
Tabel 3.1 Instrumen Interview ........................................................................ 30
Tabel 3.2 Skenario Pengujian ........................................................................ 31
Tabel 3.3 Instrumen Pengujian ....................................................................... 32
Tabel 4.1 Hasil Wawancara ............................................................................ 34
Tabel 4.2 Hasil Pengujian Login Aplikasi Lama ............................................ 46
Tabel 4.3 Hasil Pengujian Login Aplikasi Baru ............................................. 47
Tabel 4.4 Hasil Pengujian CRUD Daya Siswa/I Aplikasi Lama .................... 48
Tabel 4.5 Hasil Pengujian CRUD Daya Siswa/I Aplikasi Baru ...................... 49
Tabel 4.6 Hasil Pengujian Transaksi Tabungan Aplikasi Lama ..................... 51
Tabel 4.7 Hasil Pengujian Transaksi Tabungan Aplikasi Baru ...................... 51
Tabel 4.8 Hasil Pengujian Transaksi Pembayaran Aplikasi Lama ................. 52
Tabel 4.9 Hasil Pengujian Transaksi Pembayaran Aplikasi Baru .................. 53
Tabel 4.10 Hasil Pengujian Laporan Tabungan Aplikasi Lama ..................... 54
Tabel 4.11 Hasil Pengujian Laporan Tabungan Aplikasi Baru ...................... 55
Tabel 4.12. Hasil Pengujian Laporan Pembayaran Aplikasi Lama ................ 57
Tabel 4.13. Hasil Pengujian Laporan Pembayaran Aplikasi Baru ................. 58
Tabel 4.14. Hasil Pengujian Laporan Koreksi Aplikasi Lama ....................... 59
Tabel 4.15. Hasil Pengujian Laporan Koreksi Aplikasi Baru ......................... 60
Tabel 4.16. Evaluasi Pengujian Aplikasi ........................................................ 62

viii
 DAFTAR GAMBAR

Gambar 2.1 Relational Database Management System ................................. 6

Gambar 2.2 Summary Report Data Pada Apache Jmeter ............................... 10
Gambar 2.3 Label Pada Apache Jmeter .......................................................... 10
Gambar 2.4 LoadFocus .................................................................................. 12
Gambar 2.5 Diagram Kerangka Pemikiran ..................................................... 28
Gambar 3.1 Import Database pada MongoDB ................................................ 31
Gambar 4.1 Use Case Diagram ....................................................................... 34
Gambar 4.2 Activity Diagram Login ............................................................... 35
Gambar 4.3 Activity Diagram CRUD Data Siswa/I untuk Admin.................. 36
Gambar 4.4 Activity Diagram CRUD Data Siswa/I untuk Teller ................... 37
Gambar 4.5 Activity Diagram Transaksi Tabungan ........................................ 38
Gambar 4.6 Activity Diagram Transaksi Pembayaran .................................... 39
Gambar 4.7 Activity Diagram Laporan Tabungan .......................................... 40
Gambar 4.8 Activity Diagram Laporan Pembayaran ...................................... 41
Gambar 4.9 Activity Diagram Koreksi Pembayaran ....................................... 42
Gambar 4.10 Halaman Login .......................................................................... 43
Gambar 4.11 Halaman CRUD Data Siswa/i ................................................... 43
Gambar 4.12 Halaman Transaksi Tabungan .................................................. 44
Gambar 4.13 Halaman Transaksi Pembayaran ............................................... 44
Gambar 4.14 Halaman Laporan Tabungan ..................................................... 45
Gambar 4.15 Halaman Laporan Pembayaran ................................................. 45
Gambar 4.16 Halaman Koreksi Pembayaran .................................................. 46
Gambar 4.17 Diagram Pengujian Login Aplikasi Lama dan Baru ................. 48
Gambar 4.18 Diagram Pengujian CRUD Aplikasi Lama dan Baru .............. 50
Gambar 4.19 Diagram Transaksi Tabungan Aplikasi Lama dan Baru ........... 52
Gambar 4.20 Diagram Transaksi Tabungan Aplikasi Lama dan Baru ........... 54
Gambar 4.21 Diagram Laporan Tabungan Aplikasi Lama dan Baru .............. 56
Gambar 4.22 Diagram Laporan Pembayaran Aplikasi Lama dan Baru ......... 58
Gambar 4.23 Diagram Koreksi Pembayaran Aplikasi Lama dan Baru .......... 60

ix
 BAB I
PENDAHULUAN
1.1 Latar Belakang
Sistem informasi adalah alat untuk menyajikan informasi sedemikian rupa
sehingga bermanfaat bagi penerimanya. Tujuannya adalah untuk memberikan informasi
dalam perencanaan, memulai, pengorganisasian, operasional sebuah perusahaan yang
melayani sinergi organisasi dalam proses mengendalikan pengambilan keputusan (Kouw
et al., 2020).Dengan adanya sistem informasi diharapkan dapat meningkatkan kinerja dan
efektifitas dari suatu perusahaan. Begitu juga pada Yayasan Sumber Barokah Karawang
telah terdapat sistem informasi yang berjalan dan mempermudah juga meningkatkan
efektifitas baik yang bersifat akademik maupun administratif namun dalam
implementasinya tentunya terdapat beberapa kendala yang menjadikan proses yang
dilakukan masih belum sesuai dengan yang diharapkan baik ketika pertama kali
implementasi maupun setelah beberapa waktu kemudian diantaranya pada awal
implementasi adalah penyesuaian terhadap sistem, Adapun kendala ketika sistem ini telah
berjalan adalah jumlah data yang terus meningkat dapat mempengaruhi kecepatan akses
data.
Sistem informasi pada Pondok Pesantren Sumber Barokah ini terdapat aplikasi
administrasi yang mengunakan framework Jqgrid dengan Bahasa pemograman javascript
dan PHP sedangkan databasenya menggunakan database Mysql dengan total jumlah data
yang telah terecord berdasarkan hasil penelitian pada tanggal 04 Juni 2021 diperoleh
jumlah file data 982.522 untuk tabel transaksi tabungan dan 203.884 untuk transaksi
Pembayaran uang makan (SPP). Dari jumlah data yang ada dan dengan spesifikasi server
sebagai berikut :
• OS : Ubuntu 20.04.1 LTS
• Processor : intel Xeon(R) E-2124 3.30GHz x 4
• Ram Server : 24gb DDR4
• SSD : 240GB SATA Samsung Evo
• Hardisk : 1TB

Dengan menggunakan spesifikasi server diatas waktu yang diperlukan untuk

mengakses menu transaksi tabungan sekitar 2 – 5 detik dan transaksi SPP/Kost Pondok
0.1 – 3 detik dan akan berulang ketika refresh page.

Apabila dijalankan di sisi Client dengan spesifikasi client sebagai berikut :

• OS : Windows 10 64bit
• Processor : intel core i3-3240
• Ram Server : 4gb DDR3
• Hardisk : 500GB

Waktu yang diperlukan untuk mengakses menu transaksi tabungan sekitar 3 – 10

detik dan transaksi SPP/Kost Pondok 2 – 5 detik dan akan berulang ketika refresh page.

1
1.2 Masalah Penelitian
1.2.1 Identifikasi Masalah
1) Akses untuk menu transaksi tabungan dan SPP/ Kost Pondok lambat..
2) Akses menu laporan tabungan sangat lambat.
3) Ada bebarapa menu aplikasi keuangan yang sudah tidak digunakan lagi.
4) Untuk perbaikan dan pengembangan aplikasi terkendala karena pihak
developer sudah tidak dapat dihubungi lagi
5) Terdapat beberapa bug yang menjadikan proses tidak dapat berjalan.
6) Terdapat 178 tabel database dan banyak yang tidak digunakan.
7) Terdapat beberapa script yang sudah digunakan tapi masih berjalan.

1.2.2 Batasan Masalah

Pembatasan suatu masalah digunakan untuk menghindari adanya
penyimpangan maupun pelebaran pokok masalah agar penelitian tersebut lebih
terarah dan memudahkan dalam pembahasan sehingga tujuan penelitian akan
tercapai. Beberapa batasan masalah dalam penelitian ini adalah sebagai berikut:
1) Luas lingkup hanya meliputi informasi akses load data pada transaksi
pembayaran.
2) Informasi yang disajikan yaitu transaksi pembayaran.

1.2.3 Rumusan Masalah

1. DBMS apa yang dapat mempercepat akses menu transaksi Administrasi Pondok
Pesantren Sumber Barokah?
2. Framework apa yang dapat mempercepat akses menu transaksi Administrasi
Pondok Pesantren Sumber Barokah?
3. Webserver apa yang dapat mempercepat akses menu transaksi Administrasi
Pondok Pesantren Sumber Barokah?

1.3.Tujuan Penelitian
1) Untuk Mengetahui jenis database apa yang dapat mempercepat akses terhadap
aplikasi administrasi pondok sumber barokah?.
2)
3) Untuk Merancang Aplikasi Pondok Pesantren Sumber Barokah Karawang
dengan akses yang memiliki response time lebih cepat.
4) Sebagai bahan referensi bagi pengembang lain yang ini mengembangkan sistem
dengan database MongoDB.

2
 BAB II
LANDASAN TEORI DAN KAJIAN TEORITIS
3.1 Landasan Teori
1. Response Time
Response Time adalah waktu tanggap yg diberikan oleh antar
muka/interface ketika user mengirim permintaaan ke komputer. Secara umum,
pengguna menginginkan bahwa program aplikasinya dapat memberikan waktu
tanggap yang sependek – pendeknya. Tetapi waktu tanggap yang baik memang
tidak dapat ditentukan, karena ada beberapa aspek yang mempengaruhi, antara
lain yakni ragam interaksi yang diinginkan dan kefasihan pengguna dalam
menjalankan program aplikasi tersebut (Noviyanti et al., 2018).

2. Query
Query adalah semacam kemampuan untuk menampilkan suatu data dari
database dimana mengambil dari tabel-tabel yang didatabase, namun tabel
tersebut tidak semua ditampilkan sesuai yang diinginkan atau data yang ingin
ditampilkan (Sinuraya, 2017). Menurut SilberSchatz, query adalah sebuah
pernyataan yang meminta pengaksesan informasi. Query (permintaan) merupakan
metode pengaksesan yang paling sering digunakan. Dalam DBMS, query
dinyatakan dalam Structured Query Languange (SQL) (Lubis, 2017).
Dari tiga query khusus SQL, query definisi data adalah yang paling tidak
berguna terhadap tabel lokal. Segala sesuatu yang dapat dilakukan dengannya
juga dapat dilakukan dengan menggunakan alat desain di Access. Namun, query
definisi data adalah cara yang efisien untuk membuat atau mengubah objek
database. Dengan kueri definisi data, pernyataan SQL ini dapat digunakan
(Noviyanti et al., 2018).

3. Structure Query Language (SQL)

Structure Query Language (SQL) adalah standar bahasa untuk berinteraksi
dengan database dengan menggunakan operasi-operasi umum pada basis data
(Sinuraya, 2017). Structured Query Language (SQL) pada awalnya disebut
dengan SEQUEL dikembangkan di IBM oleh Donald D. Chamberlin dan
Raymond F. Boyce pada tahun 1970. SQL digunakan untuk memanipulasi dan
menarik data yang tersimpan pada IBM database management system yang
disebut dengan System R. SQL ini dikembangkan setelah mempelajari model
rasional dari manajemen basis data yang ditemukan oleh E. F Codd di awal tahun
1970 (Suliyanti, 2019).
SQL adalah struktur blok Bahasa query dalam pengambilan dan
pemanipulasian data. Dalam pemakaianya, SQL dibagi menjadi 2 :
1) Data Definition Language (DDL) : Bahasa yang digunakan untuk
mendifinisikan data DDL terdiri dari CREATE (mengubah) dan DROP
(menghapus)
2) Data Manipulation Language (DML) : Bahasa yang digunakan untuk
memanipulasi data. DML terdiri dari SELECT (mengambil), INSERT
(menambah), DELETE (menghapus) dan UPDATE (mengubah).

3
 Perintah DDL membuat/mengubah/menghapus suatu objek tertentu, seperti
database, table. View, trigger, stored procedure dan sebagainya (tergantung dari
versi standar SQL yang digunakan) (Selamet, 2008).

4. Database/Basis Data
Database terdiri atas 2 kata, yaitu Basis dan Data. Basis kurang lebih dapat
diartikan sebagai markas atau gudang, tempat bersarang atau berkumpul.
Sedangkan Data adalah representasi fakta dunia nyata yang mewakili suatu objek
seperti manusia (pegawai, siswa, pembeli, pelanggan), barang, hewan, peristiwa,
konsep, keadaan, dan sebagainya, yang diwujudkan dalam bentuk angka, huruf,
symbol, teks, gambar, bunyi, atau kombinasinya(Maanari et al., 2013).

Basis data merupakan kumpulan data dari berbagai entitas yang saling
berhubungan. Basis data dikelola melalui sebuah perangkat lunak yang disebut
database managements System (DBMS). Melalui DBMS manusia dapat
berinteraksi dengan basis data. Salah satu DBMS paling populer saat ini adalah
Oracle, perangkat lunak produksi Oracle USA, Inc yang merupakan aplikasi
Relational DBMS dengan berbagai macam fiturfitur yang dapat mengoptimalkan
pengelolaan basis data. Dalam dunia bisnis saat ini, suatu perusahaan (contohnya
sebuah distributor) membutuhkan suatu sistem yang mampu menangani dan
mengolah data dari proses bisnisnya dengan cepat dan akurat tanpa membuang
banyak biaya maupun waktu. Hal ini tentunya juga sangat penting mengingat
persaingan yang semakin ketat dalam dunia bisnis. Dengan adanya sebuah sistem
informasi yang didukung sebuah basis data yang baik diharapkan mampu
menambah daya saing dari perusahaan serta tentunya mewujudkan prinsip
ekonomi yaitu menambah keuntungan dan menekan pengeluaran sekecil mungkin
(Maanari et al., 2013).

Database adalah kumpulan informasi yang disimpan di dalam komputer

secara sistematik sehingga dapat diperiksa menggunakan suatu program komputer
untuk memperoleh informasi dari basis data tersebut. Database adalah
representasi kumpulan fakta yang saling berhubungan disimpan secara bersama
sedemikian rupa dan tanpa pengulangan (redudansi) yang tidak perlu, untuk
memenuhi berbagai kebutuhan. Database merupakan sekumpulan informasi yang
saling berkaitan pada suatu subjek tertentu pada tujuan tertentu pula. Database
adalah susunan record data operasional lengkap dari suatu organisasi atau
perusahaan, yang diorganisir dan disimpan secara terintegrasi dengan
menggunakan metode tertentu dalam komputer sehingga mampu memenuhi
informasi yang optimal yang dibutuhkan oleh para pengguna (Helmud, 2021).

Database didefinisikan sebagai pengumpulan data yang terorganisir.

selain itu, basis data juga dapat merujuk ke sistem datastore atau juga disebut
kumpulan dataset yang disimpan dalam sistem datastore. Sistem datastore ini
yang menangani semua dataset dan organisasinya, mengambil, menyimpan, dan
memperbarui disebut Sistem Manajemen Basis Data (DBMS) (Kinanti, 2021).

4
5. Relational Database Management System (RDBMS)
Relational database merupakan basis data dimana data disimpan dalam
bentuk tabel yang terdiri dari baris dan kolom. Relational database memiliki
bentuk schema (struktur tabel) yang tetap. Software system.

database relational disebut sebagai relational database management

system (RDBMS) dimana bahasa yang digunakan untuk melakukan query disebut
sebagai structured query language (SQL) (Jaiswal and Agrawal, 2015). Relational
database baik digunakan untuk online transaction processing (OLTP) atau
transaksi online karena dalam relational database sedikit terdapat duplikasi data
berkat adanya normalisasi data. Relational database menggunakan index dan key
sehingga membuat perintah dalam query dapat dengan cepat melakukan
manipulasi data (Setialana, Adji and Ardiyanto, 2017).

Database Management System (DBMS) atau dalam bahasa Indonesia

disebut dengan Manajemen Basis Data adalah perangkat lunak yang dirancang
untuk mengelola dan memanggil kueri (query) basis data. DBMS adalah
perangkat lunak (Software) yang ber-fungsi untuk mengelola database, mulai dari
membuat database itu sendiri, sampai dengan proses-proses yang berlaku dalam
database tersebut, baik berupa entry, edit, hapus query terhadap data, membuat
laporan dan lain sebagainya secara efektif dan efisien. Salah satu jenis DBMS
yang sangat terkenal saat ini adalah Relational DBMS (RDBMS) yang
merepresentasikan data dalam bentuk tabel-tabel yang saling berhubungan.
Sebuah tabel disusun dalam bentuk baris (record) dan kolom (field). Banyak
sekali berkembang perangkat lunak RDBMS ini, misalnya MySQL, Oracle,
Sybase, dBase, MS. SQL,Microsoft Access (MS. Access) dan lain-lain (Saputra,
2012).

Sistem manajemen database atau database management system (DBMS)

adalah merupakan suatu sistem softwareyang memungkinkan seorang user dapat
mendefinisikan, membuat, dan memelihara serta menyediakan akses terkontrol
terhadap data. Database sendiri adalah sekumpulan data yang berhubungan
dengan secara logika dan memiliki beberapa arti yang saling berpautan.
Keuntungan dari Database Management System adalah (Prasetyo, Pattiasina and
Soetarmono, 2015):

1) Pengulangan Data Berkurang. Pengulangan data atau repetisi berarti

bahwa kolom data yang sama (misal: alamat seseorang) muncul berkali-
kali dalam file yang berbeda dan terkadang dalam format yang berbeda.
Dalam sistem pemrosesan yang lama, file - file yang berbeda akan
mengulang data yang sama sehingga memboroskan ruang penyimpanan.
2) Intregitas Data Meningkat. Integritas tidak akurat. dalam DBMS,
berkurangnya pengulangan berarti meningkatkan kesempatan integritas
data, karena semua perubahan hanya dilakukan di satu tempat.
3) Keamanan Data Meningkat. Meskipun berbagai departemen bisa berbagi
pakai data, Namun akses ke informasi bisa dibatasi hanya untuk pengguna

5
 tertentu. Hanya dengan menggunakan password maka informasi finansial,
medis, dan nilaimahasiswa dalam database sebuah universitas tersedia
hanya bagi mereka yang memiliki hak untuk mengetahuinya.
4) Kemudahan Pemeliharaan Data. DBMS menawarkan prosedur standar
untuk menambahkan, mengedit dan menghapus rekaman, juga untuk
memvalidasi pemeriksaan untuk memastikan bahwa data yang tepat sudah
dimasukkan dengan benar dan lengkap ke dalam masing - masing jenis
kolom.

Gambar 2.1 Relational Database Management System (RDBMS)

6. MySQL
MySQL (MY Structure Query Language) adalah salah satu Basis Data
Management System (DBMS) dari sekian banyak DBMS seperti Oracle, MS
SQL, Postagre SQL, dan lainnya. MySQL berfungsi untuk mengolah Basis Data
menggunakan bahasa SQL. MySQL bersifat open source sehingga kita bisa
menggunakannya secara gratis. Pemprograman PHP juga sangat mendukung atau
mensupport dengan Basis Data MySQL (Dio Lavarino, 2016).

MySQL adalah RDBMS yang didistribusikan secara gratis dibawah

lisensi GPL. Dimana setiap orang bebas untuk menggunakan MySQL, namun
tidak boleh dijadikan produk turunan yang bersifat komersial. MySQL sebenarnya
merupakan turunan salah satu konsep utama dalam database sejak lama, yaitu
SQL (Structured Query Language). SQL adalah sebuah konsep pengoperasian
database, terutama untuk pemilihan atau seleksi dan pemasukan data, yang

6
 memungkinkan pengoperasian data dikerjakan dengan mudah secara otomatis.
Keandalan suatu sistem database (DBMS) dapat diketahui dari cara kerja
optimizer-nya dalam melakukan proses perintah-perintah SQL, yang dibuat oleh
user maupun program-program aplikasinya. Sebagai database server, MySQL
dapat dikatakan lebih unggul dibandingkan database server lainnya dalam
query data. Hal ini terbukti untuk query yang dilakukan oleh single user,
kecepatan query MySQL bisa sepuluh kali lebih cepat dari PostgreSQL dan lima
kali lebih cepat dibandingkan Interbase (Standsyah and Restu, 2017).

MySQL merupakan software database open source yang paling populer di

dunia. MySQL menjadi pilihan utama bagi banyak pengembang software dan
aplikasi hal ini dikarenakan kelebihan MySQL diantaranya sintaksnya yang
mudah dipahami, didukung program-program umum seperti C, C++, Java, PHP,
Pyton. Pengguna MySQL tidak hanya sebatas pengguna perseorangan maupun
perusahaan kecil, namun perusahaan seperti Yahoo!, Google, Nokia, Youtube,
Wordpress juga menggunakan DBMS MySQL (Rosid, 2017).

7. MariaDB
MariaDB adalah sistem manajemen database relasional yang
dikembangkan dari MySQL yang dimaksudkan untuk tetap bebas di bawah
General Public License (GPL). Pengembangan dipimpin oleh beberapa orang
yang sebelumnya berkontribusi untuk MySQL, karena kekhawatiran atas akuisisi
oleh Oracle Corporation (Fadhilah et al., 2018).
MariaDB adalah DBMS hasil forking dari DBMSMySQL. Jadi syntax
query yang digunakan hampir sama. MariaDB menerapkan lisensi bebas
GNU/GPL. Nama MariaDB diturunkan dari nama putri ketiga Michael “Monty”
Widenius, pendiri Monty Program dan MySQL. MariaDB memiliki banyak fitur
yang sejak lama telah dipelihara komunitas sehingga menurut Monty seharusnya
sangat stabil. MariaDB telah mengganti InnoDB dengan XtraDB yang juga telah
mendapat perbaikan dari Google dan Percona.XtraDB diklaim secara signifikan
bisa jalan lebih cepat dibandingkan InnoDB, disamping ia juga bisa digunakan
tanpa perlu memasang Plugin seperti halnya pada MySQL. MariaDB
meningkatkan portofolionya dengan fitur “synchronous Multi Master
Replication”.Untuk itu, pengembang MariaDB telah mengimplementasikan
teknologi “Galera Cluster” yang dikembangkan oleh Codership dan ditanamkan
langsung di sistem pengelolaan basis data MariaDB.Solusi ini memungkinkan
replikasi terselaraskan (synchronous replication) dengan topologi Multi Master
(Satryawan, 2016).

8. MongoDB
MongoDB adalah basis data dokumen yang menyediakan performa tinggi dan
ketersediaan tinggi, skalabilitas yang mudah. MongoDB adalah sebuah basis data
open source yang banyak digunakan untuk menangani data yang besar. MongoDB
memberikan performa yang tinggi karena penggunaan indexing, aggregation, load
balancing, dan sebagainya.

7
 MongoDB mempunyai fitur-fitur sebagai berikut:
1) Document Oriented, MongoDB tidak mengambil dan memecah entitas
menjadi beberapa struktur relasional, tetapi MongoDB menyimpannya dalam
jumlah dokumen yang minimal.
2) Ad Hoc Queries, MongoDB mendukung pencarian berdasarkan field, range
queries, dan regular expression. Hasil dari query dapat berupa field-field
tertentu dari dokumen, termasuk penggunaan fungsi-
3) fungsi JavaScript.
4) Indexing, Setiap field di dokumen MongoDB dapat diberi indeks yang
menyediakan efisiensi dalam pencarian data.
5) Replication, MongoDB memberikan ketersediaan yang tinggi untuk
kumpulankumpulan replika. Sebuah replika berisi dua atau lebih salinan data.
6) Load Balancing, Skalabilitas MongoDB bersifat horizontal menggunakan
sharding. Pengguna memilih sebuah kunci shard, untuk menentukan
bagaimana data dalam sebuah koleksi akan didistribusikan.(Silalahi, 2018).

Document-oriented database adalah basis data dimana data disimpan dalam

bentuk dokumen yang biasanya dalam format XML, JSON maupun BSON. Sifat
dokumen yang semi terstruktur menyebabkan data tidak disimpan dalam bentruk
struktur tabel seperti pada relational database. Document-oriented database tidak
memiliki schema (schemaless) sehingga mampu menyimpan dokumen dalam
bentuk yang berbeda-beda. Hal tersebut membuat document-oriented database
sangat berguna untuk menyimpan data yang strukturnya dinamis dan mudah
berubah.(Setialana, Adji and Ardiyanto, 2017)

9. Web Server
Web server adalah perangkat lunak yang menjadi tulang belakang dari world
wide web (www). Web server menunggu permintaan dari client yang
menggunakan browser seperti Netscape Navigator, Internet Explorer, Mozilla,
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.(Riswandi, Kasim and Raharjo, 2020)
Web Server sistem operasi adalah penggunaan perangkat lunak untuk
memungkinkan satu perangkat keras untuk menjalankan beberapa sistem operasi
pada saat yang sama. software yang menyediakan layanan akses kepada user
melalui protokol komunikasi HTTP atau HTTPS atas berkas-berkas yang terdapat
pada suatu situs Web menggunakan aplikasi tertentu seperti Web Browser.
Penggunaan paling umum Server Web adalah untuk menempatkan situs Web,
namun pada prakteknya penggunaannya diperluas sebagai tempat peyimpanan
data ataupun untuk menjalankan sejumlah aplikasi.(Irza, Zulhendra and Efrizon,
2017)

10. Apache
Apache Web Server merupakan unix-based web server. Apache merupakan
web server yang paling populer dan banyak digunakan lebih dari 42% dari
berbagai domain website yang ada di internet. Apache pertama kali dikembangkan

8
 berbasiskode pada NCSA HTTPD 1.3 yang diprogram ulang menjadi sebuah web
server. Apache memiliki fitur yang sangat lengkap mulai dari performa yang
tinggi, fungsionalitas, efisiensi, serta kecepatan. Apache juga merupakan web
server berbasis open source.(Satwika and Semadi, 2020)
Apache merupakan web server yang bersifat open source yang digunakan
untuk melayani dan melakukan pengaturan fasilitas web, pada umumnya memiliki
fungsi untuk memperoleh berkas berisi permintaan (request) dari client melalui
web browser, kemudian apache akan memproses data tersebut dengan
menghasilkan keluaran (output) yang diinginkan oleh client. Ouput didapatkan
berdasarkan data yang tersimpan dalam database website tersebut. (Riswandi,
Kasim and Raharjo, 2020)

11. Nginx
Dalam situs resmi Nginx (Engine X) versi Bahasa Indonesia. Nginx (baca:
enjin eks) merupakan sender HTTP dan reverse proxy gratis berbasis open source
yang memiliki kemampuan tinggi. Nginx juga dapat digunakan sebagai proxy
IMAP/POP3. Perangkat lunak ini diciptankan oleh Igor Sysoev pada tahun 2002
dan dirilis untuk pertama kalinya secara umum pada tahun 2004.(Hutama Muliana
et al., 2018)
Awalnya Nginx dibangun di Rusia untuk memenuhi kebutuhan mesin pencari
skala besar Ramble yang tetap memanfaatkannya sampai sekarang. Berkat
berbagai kemampuan yang dimilikinya, termasuk kinerja yang tinggi dan
fleksibilitas dalam konfigurasi, Nginx banyak digunakan untuk mendukung
layanan web skala besar antara lain WordPress.com, SourceForge, Hulu,
ComputerBase.(Aziz and Tampati, 2015)

12. Browser Crome

Adalah browser yang dirilis oleh google pada tahun 2008, versi browser crome
terbaru saat ini adalah versi 96.0.4664.110 (Official Build), browser crome juga
extension loadfocus yang dapat di unduh secara gratis pada halaman extesnsion
dan berfungsi untuk merekam proses request pada halaman browser dan hasilnya
dapat di lakukan uji ulang pada aplikasi Apache Jmeter.

13. Apache Jmeter

Apache Jmeter adalah aplikasi open source berbasis Java yang dapat
dipergunakan untuk performance test. Bagi seorang QA Engineer jMeter bisa
digunakan untuk melakukan load/stress testing Web Application, FTP
Application dan Database server test.(Silalahi, 2018). Pada Jmeter terdapat
Summary Report yang merupakan salah satu jenis laporan yang disediakan oleh JMeter.

9
 Gambar 2.2 Summary Report pada Apache Jmeter
Pada tampilan summary report terdapat beberapa komponen, diantaranya :
• Name : Berupa judul atau nama dari summary report kita.
• Comments : Berupa catatan tambahan yang mungkin dimiliki oleh QA.
• Write results to file / Read from file : Kita dapat membaca hasil dari pengujian
yang sebelumnya sudah kita lakukan dengan browsing file dan hasil summary
report dari file itu akan ditampilkan pada tabel.
Laporan pada Summary Report memberikan beberapa informasi yang disajikan
dalam bentuk tabel dengan beberapa komponen, yaitu Label, Samples,
Average, Min, Max, Std.Dev., Error %, Throughput, Received KB/sec, Sent
KB/sec, dan Avg. Bytes.
• Label : Merupakan nama dari HTTP Request yang kita jalankan. Misalnya ada
dua request yang sedang kita jalankan secara bersamaan, dimana nama dari
masing-masing http request tersebut adalah Test-1 dan Test-2, maka Label dari
Summary Report tersebut ada Test-1 dan Test-2. Jelasnya dapat dilihat pada
gambar berikut.

Gambar 2.3 Label pada Apache Jmeter

• Samples : Jumlah total request yang dikirimkan ke server selama durasi
tes/pengujian.
• Average : adalah waktu rata-rata yang dihabiskan dalam mengeksekusi masing-
masing request (lebih kecil nilainya lebih baik). Dalam contoh gambar diatas,
average time dari label Test-1 adalah 17 milisekon dan label Test-2 adalah 323
milisekon, sehingga total average yang dihasilkan adalah (17+323)/2 = 170.
• Min : adalah waktu tersingkat yang dibutuhkan dalam mengeksekusi masing-
masing label. Dalam kasus kita, nilai min untuk label Test-1 adalah 8 milisekon
dan label Test-2 adalah 234, sehingga total min yang dihasilkan adalah 8
(diambil dari nilai min paling kecil dari masing-masing label).

10
 • Max : adalah waktu terpanjang yang dibutuhkan dalam mengeksekusi
masing-masing label. Dalam kasus kita, nilai max untuk label Test-1 adalah
282 milisekon dan label Test-2 adalah 713, sehingga total max yang
dihasilkan adalah 713 (diambil dari nilai max paling besar dari masing-
masing label).
• Std. Dev : Menunjukkan penyebaran kumpulan data relatif terhadap rata-
ratanya. Semakin kecil nilai dari std.dev menunjukkan bahwa data yang
dijalankan pada masing-masing label semakin konsisten. Nilai dari std.dev
sebaiknya lebih kecil atau sama dengan setengah dari nilai average dari
setiap label. Dari contoh kasus yang kita jalankan dapat kita tarik
kesimpulan bahwa data yang dijalankan pada label Test-2 masih lebih
konsisten dibanding data yang dijalankan pada label Test-1 karena pada
label Test-1 nilai std.dev > average, sedangkan di label Test-2, nilai std.dev
< average.
• Error % : Menunjukkan jumlah error dalam satuan persen yang terjadi pada
setiap label request. Dalam kasus pada, di label Test-1 dilihat bahwa jumlah
error nya 0%, sedangkan di label Test-2 sebesar 100%.
• Throughput : Menunjukkan jumlah request yang berhasil diproses per time
unit (second, minute, hours) oleh server. Waktu ini dikalkulasikan dari awal
sample pertama dijalankan sampai sample terakhir. Berbeda dengan std.dev,
semakin besar nilai throughput, semakin bagus. Dari contoh kasus yang kita
jalankan, di label Test-1 ada 4.6196489… request yang berhasil diproses
oleh server yang kita jalankan per second, dan di label Test-2 ada
4.5889101… (dibulatkan menjadi 4.6) request per second.
• Received KB/sec : Adalah jumlah data yang berhasil diunduh oleh server
selama dilakukannya eksekusi pengujian performance dalam satuan
kilobyte tiap 1 sekon.
• Sent KB/sec : Adalah jumlah data yang berhasil dikirim dari server selama
dilakukannya eksekusi pengujian performance dalam satuan kilobyte tiap 1
sekon.
• Avg Bytes : Adalah rata-rata byte yang berhasil diunduh (download) oleh
server.

14. LoadFocus
Adalah extension crome browser yang berfunsi untuk merekam semua proses
yang dilakukan pada browser dengan output .jmx sehingga selanjutnya dapat
dilakukan proses pengujian lebih lanjut dengan software Apache Jmeter. Berikut
adalah tampilan dari extension loadfocus :

11
 Gambar 2.4 LoadFocus

Versi terbaru LoadFocus saat ini adalah versi 1.1.1, ada beberapa macam
extension yang serupa dengan loadfocus tapi rata-rata semua berbayar, sedangkan
loadfocus saat ini masih menyediakan versi gratis, hanya saja kekurangan versi
gratis ini rekaman prosesnya hanya dibatasi sampai 1 menit saja.

12
2.3 Kajian Literatur
1) Analisis Web Server
NO Judul Tahun Proses Tools Hasil Analisis Sumber
1. Analisis Performansi 2019 Request Apache Hasil uji yang dilakukan pada kedua Jurnal Sistem
Antara Apache & Bench web server tersebut menujukan bahwa Dan
Nginx Web Server Nginx memiliki rata-rata waktu Informatika
dalam Menangani penyelesaian request yang lebih cepat (Jsi)
Client Request. dibandingkan dengan Apache. Hasil ini
(Chandra and Yakobus, didapatkan setelah proses
2019) pengujian dengan jumlah request mulai
dari 100 sampai 1000000 dengan
menggunakan tool Apache
Bench.
2. Perbandingan 2020 Response time Apache Kinerja web server dengan ISSN 2686-
Performansi Web & memory Benchmark menggunakan NGINX memiliki 6099 – SCAN
Server Apache Dan usage ing Tool performansi lebih baik dibandingkan VOL. XV
Nginx Dengan dengan APACHE. NOMOR 1
Menggunakan Ipv6.
(Satwika and Semadi,
2020)
3. Analisis Perbandingan 2018 Response Time, HTTPERF 1.Throughput web server Nginx lebih Jurnal Web
Kinerja Web Server Througput unggul dalam segi bandwidth pada file Informatika
Apache bertipe PHP. Sedangkan pada file Teknologi,
dan Nginx pada VPS gambar bertipe jpg, sebagian besar hasil Vol.3, No.1,
dengan Menggunakan pengujiannya menunjukkan bahwa Mei 2018
HTTPERF Nginx lebih unggul dalam segi
untuk bandwidth - nya.
Sistem Operasi CentOS 2.Throughput web server Apache lebih
(Hutama Muliana et al., unggul dalam segi bandwidth pada file
2018) bertipe HTML

13
4 Analisis Kinerja Web 2021 Througput website Dari hasil pengujian yang dilakukan Vol. XVI
Server Apache Dan meliputi pengujian throughput, Nomor 2 Juli
Litespeed Connection time, dan reply time dapat 2021 – Jurnal
Menggunakan Httperf ditarik kesimpulan bahwa kinerja web Teknologi
Pada Virtual Private server Apache lebih unggul jika dilihat Informasi
Server (VPS) dari hasil keseluruhan nilai throughput
(Yudhiastari, 2021) yang lebih besar dari web server
Litespeed. Sedangkan web server
Litespeed lebih unggul jika dilihat dari
hasil keseluruhan nilai Connection, dan
reply yang lebih kecil dari web server
Apache.
5. Performansi Web 2021 Request,respon Apache Dengan melihat hasil dari penelitian Ijns.org.
Server Apache dan se time Bench diatas, dapat diambil kesimpulan Indonesian
Nginx Pada bahwa web server Nginx lebih unggul Journal on
Aplikasi penjualan dalam hal pelayanan terhadap request Networking and
Online dari client dibandingkan dengan Security -
(Praba and Hariyanto, Apache dengan memiliki rata-rata Volume 9 No 3
2020) waktu proses lebih cepat. Hasil – Juni– 2020
ini diperoleh dari penelitian dengan
menguji jumlah request mulai dari 500
sampai dengan
50000 dengan menggunakan alat ukur
ApacheBench.
6. Analisis Web Server 2015 Time per Aplikasi analisis dari hasil pengujian tersebut Jurnal
untuk Pengembangan request, web ditemukan web server Apache memiliki multinetics vol.
Hosting Server Transfer rate, kinerja lebih baik dari pada web server 1 no. 2
Institusi: Pembandingan Connection Nginx, november 2015
Kinerja Web Server Times dimana kemungkinan pengguna web
Apache dengan Nginx server Apache belum mengetahui. Hal

14
 (Aziz and Tampati, tersebut bahwa web server Apache
2015) memiliki kecepatan transfer rate, time
per
request dan connection time lebih cepat
dibandingkan dengan Nginx, dimana
dengan nilai
transfer rata-rata dari Apache 701
Kbytes/sec sedangkan Nginx 522
Kbytes/sec
7. Analisa Kinerja Apache 2021 Response time, Arsitektur Berdasarkan hasil perhitungan rata-rata Jurnal Infra
dan Nginx dalam throughput microservic untuk response time dan throughput
Arsitektur e maka web server Apache lebih unggul
Microservice dibandingkan dengan web server
Menggunakan Siege Nginx, tetapi berdasarkan untuk jumlah
(Christopher, Unsong dari transaksi web server
and Andjarwirawan, Nginx lebih banyak daripada web
2021) server Apache
8 Analisis Perbandingan 2017 Throughput, httperf / Dari perbandingan pengujian Jurnal
Kinerja Web Server connection, siege throughput antara perangkat lunak http Vokasional
Apache dan Nginx request, reply Server apache dan nginx sebanyak Teknik
Menggunakan Httperf dan error empat kali pengujian didapatkan hasil Elektronika &
Pada Portal Berita dimana hasil dari throughput apache Informatika
(Studi Kasus memiliki kinerja yang lebih unggul dari
beritalinux.com) pada kinerja throughput nginx, dimana
(Irza, Zulhendra and bandwidth yang dihasilkan jauh lebih
Efrizon, 2017) baik sehingga mampu menampung
banyak data
9 Comparative 2017 Response time, hasil evaluasi kinerja implementasi web VNU Journal of
Performance Evaluation throughput, server ditinjau dari kinerja bottle neck Science: Comp.
of Web Servers request dan efisiensi penggunaan sumber daya. Science & Com.

15
 Dua percobaan telah dilakukan Eng., Vol. 31,
menggunakan Apache Bench dan No. 3 (2017)
Tsung dengan beban sangat tinggi. 28–34
Hasil eksperimen menunjukkan bahwa
NginX dapat mencapai tingkat
konkurensi hingga 42% dan hingga
200% lebih tinggi dari masing-masing
prefork NodeJS dan Apache. Hasilnya
juga mengungkapkan bahwa NginX
bisa mendapatkan throughput hingga
16% lebih tinggi dari Apache dalam
jangka panjang dengan volume beban
yang tinggi. Waktu respons NginX juga
dua kali lebih kecil daripada Apache.
10 Evaluasi Kinerja Web 2020 Response time, HTTP2 Dari hasil pengujian response time Journal of
Server Apache latency yang dilakukan, terbukti bahwa Engineering,
menggunakan Protokol kecepatan response time yang Technology &
HTTP2 dihasilkan HTTP/2 dalam mentransfer Applied Science
(Riswandi, Kasim and data lebih kecil dari pada HTTP/1. p-ISSN: 2721-
Raharjo, 2020) HTTP/2 menunjukkan performa 7949, e-ISSN:
kecepatan response time yang lebih 2721-8090
cepat jika diterapkan dalam web server
nginx dari pada menggunakan web
server apache.
Tabel 2.1 Kajian Literatur Web Server
Kesimpulan dari analisis beberapa jurnal tersebut dapat di ambil kesimpulan bahwa kinerja web server nginx diduga lebih baik
dari pada web server apache dan litespeed baik dari response time, memory usage maupun throughput.

16
 2) Analisis Backend Framework
N Judul Tahun Proses Tools Hasil Analisis Sumber
O
1 Studi Komparasi 2020 Load Test Hasil pengujian yang Conference on
Pengembangan Website didapatkan memiliki perbedaan yang Business, Social
Dengan tidak signifikan. Pengujian parameter Sciences and
Framework Codeigniter time pada Codeigniter sebesar 151,5 Innovation
Dan Laravel ms dan Laravel sebesar 147,3 ms. Technology,
(Prasena and Sama, Sedangkan pada pengujian paramater Unversitas
2020) speed, Codeigniter memilike speed Internasional
sebesar190,23 Kbit/s dan Laravel Batam
sebesar 150,15 Kbit/s.
2 Analisis Performasi 2017 Respontime, Web Stress 1. Aplikasi web yang menggunakan E-Proceeding Of
Framework Codeigniter Page size dan Tool framework CodeIgniter lebih baik Engineering :
Dan Laravel Speed dari sisi Vol.4, No.3
Menggunakan Web perfomasinya dibandingkan Desember 2017 |
Server Apache dengan aplikasi web yang Page 3565
(Performance Analysis menggunakan framewrok
Framework Codeigniter Laravel
And Laravel Using 2. Dari ukuran page size pada saat
Apache Web Server) pengujian load test, aplikasi web
(Eriton, Muldina Negara yang
and Sanjoyo Dwi, 2017) menggunakan framewoek Laravel
menghasilkan page size yang lebih
besar dan
berubah-ubah karena pada
framework Laravel meload lebih
banyak library dari
pada framework CodeIgniter,
maka mengakibatkan time yang

17
 dihasilkan
frameworok Laravel lebih besar.
3. Comparison Between 2018 Throughput debug bar Perbandingan kinerja antara Laravel International
Yii Frameworks And ,Memory dan Kerangka Yii2 yang telah kami Journal of
Laravel In Consumption , lakukan dalam makalah ini adalah Innovation in
3 Different Version For Execution berdasarkan waktu eksekusi, Enterprise
Viewing Large Data Of Time penggunaan memori puncak, dan System, Volume
Shipyard Industry In metrik throughput. Pengujian yang 2, Issue 01,
Indonesia dihasilkan menunjukkan bahwa dalam January 2018,
(Latif and Kusumasari, waktu eksekusi dan pengukuran pp. 13-18
2018) throughput, Laravel memberikan hasil
yang lebih baik dengan jumlah yang
sedikit berbeda.

4 A Comparative study of 2019 Request, Apache Dari hasi pegujian Laravel memiliki 2351-9789 ©
PHP frameworks Response time, Benchmark request terbanyak dalam waktu 1 detik 2019 The
performance Memory dari pada framework Symfoni dan Authors.
(Laaziri et al., 2019) Usage, Code Igniter, begitu juga pada Published by
Number of pengunaan memory dan respone time Elsevier Ltd.
Files Laravel lebih baik dari pada symfoni This is an open
dan Code Igniter access article
under the CC
BY-NC-ND
license
(https://creativec
ommons.org/lice
nses/by-nc-
nd/4.0/)
Selection and
peer-review

18
 under
responsibility of
the 12th
International
Conference
Interdisciplinarit
y in
Engineering.
10.1016/j.promf
g.2019.02.295
5. Performance benchmark 2015 findByPk, Excecution Analisis objektif menunjukkan bahwa International
of php frameworks with findByAttribute Speed rata-rata scientific journal
database s, findAll eksekusi metode di Codeigniter adalah "machines.
select methods yang tercepat, jadi kami menyatakan technologies.
(Janev, Delipetrev and materials. web
Ristova, 2015) Codeigniter sebagai pemenang. issn 1314-507x;
print issn 1313-
0226
6 Analisis Perbandingan 2020 Request, Page Browser Jumlah baris kode berorientasi fungsi, Expert, Jurnal
Bahasa Pemrograman Size website yang dibangun dengan Manajemen
Php Laravel menggunakan framework Laravel Sistem
Dengan Php Native Pada memiliki lebih banyak baris pada Informasi Dan
Pengembangan Website fungsi Teknologi
(Endra et al., 2021) dibandingkan dengan website yang
dibangun dengan PHP Native. Website
yang memakai framewok Laravel
memiliki tingkat ke-efesien-an
membuat sebuah fungsi kode program
yang lumayan tinggi dibandingkan
dengan PHP Native. Dikarenakan

19

7 Komparasi Penggunaan 2020
Framework Codeigniter
Vs Php Native
Pada Sistem Informasi
Manajemen Surat
Laravel telah menyediakan
berbagai library untuk mengeksekusi
program tersebut. Seperti pada
penggunaan ORM (Object Relation
Mapping) untuk pengeksekusian kode
program untuk mengelola basis data
sehingga pengguna waktu untuk
membuat program berkurang dan
mudah untuk di-maintenance. PHP
Native unggul dalam kecepatan dan
page size, ini
dikarenakan konten dan ukuran projek
pada Laravel jauh lebih banyak dan
besar dibandingkan dengan native.
Walaupun struktur folder pada PHP
Native jauh lebih flexible daripada
Laravel apabila dikerjakan sendiri,
tetapi untuk pengerjaan secara tim atau
kelompok Laravel lebih unggul, sebab
tempat dan struktur folder yang akan
digunakan sama dibandingkan dengan
Laravel. Tetapi pada struktur URL
yang digunakan pada Laravel jauh
lebih flexible dan mudah untuk diubah
pada routing
Connection Quisionair 1.Framework CodeIgniter lebih baik Jurnal SCRIPT,
Database, dibandingkan dengan PHP Native dari Vol. 8 No. 1
Request, segi performa dan lebih Juni 2020
Throughput direkomendasikan untuk digunakan
kepada user.
20
 Sekretariat Jurnal SCRIPT, Vol. 8 No. 1 Juni 2020
Dprd Pemalang E-ISSN:2338-63135
(Aditya, Erna and Dina, 2. Coding menggunakan CodeIgniter
2020) lebih tertata dalam Folder setiap
SubMenu yang akan
dilakukan coding.
3. PHP Native lebih simple dalam
pencodingan sistem ,ini dapat
direkomendasikan kepada
programer tingkat lanjut dan bukan
untuk kerja team,karena beberapa
variabel hanya
programer yang membuat sistem ini
sendiri yang tahu, jadi tidak cocok
apabila digunakan kerja
team
8 Analisis Perbandingan 2018 Respon Aplikasi Web service menggunakan framework Bangkit
Performa Web Service Time, Mobile Django diprediksi memiliki waktu Indonesia, Vol.
Rest CPU Android respon yang cepat, penggunaan CPU 2, No.VII,
Menggunakan Usage, dan Memori yang paling sedikit Oktober 2018
Framework Laravel, RAM sehingga penulis
Django Dan Ruby On Usage merekomendasikan kepada kampus
Rails STTI Tanjungpinang untuk
Untuk Akses Data membangun web service Portal E-
Dengan Aplikasi Mobile Kampus yang lebih lengkap,
(Saputra, 2018) mengintegrasikan semua proses bisnis
yang ada saat ini dengan menggunakan
web serviceframework Django.

21
9 Comparitive Study on 2020
Web Development using
core PHP & Laravel
Framework
(Kapoor, 2020)
10 Comparative Analysis 2018
Of Codeigniter And
Laravel In Relation To
Object-Relational
Mapping, Load Testing
And Stress Testing
(Ibrahim, Acquah and
Twum, 2018)
Performance The choice for which framework to International
select Laravel or Core PHP is depend Journal of
upon the client interest, but in terms of Advance
the performance of application laravel Science and
performed best as compare to core Technology
PHP. The speed of loading the page Vol.29,
of core PHP project is much faster No.10S,(2020),
than laravel because laravel has pp.2660-2663
triple layer function(Model, View,
Controller) for execute that taken
much time. Due to the inbuilt
libraries &packages developer always
prefer the laravel to develop E-
commerce Site.Laravel, so far one of
the most popular framework in 2019
because of its documentation &
MVC support with reliable database
Response time, Jmeter After carefully analysing the outcomes International
throughput from all testing environments, it is Research
evident that, generally CodeIgniter Journal of
performed significantly well on the Engineering and
local server with respect to throughput Technology
and response time, thus the null (IRJET)
hypothesis is rejected for the local set
up. Performance difference on a live
set up is not very significant although
CodeIgniter still performed better in
smaller load conditions but there was
an
Tabel 2.2 Kajian Literatur Backend Framework
22
 Kesimpulan dari beberapa jurnal tersebut dapat di ambil kesimpulan framework code igniter memiliki response time lebih
cepat dari Laravel,django dan yang lainnya. Namun native atau tanpa framework juga lebih cepat dibandingkan dengan
mengunakan framework Laravel atau code igniter.

3. Analisis Database SQL dan No SQL (RDBMS dan Document Oriented)

NO Judul Tahun Proses Tools Hasil Analisis Sumber
1. Perbandingan 2018 CRUD, respon Ketika menyimpan file-file berukuran CBIS
Performansi Database time besar, penggunaan processor dan JOURNAL -
Mongodb Dan Mysql konsumsi memori tidak berbeda jauh VOL. 06 NO.
Dalam Aplikasi File antara MongoDB dan MySQL. Hanya saja 01 (2018) :
Multimedia Berbasis pemakaian memori virtual MARET
Web MongoDB jauh lebih tinggi daripada
(Silalahi, 2018) MySQL.
Dari segi kecepatan, rata-rata MongoDB
lebih cepat 2,48 kali daripada MySQL
2. Studi Perbandingan 2016 Response time Xampp, Dalam studi perbandingan ini didapatkan ISBN : 979-
Performansi Antara web hasil response time untuk masing masing 587-626-0 |
MongoDB browser database, mongoDB menunjukkan UNSRI,
dan MySQL Dalam performansi yang baik dengan response Prosiding
Lingkungan Big Data time 12.83624 detik, MySQL ANNUAL
(Junaidi, 2016) menunjukkan response time 70.584384 RESEARCH
detik dengan 226.232 record untuk SEMINAR
masing masing database. 2016
6 Desember
2016, Vol 2
No. 1

23
3. Perbandingan 2017 Response time Dari hasil uji coba yang dilaksanakan JURNAL
Kemampuan Database mongodb mmiliki permoance lebih baik TEKNIK ITS
nosql dari pada Mysql yakni memiliki respon Vol. 6, No. 2
dan SQL dalam Kasus yang lebih cepat baik untuk proses (2017), 2337-
ERP Retail CRUD maupun agregation 3520 (2301-
(Bhaswara, Sarno and 928X Print)
Sunaryono, 2017)
4. Analisis Perbandingan 2020 Response time Pada penelitian ini dapat disimpulkan (Jurnal
Performansi Waktu bahwa database NoSQL MongoDB Teknologi
Respons Kueri terbukti lebih unggul dalam setiap Informasi)
Antara Mysql Php transaksi query yang diujikan Vol.4, No.2,
7.2.27 Dan Nosql dibandingkan dengan MySQL, namun Desember
Mongodb lemah dalam pemrosesan transaksi query 2020
(Bhaswara, Sarno and untuk menampilkan data dengan jumlah
Sunaryono, 2017) selisih runtime 1,95s. Penelitian ini
membuktikan database NoSQL mampu
memenuhi pemrosesan kebutuhan data
yang besar dengan kecepatan waktu
respond query yang optimal dan terbukti
memiliki lebih banyak keunggulan
dibanding database MySQL.
5. Perbandingan Performa 2021 CRUD Dalam semua proses baik proses IJCIT
SQL dan Nosql Dengan select,insert,update maupun delete (Indonesian
PHP mongodb menunjukan memiliki respon Journal on
Pada 5 Juta Data yang lebih cepat dari pada Mysql Computer
(Budiman et al., 2021) and
Information
Technology)
6 (1) (2021)
38-42

24
6. Analisa Perbandingan 2021 CRUD Aplikasi Query read data pada nosql database ResearchGate
Kemampuan Database web memiliki response times yang paling cepat
NoSQL dan SQL dibanding query untuk proses create,
(Salsabila et al., 2021) update dan delete. Query update data pada
nosql database memiliki response times
yang paling
lama dibanding query untuk proses create,
read dan delete. Sedangkan Query delete
data pada nosql database memiliki
response times yang lebih cepat dibanding
query create data. Perbandingan query
response times dari beberapa software
NoSQL database merupakan salah satu
topik yang dapat dikembangkan pada
penelitian selanjutnya.
7. Analisis Perbandingan 2020 CRUD fungsi PHP Berdasar pada hasil penelitian yang Jurnal
Unjuk Kerja Database microtime dilakukan diperoleh bahwa waktu Nasional
SQL dan Database eksekusi database Redis lebih cepat dari Teknik
NoSQL Untuk database MySql untuk melakukan operasi Elektro, Vol.
Mendukung Era Big dasar yaitu create, read, delete dan update. 9, No. 3,
Data Peningkatan kecepatan waktu eksekusi November
(Fadli et al., 2020) tersebut sebesar 87.58% pada operasi 2020
create, 85.53% pada operasi update, dan
pada operasi delete sebesar 86.40% dan
sedangkan pada operasi read penigkatan
kecepatan waktu eksekusi diperoleh
sebesar 57.09%, sehingga secara rata-rata
Database Redis memiliki untuk kerja yang
lebih baik dari Database MySQL yaitu
sebesar 79.15%.

25
8 Perbandingan Performa 2017 Average Time Node.js Pengujian performa terhadap relational Seminar
Relational, Document- javascript database (PostgreSQL), document- Nasional
Oriented dan Graph runtime oriented database (MongoDB) dan graph Teknologi
Database Pada Struktur environment database (Neo4j) pada data genealogy Informasi
Data Directed Acyclic dengan struktur directed acyclic graph dan
Graph.(Setialana, Adji (DAG) menghasilkan data bawa Multimedia
and Ardiyanto, 2017) PostgreSQL memiliki performa dan 2017
kecepatan yang lebih baik dalam operasi
menyimpan (single write syncrhonous)
yaitu sebesar 0.64 ms maupun membaca
data (single read) yaitu sebesar 0.32 ms
dibandingkan MongoDB yaitu 5.29 ms
pada operasi single write syncrhonous dan
4.59 ms pada operasi single read.
Sedangkan Neo4j memiliki performa
paling buruk pada operasi single write
synchronous yaitu sebesar 9.92 ms dan
operasi single read yaitu sebesar 8.92 ms
9 Benchmarking Mysql 2019 response time, Benchmark MongoDB memiliki Response time lebih Journal Of
And Nosql Database throughput, Metrics cepat dibandingkan Mysql dan troughput Information
ON Egovbench backup and namun paling besar dalam storage Technology
Application storage, And Its
(Rakhmawati et al., volume. Utilization,
2019) Volume 2,
Issue 1, June-
2019:18-23
10 A Comparison of 2016 CRUD time As amount of data is increasing, time International
MySQL and MongoDB taken by MySQL to perform operations is Research
Databases also increasing . Above tables and charts Journal of
clearly shows that MySQL is not able to Engineering

26
 (Rakhmawati et al., handle large amount of data that’s why and
2019) MongoDB is preferred over MySQL. Technology
(IRJET)
Tabel 2.3 Kajian Literatur Database

Kesimpulan dari hasil analisis beberapa jurnal diatas bahwa diduga kinerja database MongoDB lebih cepat dari pada database
RDBMS baik Mysql,PostgreSQL maupun database RDBMS lainnya dalam response time, throughput dan dalam terutama
penanganan big data.

27
2.4. Hipotesis
Hipotesis dari kajian literatur beberapa referensi adalah “Diduga dengan
aplikasi baru yang
database MongoDB dan Web Server Nginx dapat meningkatkan kecepatan
response time aplikasi Administrasi Pondok Pesantren Sumber Barokah”.

2.5. Kerangka Pemikiran

Kerangka berpikir merupakan model konseptual tentang bagaimana teori
berhubungan dengan berbagai faktor yang telah diidentifikasi sebagai hal yang
penting (Setiawan and Kurniasih, 2020). Pada kerangka pemikiran ini dilakukan
normalisasi terlebih dahulu sebelum melakukan pengujian kecepatan respon time
dari masing-masing RDBMS yaitu Mysql, Postgresql maupun mariadb. Berikut
adalah bagan kerangka pemikiran :

Aplikasi Analisis Perancangan &

Lama Kebutuhan Pengembangan Pengujian
Aplikasi

Evaluasi
&
Perbaikan

Aplikasi
Baru

Gambar 2.5 Bagan Kerangka Pemikiran

28
 BAB III
METODOLOGI DAN RANCANGAN PENELITIAN
3.1 Metode Penelitian
3.1.1 Metode Pengumpulan Data
Metode yang digunakan untuk pengumpulan data adalah metode
telaah dokumen, wawancara dan observasi langsung.

3.1.2 Metode Pengembangan Sistem

Metode yang digunakan pada ini adalah penelitian pengembangan
perangkat lunak Sistem Develompent Life Cycle (SDLC) dengan
Prototype Model. Sedangkan untuk Perancangan sistemnya penulis
menggunakan metode prototyping .Prototyping merupakan proses yang
digunakan untuk membantu pengembangan perangkat lunak dalam
membentuk model perangkat lunak (Syarif, 2018). Prototype ini adalah
versi awal dari sebuah tahapan sistem perangkat lunak yang digunakan
untuk mempresentasikan gambaran dari ide, mengeksperimenkan
sebuah rancangan, mencari masalah yang ada sebanyak mungkin serta
mencari solusi terhadap penyelesaian masalah tersebut. Model
prototype yang dipergunakan oleh sistem akan mengijinkan pengguna
mengetahui seperti apa tahapan sistem yang dibuat sehingga sistem
dapat mampu beroperasi secara baik.
3.1.3 Metode Penelitian
Pada pengujian penelitian ini, metode yang akan dipakai adalah
menggunakan metode penelitian komparatif kuantitatif. Metode
komparatif bertujuan untuk membandingkan keberadaan suatu variable
atau lebih, pada dua atau lebih sampel yang berbeda, atau pada waktu
yang berbeda (Satryawan, 2016). Penelitian ini membandingkan
kecepatan aplikasi dalam memproses data pada transaksi Administrasi
Pondok dengan aplikasi yang adas sebelumnya.

3.2 Tempat dan Waktu Penelitian

Penelitian ini dilaksanakan di Pondok Pesantren Sumber Barokah
Karawang. Waktunya disesuaikan dengan jadwal pelayanan administrasi Pondok
sumber barokah karawang yaitu pukul 08.00 s/d 17.00 wib.

3.3 Tahap Analisis Kebutuhan

3.3.1 Menganalisis Sistem Lama
Tahapan ini menganalisis dan mempelajari alur aplikasi lama terutama
yang terkait dengan menu administrasi atau keuangan pondok pesantren. Selain
itu juga menganalisis faktor-faktor yang menyebabkan lambatnya aplikasi
administrasi yang sedang berjalan.
Sedangkan aplikasi lama yang digunakan dalam pengujian adalah dengan
spesifikasi sebagai berikut:
• Bahasa Pemograman : PHP(5.4) dan Javascript
• Framework Backend : JqGrid
• Template : Native
• Database : Mysql/10.1.38-MariaDB

29
 • Web Server : Apache versi 2.4.38
• Tool : Xampp v3.2.3

3.3.2 Menganalisis Kebutuhan Sistem baru

Tahapan ini menganalisis apa saja kebutuhan yang akan di design
pada sistem yang baru yatu dengan dilakukannya wawancara kepda
sejumlah user diantaranya : teller, kepala bagian keuangan dan
manager.
Instrumen penelitian adalah alat ukur yang digunakan dalam
penelitian. Sedangkan Instrumen penelitian menurut Arikunto
(2013:203), alat atau fasilitas yang digunakan dalam penelitian untuk
mengumpulkan data agar pekerjaanya lebih mudah, hasilnya lebih
baik sehingga data penelitian mudah diolah. Dari pendapat diatas
dapat disimpulkan bahwa instrumen penelitian adalah alat ukur
penelitian untuk mengumpulkan data penelitian sehingga
mempermudah dalam mengolah data penelitian (Abidin and
Purbawanto, 2015).
Salah satu ciri penelitian kualitatif adalah peneliti bertindak
sebagai instrumen sekaligus pengumpil data. Instrumen selain
manusia (seperti; angket, pedoman wawancara, pedoman observasi
dan sebagainya) dapat pula digunakan, tetapi fungsinya terbatas
sebagai pendukung tugas peneliti sebagai instrumen kunci. Oleh
karena itu dalam penelitian kualitatif kehadiran peneliti adalah
mutlak, karena peneliti harus berinteraksi dengan lingkungan baik
manusia dan non manusia yang ada dalam kancah penelitian.
Kehadirannya di lapangan eneliti harus dijelaskan, apakah
kehadirannya diketahui atau tidak diketahui oleh subyek penelitian.
Ini berkaitan dengan keterlibatan peneliti dalam kancah penelitian,
apakah terlibat aktif atau pasif (Murni, 2017). Berikut adalah tabel
instrumen interview :

NO Menu Hak Akses Perbaikan/

Pengembangan
1 Login
2 CRUD Data Siswa/i
3 Tabungan
4 Pembayaran
5 Laporan Tabungan
6 Laporan Pembayaran
7 Koreksi Pembayaran
Tabel 3.1 Tabel Instrumen Interview

3.4 Tahap Rancangan dan Desain Sistem

Aplikasi yang dibuat adalah aplikasi yang dirancang berdasarkan analisis
kepada beberapa kajian literarur dan juga dengan beberapa pengguna dan
pimpinan, sehingga menjadi aplikasi baru yang diharapkan memiliki response
time lebih cepat, lebih stabil dan memiliki menu yang sesuai dengan

30
 kebutuhan, karena pada aplikasi lama terdapat beberapa menu yang sudah
tidak diperlukan. Aplikasi
yang dirancang dengan spesifikasi sebagai berikut:

• Bahasa Pemograman : PHP(7.4) dan Javascript

• Framework Frontend : Bootstrap 4
• Framework Backend : Native
• Template : AdminLte v3.2.0-rc
• Database : MongoDB v5.0.4
• Web Server : Nginx/1.20.2

3.5 Tahap Skenario Pengujian

Sebelum Pengujian dilakukan diperlukan skenario pengujian terlebih
dahulu diantaranya :
1). Menentukan halaman atau menu proses yang akan di uji dengan jumlah
user tertentu. Pada tahapan ini akan dilakukan beberapa tahapan pengujian dan
dilakukan dengan jumlah user dari 1 sampai 30 user.

NO Proses Jumlah User

1 Proses Login 1,5,10,15,20,25,30
2 Proses CRUD Data Siswa/i 1,5,10,15,20,25,30
3 Proses Transaksi Tabungan 1,5,10,15,20,25,30
4 Proses Transaksi Pembayaran 1,5,10,15,20,25,30
5 Proses Laporan Tabunan 1,5,10,15,20,25,30
6 Proses Laporan Pembayaran 1,5,10,15,20,25,30
Tabel 3.2 Tabel Skenario Pengujian

2). Eksport database existing

Database yang akan diuji dieksport terlebih dahulu dengan format
.json. untuk mengubah database MariaDB ke dalam bentuk .json diperlukan
aplikasi atau script sederhana dengan PHP.

3). Import database ke dalam Mongodb.

Setelah di eksport file database .json di import pada mongodb
selanjutnya dilakukan konfigurasi koneksi ke dalam aplikasi baru.

31
 Gambar 3.1 Import database pada MongoDB
3.6 Tahapan Pengujian
Pengujian dilakukan dengan menggunakan browser crome, tool Apache
Jmeter dan LoadFocus yang merupakan extension browser crome. Tahapan
pengujian dilakukan pada beberapa Tahapan proses yaitu :
1) Tahapan Proses Login
2) Tahapan Proses CRUD Data Siswa/i
3) Tahapan Proses Transaksi Tabungan
4) Tahapan Proses Transaksi Pembayaran
5) Tahapan Proses Laporan Tabungan
6) Tahapan Proses Laporan Pembayaran

Instrumen pengujian terdari dari kolom jumlah request, waktu rata-rata

setiap request (Average) dan jumlah data yang di download serta di kirim oleh
server, tabel untuk pengujian dapat dilihat pada table berikut :

N Proses Requ Average Through Received/sent Error U

O est (ms) put (KB/Sec) (%) se
(/sec) Received Sent r
1 Login
2 CRUD data
Siswa/i
3 Transaksi
Tabungan
4 Transaksi
Pembayaran
5 Laporan
Tabugan
6 Laporan
Pembayaran
Tabel 3.3 Tabel Instrumen Pengujian

32
3.7 Evaluasi Sistem
Tahap evaluasi ini pengguna melakukan evaluasi untuk memastikan
apakah program atau sistem yang sudah dibangun sudah sesuai dengan
keinginan atau belum. Apabila telah sesuai maka sistem sudah dapat
digunakan. Tapi apabila dinyatakan belum sesuai maka pengembang harus
kembali ketahap sebelumnya untuk memperbaiki sesuai dengan keinginan
pengguna.

33
 BAB VI
PEMBAHASAN HASIL PENELITIAN

Pada penelitian aplikasi yang berjalan sebelumnya ditemukan beberapa

penyebab lambatnya aplikasi ini berjalan. Dianataranya adalah :
1. Banyak query yang sudah tidak terpakai tapi masih berjalan.
2. Terdapat cukup banyak join yang dilakukan antar table database.
3. Terdapat cukup banyak request dalam satu proses (dapat dikarenakan
tedapat beberapa library).
4. Terdapat file atau atau request yang tidak dapat diproses.

4.1 Hasil Wawancara

NO Menu Hak Akses Perbaikan/Pengembangan
1 Login Teller Dibuat Sederhana
2 CRUD Data Kesiswaan, Admin, Tambah Data : Nama
Siswa/i Teller Lengkap, Jenis kelamin,
KBM, Tempat Lahir,
Tanggal Lahir, HP, PDD
Terakhir, Alamat, Tanggal
Masuk.
Edit Data : NIS, NIK,
No.KK,NISN, No. KIP,
No.PKH, No.KKS, Nama
Lengkap, Jenis kelamin,
KBM, Kelas Sekolah, Kelas
Ngaji, Kamar, Tempat Lahir,
Tanggal Lahir, HP, PDD
Terakhir, Alamat, Anak Ke,
Jumlah Saudara, Status Anak,
Prestasi/Hobi/Keterampilan,
Status Siswa (Data Siswa).
Nama Ayah, NIK Ayah,
Status Ayah, Alamat Ayah,
HP Ayah, PDD Ayah,
Pekerjaan Ayah, Nama Ibu,
NIK Ibu, Status Ibu, Alamat
Ibu, HP Ibu, PDD Ibu,
Pekerjaan Ibu.
Untuk Teller :hanya bisa
update status siswa menjadi
aktif atau izin saja
3 Tabungan Teller, Admin Font untuk input Jumlah
dipertebal, dan diberiwarna
seperti aplikasi lama.
4 Pembayaran Teller, Admin, Biaya :
Kepala Bagian Peralatan dapur -> 40.000
Olahraga -> 50.000
Loker -> 100.00

34
 Kesehatan -> 50.000
ID Card -> 20.000
Lainnya -> 0
5 Laporan Teller, Admin, Dibuatkan tombol export
Tabungan Kepala Bagian excel
6 Laporan Teller, Admin Dibuatkan tombol export
Pembayaran excel
7 Koreksi Admin, Kepala Dibuatkan history koreksi
Pembayaran Bagian data
Tabel 4.1 Tabel Hasil Wawancara

Pada menu CRUD data siswa user teller hanya dapat mengupdate data siswa/i
saja dan pilihanya hanya aktif dan izin, teller dapat merubah status menjadi izin
apabila telah melunasi biaya SPP pada bulan tersebut.

4.2 Use Case Diagram

Dari hasil interview maka dapat di deskripsikan interaksi antara si pengguna
dengan sistemnya aplikasi yang baru seperti berikut :

Melakukan
Transaksi
Tabungan

Melakukan
Transaksi
Pembayaran

Teller <<includes>>
Melihat Laporan <<includes>>
Tabungan
<<includes>>
Login
Admin
Melihat Laporan <<includes>>
Pembayaran

<<includes>>
Kepala
Bagian
Update Status
<<includes>>
Siswa/i

Koreksi
Pembayaran

Gambar 4.1 Use Case Diagram

35
 Pada diagram diatas terlihat bahawa semua proses dapat dilakukan oleh user
manapun tentunya harus login terlebih dahulu. User Teller dapat mengakses semua
menu kecuali menu koreksi pembayaran dan pada menu CRUD Data Siswa/i hanya
dapat mengupdate status saja. Sedangkan user Kepala Bagian hanya dapat
melakukan koreksi pembayaran dan melihat laporan transaksi baik tabungan
maupun pembayaran.

4.3 Activity Diagram

1) Activity Diagram Login

Gambar 4.2 Activity Diagram Login

Pada activity diagram diatas dapat dilihat bahwa user dapat masuk
ke halaman utama dashboard dengan cara login terlebih dahulu, apabila user
tidak tepat dalam memasukan username atau password maka akan tampil
dialog kesalahan, apabila user benar dalama memasukan username dan
password maka dapat masuk kedalam halaman utama dashboard.

36
2) Activity Diagram CRUD Data Siswa/i

Gambar 4.3 Activity Diagram CRUD Data Siswa/I

untuk Admin
Pada activity diagram diatas ketika user admin memilih menu data
siswa/i maka akan langsung tampil data siswa/i, pada menu tersebut terdapat
3 buah tombol. Ketika user admin menekan tombol tambah data maka akan
muncul form pengisian data siswa/i, setelah selesai maka user akan
menekan tombol simpan dan akan muncul notifikasi terutama untuk
beberapa isian yang bersifat harus diisi(required). Apabila belum maka
akan kembali ke form pengisisan dengan menfokuskan pada isiin yang
belum diisi, apabila sudah lengkap maka data akan tersimpan kedalam
database. Ketika user admin menekan tumbol Edit maka akan muncul form
edit data, ketika telah selesai lalu user menekan tombol simpan maka akan
muncul notifikasi isiian data khususnya yang harus diisi(required) apabila
sudah semua maka data akan terupdate. Selanjutnya ketika user menekan
tombol hapus, maka akan muncul konfirmasi berupa dialog/pop up yang
berisikan pesan konfirmasi “apakah anda yakin?” apabila tekan tombol batal

37
 maka proses hapus akan dibatalkan, apabila menekan tombol OK maka
proses hapus data akan diproses.

Gambar 4.4 Activity Diagram CRUD Data Siswa/I

untuk Teller
Sedangkan untuk user teller ketika memilih menu data siswa/i akan
muncul tampilan data siswa/i dengan satu tombol edit saja danhanya dapat
melakukan edit status siswa/i yaitu Aktif. Perihal ini ditujukan agar user
teller dapat membantu mengaktifkan siswa/i yang telah berada dipondok
namun statusnya masih izin atau belum aktif.

3) Activity Diagram Transaski Tabungan

38
 Gambar 4.5 Activity Diagram Transaksi Tabungan

Pada activity diagram diatas ketika user admin atau teller memilih
menu transaksi tabungan maka akan muncul tampilan transaksi tabungan,
kemudian untuk melakukan transaksi user harus memilih siswa terlebih
dahulu kemudian melakukan transaksi tabungan diantaranya berisi setoran,
penarikan, dan transferan. Setelah melakukan transaksi data akan terinsert
kedalam database kemudian baru user dapat mencetak ke buku tabungan
siswa/i.

39
4) Activity Diagram Transaksi Pembayaran

Gambar 4.6 Activity Diagram Transaksi Pembayaran

Pada activity diagram diatas ketika user admin atau teller memilih
menu transaksi pembayaran maka akan muncul tampilan transaksi
pembayaran, kemudian untuk melakukan transaksi user harus memilih
siswa terlebih dahulu kemudian melakukan transaksi pembayaran
diantaranya berisi pembayaran Kost Pondok, Shodaqoh olahraga,
perawatan loker, shodaqoh dapur, kesehatan, ID Card dan pembayaran
lainnya. Setelah melakukan transaksi data akan terinsert kedalam database
kemudian baru user dapat mencetak stuk bukti pembayaran.

40
5) Activity Diagram Laporan Tabungan

Gambar 4.7 Activity Diagram Laporan Tabungan

Pada activity diagram diatas ketika user admin, teller, atau kabag
memilih menu laporan tabungan maka akan muncul tampilan laporan
tabungan, selanjutnya user dapat memilih operator yang melakukan
transaksi dan tanggal transaksi awal sampai tanggal transaksi akhir
transaksi, setelah itu data akan dapat dicetak atau di print secara langsung
atau dapat di export kedalam bentuk excel dengan xls.

6) Activity Diagram Laporan Pembayaran

41
 Gambar 4.8 Activity Diagram Laporan Pembayaran

Pada activity diagram diatas ketika user admin, teller, atau kabag
memilih menu laporan pembayaran maka akan muncul tampilan laporan
pembayaran, selanjutnya user dapat memilih operator yang melakukan
transaksi dan tanggal transaksi awal sampai tanggal transaksi akhir
transaksi, setelah itu data akan dapat dicetak atau di print secara langsung
atau dapat di export kedalam bentuk excel dengan xls.

7) Activity Diagram Koreksi Pembayaran

42
 Gambar 4.9 Activity Diagram Koreksi Pembayaran

Pada activity diagram diatas ketika user admin, atau kabag memilih
menu koreksi pembayaran maka akan muncul tampilan koreksi
pembayaran, selanjutnya user diharuskan memilih data siswa/i terlebih
dahulu, kemudian pilih salah satu transaksi yang akan dibatalkan, setelah
itu user dapat melakukan perbatalan pada transaksi tersebut dan data
tersebut akan terupdate kedalam database. Apabila transaksi telah
dibatalkan maka transaksi tersebut tetap muncul pada menu teller hanya saja
truk pembayaran tersebut sudah tidak dapat lagi di cetak.

4.4 Design User Interface

Berikut merupakan beberapa rancangan desain user interface Aplikasi Baru
Pondok Pesantren Sumber Barokah.
1) Halaman Login

43
 Gambar 4.10 Halaman Login
Halaman login dibuat dengan sederhana dengan tampilan logo
pondok pesantren sumber barokah karawang. Untuk form pengisiannya
hanya berisi input username, input password dan tombol login saja.

2) Halaman CRUD Data Siswa/i

Gambar 4.11 Halaman CRUD Data Siswa/i

Pada halaman data siswa/i terdapat tombol untuk tambah, edit dan
delete data dengan menggunakan popup bootstrap, sedangkan untuk delete
data akan muncul alert (menggunakan sweetalert) untuk mengkonfirmasi
apakah benar akan menghapus data.

44
3) Halaman Transaksi Tabungan

Gambar 4.12 Halaman Transaksi Tabungan

Pada halaman transaksi tabungan, terdapat pilihan transaksi yaitu

setoran, penarikan dan transferan. Pada input jumlah diberikan border-color
untuk membedakan jenis transaksi dan mengurangi kesalahan transaksi oleh
pengguna (human error).

4) Halaman Transaksi Pembayaran

Gambar 4.13 Halaman Transaksi Pembayaran

45
 Pada halaman transaksi pembayaran terdapat beberapa jenis
pembayaran diantaranya pembayaran kost pondok, shodaqoh peralatan
dapur, perawatan loker, shodaqoh olahraga, Kesehatan, ID Card, dan
pembayaran lainnya.

5) Halaman Laporan Tabungan

Gambar 4.14 Halaman laporan Tabungan

6) Halaman Laporan Pembayaran

Gambar 4.15 Halaman Transaksi Pembayaran

46
 Pada halaman laporan tabungan terdapat pilihan sort by date,
terdapat juga tombol cetak dan tombol export to excel untuk memudahkan
pengguna dalam rekap data.

7) Kopreksi Pembayaran

Gambar 4.16 Halaman Koreksi Pembayaran

Pada halama laoran keuangan hamper sama seperti halaman laporan

pembayaran yaitu terdapat pilihan sort by date, tombol cetak dan tombol
export to excel untuk memudahkan pengguna dalam rekap data.

4.5 Pengujian dengan Apache Jmeter

Pengujian ini dilakukan dengan menggunakan browser crome versi
96.0.4664.110 (Official Build) (64-bit) dan LoadFocus versi 1.1.1 sebagai
extension browser crome yang dapat merekam proses pengujian. Hasil
pengujian dapat di download dengan format .jmx sehingga selanjutnya dapat
dilakukan pengujian pada Apache Jmeter (versi 5.4.1). Dengan LoadFocus
maka pengujian yang dilakukan dengan Apache Jmeter tidak perlu lagi
melakukan setting path, karena semua sudah terekam kedalam 1 file .jmx
1) Hasil Pengujian Proses Login
• Aplikasi Lama

NO Proses Request Average Throughput Received/sent Error User

(ms) (/sec) (KB/Sec) (%)
Received Sent
1 46 84 11,8 454,62 7,90 0 1
2 230 341 12,9 494,12 8,59 0 5
3 Proses 460 689 12,4 476,07 8,27 0 10
4 Login 690 1010 12,9 494,19 8,59 0 15
5 920 1473 11,8 452,62 7,86 0 20
6 1150 1868 11,7 447,93 7,78 0 25

47
7 1380 2165 12,0 461,47 8,02 0 30
Tabel 4.2 Hasil Pengujian Login Aplikasi Lama

Dari Hasil pengujian Proses login pada aplikasi lama, untuk proses
login dengan 1 pengguna didapatkan 46 request dengan kecepaan rata-rata
setiap requestnya adalah 84 ms, dengan throughput atau request yang berhasil
diproses tiap detik adalah 11,8. Sedangkan data yang berhasil di unduh oleh
server tiap detiknya adalah 454,62 KB dan server dapat mengirim data 7,90 Kb
setiap detiknya. Dari pengujian dengan 1 pengguna sampai 30 pengguna proses
login ini berjalan dengan cukup stabil meningkat sesuai dengan banyaknya
jumlah pengguna dan dengan tingkat kegagalan proses 0%.

• Aplikasi Baru
NO Proses Request Average Throughput Received/sent Error User
(ms) (/sec) (KB/Sec) (%)
Received Sent
1 47 2 367,2 39.907,21 249,26 0 1
2 235 3 246,3 26.772,13 167,22 0 5
3 470 1 459,9 49.981,63 312,18 0 10
Proses
4 705 1 692,5 75.267,04 470,12 0 15
Login
5 940 1 917,1 99.670,70 622,54 0 20
6 1175 1 1047,2 113.817,36 710,90 0 25
7 1410 1 1330,2 144.569,52 902,98 0 30
Tabel 4.3 Hasil Pengujian Login Aplikasi Baru

Dari Hasil pengujian Proses login pada aplikasi baru, untuk proses login
dengan 1 pengguna didapatkan 47 request dengan kecepaan rata-rata setiap
requestnya adalah 2 ms (82ms lebih cepat dari pada aplikasi lama), dengan
throughput atau request yang berhasil diproses tiap detik adalah 367,2(355,4
lebih banyak dari pada aplikasi lama). Sedangkan data yang berhasil di unduh
oleh server tiap detiknya adalah 39907,21 KB (39.452,59 KB lebih banyak dari
pada apalikasi lama) dan server dapat berhasil mengirim data 249,26 Kb setiap
detiknya (241,36 KB lebih banyak dari aplikasi lama). Dari pengujian dengan
1 pengguna sampai 30 pengguna proses login ini berjalan dengan cukup stabil
namun ada kegagalan proses request sebesar 0%.

48
 Gambar 4.17 Diagram Pengujian Login Aplikasi
Lama dan Baru
Dari hasil kedua pengujian dengan 1 pengguna sampai 30 pengguna
didapatkan bahwa proses login pada aplikasi baru memiliki respon time yang
lebih cepat dari pada proses login pada aplikasi lama, dengan perbandingan
kecepatan 82 – 2.164 ms lebih cepat, dan 234,6 – 1.034,3 lebih banyak request
yang berhasil di proses.
Dari chart atau diagram diatas terlihat perbandingan antara keduanya
cukup signifikan, namun keduanya cukup stabil dengan tingkat kegagalan 0%.

2) Hasil Pengujian CRUD Data Siswa/i

• Aplikasi Lama
NO Proses Request Average Throughput Received/sent Error User
(ms) (/sec) (KB/Sec) (%)
Received Sent
1 129 18 50,3 738.51 34.48 0 1
2 645 39 115,7 1701,86 79,35 0 5
3 CRUD 1290 73 128,7 1893,60 88,29 0 10
4 Data 1935 112 128,5 1889,64 88,11 0 15
5 Siswa/i 2580 164 118,2 1738,02 81,04 0 20
6 3225 188 128,5 1904,20 88,79 0 25
7 3870 228 128,8 1895,17 88,37 0 30
Tabel 4.4 Hasil Pengujian CRUD Data Siswa/I
Aplikasi Lama

49
 Dari hasil pengujian proses CRUD data siswa/i pada aplikasi lama,
untuk proses dengan 1 pengguna didapatkan 129 request dengan kecepaan rata-
rata setiap requestnya selesai adalah 18 ms, dengan throughput atau request
yang berhasil diproses tiap detik adalah 50,3. Sedangkan data yang berhasil di
unduh oleh server tiap detiknya adalah 738,51 KB dan server dapat mengirim
data 34,48 Kb setiap detiknya. Dari pengujian dengan 1 pengguna sampai 30
pengguna proses login ini berjalan dengan cukup stabil meningkat sesuai
dengan banyaknya jumlah pengguna dan dengan tingkat kegagalan proses 0%.

• Aplikasi Baru
NO Proses Request Average Throughput Received/sent Error User
(ms) (/sec) (KB/Sec) (%)
Received Sent
1 38 12 76,0 22.606,89 59,73 0 1
2 190 25 103,6 30.861,55 81,42 0 5
3 CRUD 380 71 104,2 31.159,15 81,89 0 10
4 Data 570 144 94,8 26.126,67 74,51 0 15
5 Siswa/i 760 377 49,7 5.679,21 35,73 0 20
6 950 378 61,8 7.063,02 44,43 0 25
7 1080 378 74,4 8.507,70 53,32 0 30
Tabel 4.5 Hasil Pengujian CRUD Data Siswa/I
Aplikasi Baru

Dari hasil pengujian proses CRUD data siswa/i pada aplikasi baru,
untuk proses dengan 1 pengguna didapatkan 38 request (91 lebih sedikit dari
request CRUD pada aplikasi lama) dengan kecepaan rata-rata setiap
requestnya selesai adalah 12 ms (6 ms lebih cepat dari aplikasi lama), dengan
throughput atau request yang berhasil diproses tiap detik adalah 76,0(25,7 lebih
besar dari pada throughput aplikasi lama). Sedangkan data yang berhasil di
unduh oleh server tiap detiknya adalah 22.606,89 KB (21.867,49 lebih besar
dari pada kemampuan unduh pada aplikasi lama) dan server dapat mengirim
data 59,73 KB(25,25 KB lebih besar dari pada kemampuan mengirim data pada
aplikasi lama) setiap detiknya. Dari pengujian dengan 1 pengguna sampai 30
pengguna proses ini berjalan dengan mengalami peningkatan sesuai jumlah
pengguna namun mulai stabil pada 20-30 pengguna, dan dengan tingkat
kegagalan proses 0%.

50
 Gambar 4.18 Diagram Pengujian CRUD Data Siswa/i Aplikasi
Lama dan Baru
Dari hasil kedua pengujian dengan 1 pengguna sampai 30 pengguna
didapatkan bahwa proses CRUD data siswa/i pada aplikasi baru dengan 1
pengguna memiliki respon time yang lebih cepat dari pada proses CRUD data
siswa/i pada aplikasi lama, dengan perbandingan kecepatan 8 ms lebih cepat,
dan 25,7 lebih banyak request yang berhasil di proses.
Namun pada pengguna lebih dari 10 proses CRUD data siswa/I aplikasi
lama lebih cepat dari pada proses CRUD data siswa/I aplikasi baru dengan
peningkatan yang sesuai dengan jumlah pengguna dan pada 30 pengguna proses
CRUD data siswa/I aplikasi lama memiliki kecepatan 150ms lebih cepat dari
proses CRUD data siswa/I pada aplikasi baru dan throughput atau request yang
berhasil diproses tiap detik adalah 54,4 lebih besar dari aplikasi baru.
Dari chart atau diagram diatas terlihat perbandingan antara keduanya,
CRUD aplikasi lama bergerak meningkat secara linear sesuai jumlah pengguna
sedangkan CRUD aplikasi baru meningkat pada pengguna dibawah 20 dan mulai
stabil pada 20 pengguna sampai 30 penguna dan keduanya memiliki tingkat
kegagalan 0%.

3) Hasil Pengujian Proses Transaksi Tabungan

• Aplikasi Lama
NO Proses Request Average Throughput Received/sent Error User
(ms) (KB/Sec) (%)
(/sec) Received Sent
1 61 80 3,1 65,04 2,21 1,11 1
2 450 703 6,5 134,99 4,6 1,11 5
3 Transaksi 900 1678 5,6 117,27 3,99 1,11 10
4 Tabungan 1350 2975 4,9 101,15 3,44 1,11 15
5 1800 4265 4,3 88,76 3,02 1,11 20
6 2250 5215 4,6 95,50 3,25 1,11 25

51
7 2700 6195 4,7 98,41 3,35 1,11 30
Tabel 4.6 Hasil Pengujian Transaksi Tabungan
Aplikasi Lama
Dari Hasil pengujian Proses halaman laporan tabungan pada aplikasi
lama, untuk proses dengan 1 pengguna didapatkan 61 request dengan kecepaan
rata-rata setiap requestnya adalah 80 ms, dengan throughput atau request yang
berhasil diproses tiap detik adalah 3,1. Sedangkan data yang berhasil di unduh
oleh server tiap detiknya adalah 65,04 KB dan server dapat mengirim data 2,21
Kb setiap detiknya. Dari pengujian dengan 1 pengguna sampai 30 pengguna
proses login ini berjalan dengan cukup stabil namun memiliki tingkat kegagalan
proses 1,11% yaitu pada label atau URL :
http://localhost/sumberbarokah/sisbws/jpegcam/foto/407082100421.jpg.
Kegegalan proses ini dapat terjadi karenaalamat URL yang di request tidak ada
atau juga karena file .jpg terlalu besar atau bisa karena faktor-faktor lainnya.

• Aplikasi Baru
NO Proses Request Average Through Received/sent Error User
(ms) put (KB/Sec) (%)
(/sec) Received Sent
1 36 52 19,2 2360,06 13,43 0 1
2 180 170 22,1 2720,25 15,49 0 5
3 Transa 360 358 21,9 2701,20 15,38 0 10
ksi
4 540 561 21,7 2670,66 15,20 0 15
Tabun
5 gan 720 273 55,4 6722,50 38,88 0 20
6 900 285 80,1 9672,71 56,20 0 25
7 1080 285 95,7 11555,81 67,14 0 30
Tabel 4.7 Hasil Pengujian Transaksi Tabungan
Aplikasi Baru

Dari Hasil pengujian Proses halaman laporan tabungan pada aplikasi

batu, untuk proses dengan 1 pengguna didapatkan 36 request dengan kecepaan
rata-rata setiap requestnya adalah 52 ms, dengan throughput atau request yang
berhasil diproses tiap detik adalah 19,2. Sedangkan data yang berhasil di unduh
oleh server tiap detiknya adalah 2360,06 KB dan server dapat mengirim data
13,43 Kb setiap detiknya. Dari pengujian dengan 1 pengguna sampai 30
pengguna proses login ini berjalan dengan cukup dengan tinggat kegagalan
proses 0%.

52
 Gambar 4.19 Diagram Pengujian Transaksi Tabungan Aplikasi
Lama dan Baru

Dari hasil kedua pengujian dengan 1 pengguna sampai 30 pengguna

didapatkan bahwa proses transaksi tabungan pada aplikasi baru memiliki respon
time yang lebih cepat dari pada proses login pada aplikasi lama, dengan
perbandingan kecepatan 28 – 5.634 ms lebih cepat, dan 16,1 – 89,2 lebih banyak
request yang berhasil di proses.
Dari chart atau diagram diatas terlihat perbandingan antara keduanya
cukup signifikan, namun keduanya cukup stabil hanya saja pada aplikasi lama
terdapat request yang tidak dapat diproses dengan tingkat kegagalan 1,11%.

4) Hasil Pengujian Proses Transaksi Pembayaran

• Aplikasi Lama
NO Proses Request Average Throughput Received/sent Error User
(ms) (/sec) (KB/Sec) (%)
Received Sent
1 115 479 2,1 34,28 1,51 1,74 1
2 575 1271 3,4 56,24 2,48 1,74 5
3 1150 1913 4,2 69,78 3,08 1,74 10
Transaksi
4 1725 1888 6,2 102,44 452 1,74 15
Pembayaran
5 2300 3076 5,3 87,23 3,85 1,74 20
6 2875 4020 5,0 82.98 3,66 1,74 25
7 3450 7303 3,5 58,14 2,56 1,74 30
Tabel 4.8 Hasil Pengujian Transaksi Pembayaran
Aplikasi Lama
Dari Hasil pengujian proses transaksi pembayaran pada aplikasi lama,
untuk proses dengan 1 pengguna didapatkan 115 request dengan kecepaan rata-

53
 rata setiap requestnya adalah 479 ms, dengan throughput atau request yang
berhasil diproses tiap detik adalah 2,1. Sedangkan data yang berhasil di unduh
oleh server tiap detiknya adalah 34,28 KB dan server dapat mengirim data 1,51
Kb setiap detiknya. Dari pengujian dengan 1 pengguna sampai 30 pengguna
proses login ini berjalan dengan cukup stabil namun memiliki tingkat kegagalan
proses 1,74% yaitu pada label atau URL :
http://localhost/sumberbarokah/sisbws/jpegcam/foto/407082100421.jpg dan
pada label URL :
http://localhost/sumberbarokah/sisbws/app/view/PERIKSA_STATUS_IZIN.ph
p?q=407082100421. Kegagalan proses ini dapat terjadi karena alamat URL yang
di request tidak ada atau juga karena file .jpg terlalu besar atau bisa karena
faktor-faktor lainnya.

• Aplikasi Baru
NO Proses Request Average Throughput Received/sent Error User
(ms) (/sec) (KB/Sec) (%)
Received Sent
1 31 200 5,0 683,00 3,58 0 1
2 155 199 22,2 3034,96 15,89 0 5
3 310 199 44,0 6020,83 31,53 0 10
Transaksi
4 Pembayaran
465 198 65,6 8975,21 47,00 0 15
5 620 198 87,3 11953,46 62,59 0 20
6 775 199 108,7 14878,95 77,91 0 25
7 930 198 131,2 17960,54 94,05 0 30
Tabel 4.9 Hasil Pengujian Transaksi Pembayaran
Aplikasi Baru
Dari Hasil pengujian transaksi pembayaran aplikasi baru, untuk proses
dengan 1 pengguna didapatkan 31 request dengan kecepaan rata-rata setiap
requestnya adalah 200 ms (279ms lebih cepat dari pada aplikasi lama), dengan
throughput atau request yang berhasil diproses tiap detik adalah 5,0(2,9 lebih
banyak dari pada aplikasi lama). Sedangkan data yang berhasil di unduh oleh
server tiap detiknya adalah 683,0 KB (648,72 KB lebih banyak dari pada
apalikasi lama) dan server dapat berhasil mengirim data 3,58 Kb setiap detiknya
(2,07 KB lebih banyak dari aplikasi lama). Dari pengujian dengan 1 pengguna
sampai 30 pengguna proses login ini berjalan dengan cukup stabil dengan tingkat
kegagalan proses 0%.

54
 Gambar 4.20 Diagram Pengujian Transaksi Tabungan Aplikasi
Lama dan Baru

Dari hasil kedua pengujian dengan 1 pengguna sampai 30 pengguna

didapatkan bahwa proses transaksi pembayaran aplikasi baru memiliki respon
time yang lebih cepat dari pada proses transaksi pembayaran pada aplikasi lama,
dengan perbandingan kecepatan 277 – 7103 ms lebih cepat, dan 2,9 – 125 lebih
banyak request yang berhasil di proses.
Dari chart atau diagram diatas terlihat perbandingan antara keduanya
cukup signifikan, pada proses transaksi pembayaran aplikasi lama jumlah
request dan throughput meningkat sesuai jumlahnya pengguna dengan tingkat
kegagalan 1,74% yaitu dengan ada 2 request yang tidak dapat diproses
sedangkan proses transaksi pembayaran aplikasi lama berjalan cukup stabil
dengan tingkat kegagalan 0%.

5) Hasil Pengujian Menampilkan Laporan Tabungan

• Aplikasi Lama
NO Proses Request Average Throughput Received/sent Error User
(ms) (/sec) (KB/Sec) (%)
Received Sent
1 94 1538 0,65 13,01 0,44 7,45 1
2 470 6143 0,63 12,71 0,43 7,45 5
3 940 12004 0,61 12,19 0,41 7,45 10
Laporan
4 1410 21359 0,50 10,10 0,34 7,45 15
Tabungan
5 1880 37188 0,40 8,13 0,27 7,45 20
6 2350 47689 0,34 6,82 0,23 7,45 25
7 2820 52684 0,42 8,52 0,29 7,45 30
Tabel 4.10 Hasil Pengujian Laporan Tabungan
Aplikasi Lama

55
 Dari Hasil pengujian Proses halaman laporan tabungan pada aplikasi
lama, untuk proses dengan 1 pengguna didapatkan 94 request dengan kecepatan
rata-rata setiap requestnya adalah 1538 ms, dengan throughput atau request
yang berhasil diproses tiap detik adalah 0,65. Sedangkan data yang berhasil di
unduh oleh server tiap detiknya adalah 13,01 KB dan server dapat mengirim
data 0,44 Kb setiap detiknya. Dari pengujian dengan 1 pengguna sampai 30
pengguna proses login ini berjalan dengan cukup stabil namun memiliki tingkat
kegagalan proses 7,45% yaitu pada label atau URL :
1) http://localhost/sumberbarokah/sisbws/plugins/jquery/themes/base/jquery.
ui.all.css.
2) http://localhost/sumberbarokah/sisbws/plugins/jquery/js/jquery-
1.7.2.min.js?_=1640784475213.
3) http://localhost/sumberbarokah/sisbws/plugins/jquery/js/jquery-ui-
1.8.22.custom.min.js?_=1640784475223
4) http://localhost/sumberbarokah/sisbws/app/view/plugins/jcombo/jcombo.js
?_=1640784475231
5) http://localhost/sumberbarokah/sisbws/plugins/jquery/ui/jquery.ui.core.js?
_=1640784475239
6) http://localhost/sumberbarokah/sisbws/plugins/jquery/ui/jquery.ui.widget.j
s?_=1640784475246
7) http://localhost/sumberbarokah/sisbws/plugins/jquery/ui/jquery.ui.button.j
s?_=1640784475254

Kegagalan proses ini dapat terjadi karena alamat URL yang di request
tidak ada atau juga karena file .jpg terlalu besar atau bisa karena faktor-faktor
lainnya.

• Aplikasi Baru
NO Proses Request Average Throughput Received/sent Error User
(ms) (/sec) (KB/Sec) (%)
Received Sent
1 36 284 3,5 423,24 2,46 0 1
2 180 284 16,3 1964,63 11,41 0 5
3 360 284 32,2 3885,00 22,57 0 10
Laporan
4 540 284 48,3 5824,90 33,84 0 15
Tabungan
5 720 284 64,2 7749,90 45,03 0 20
6 900 284 80.6 9728,16 56,52 0 25
7 1080 284 96,5 11651,87 67,70 0 30
Tabel 4.11 Hasil Pengujian Laporan Tabungan
Aplikasi Baru
Dari hasil pengujian proses halaman laporan tabungan pada aplikasi
baru, untuk proses dengan 1 pengguna didapatkan 36 request dengan kecepatan
rata-rata setiap requestnya adalah 284 ms, dengan throughput atau request yang
berhasil diproses tiap detik adalah 3,5. Sedangkan data yang berhasil di unduh
oleh server tiap detiknya adalah 423,24 KB dan server dapat mengirim data 2,46
Kb setiap detiknya. Dari pengujian dengan 1 pengguna sampai 30 pengguna

56
 proses login ini berjalan dengan stabil dan memiliki tingkat kegagalan proses
0%.

Gambar 4.21 Diagram Pengujian Laporan Tabungan Aplikasi

Lama dan Baru
Dari hasil kedua pengujian dengan 1 pengguna sampai 30 pengguna
didapatkan bahwa proses laporan tabungan aplikasi baru memiliki respon time
yang cukup jauh lebih cepat dari pada proses laporan tabungan pada aplikasi
lama, dengan perbandingan kecepatan 1.254 – 52.400 ms lebih cepat, dan 3,16
– 95,85 lebih banyak request yang berhasil di proses.
Dari chart atau diagram diatas terlihat perbandingan antara keduanya
cukup jauh signifikan, pada proses laporan tabungan aplikasi lama jumlah
request dan throughput meningkat sesuai jumlahnya pengguna dengan tingkat
kegagalan 7,45% yaitu dengan ada 7 request yang tidak dapat diproses
sedangkan proses transaksi pembayaran aplikasi lama berjalan stabil dengan
kecepatan request yang dapat terselesaikan 284 ms tingkat kegagalan 0%.

6) Hasil Pengujian Menampilkan Laporan Pembayaran

• Aplikasi Lama
N Proses Request Average Throu Received/sent Error Use
O (ms) ghput (KB/Sec) (%) r
(/sec)
Received Sent
1 67 28 35,1 1031,74 23,45 0 1
2 335 116 36,6 1076,21 24,46 0 5
3 670 251 35,5 1037,83 23,59 0 10
4 Laporan 1005 378 35,5 1043,52 23,72 0 15
5 Pembaya 1340 483 37,2 1092,49 24,83 0 20
6 ran 1675 617 36,6 1074,68 24,43 0 25
7 2010 780 35,0 1028,81 23,38 0 30
Tabel 4.12 Hasil Pengujian Laporan Pembayaran
Aplikasi Lama
57
 Dari Hasil pengujian Proses halaman laporan tabungan pada aplikasi
lama, untuk proses dengan 1 pengguna didapatkan 67 request dengan kecepatan
rata-rata setiap requestnya adalah 28 ms, dengan throughput atau request yang
berhasil diproses tiap detik adalah 35,1. Sedangkan data yang berhasil di unduh
oleh server tiap detiknya adalah 1031,74 KB dan server dapat mengirim data
23,45 KB setiap detiknya. Dari pengujian dengan 1 pengguna sampai 30
pengguna proses login ini berjalan dengan cukup stabil dengan memiliki tingkat
kegagalan proses 0% .

• Aplikasi Baru
NO Proses Request Average Throu Received/sent Error Use
(ms) ghput (KB/Sec) (%) r
(/sec) Received Sent
1 35 233 4,3 530,38 2,99 0 1
2 175 233 19,5 2421,86 13,64 0 5
3 Laporan 350 234 38,3 4749,45 26,76 0 10
4 Pembay 525 234 57,5 7140,58 40,23 0 15
5 aran 700 234 76,5 9495,79 53,50 0 20
6 875 234 95,5 11859,37 66,81 0 25
7 1050 233 114,8 14254,60 80,31 0 30
Tabel 4.13 Hasil Pengujian Laporan Pembayaran
Aplikasi Baru
Dari hasil pengujian proses halaman laporan pembayaran pada aplikasi
baru, untuk proses dengan 1 pengguna didapatkan 35 request dengan kecepatan
rata-rata setiap requestnya adalah 233 ms, dengan throughput atau request yang
berhasil diproses tiap detik adalah 4,3. Sedangkan data yang berhasil di unduh
oleh server tiap detiknya adalah 530,38 KB dan server dapat mengirim data 2,99
Kb setiap detiknya. Dari pengujian dengan 1 pengguna sampai 30 pengguna
proses login ini berjalan dengan stabil dan memiliki tingkat kegagalan proses
0%.

58
 Gambar 4.22 Diagram Pengujian Laporan Pembayaran Aplikasi
Lama dan Baru
Dari hasil kedua pengujian dengan 1 pengguna sampai 30 pengguna
didapatkan bahwa proses laporan pembayaran pada aplikasi lama memiliki
respon time yang lebih cepat pada 1 pengguna sampai kurang dari 10 pengguna
dari pada proses laporan pembayaran pada aplikasi baru, dengan perbandingan
kecepatan 205 ms lebih cepat, dan 30,8 lebih banyak request yang berhasil di
proses.
Sedangkan pada 10 pengguna sampai 20 pengguna, halaman proses
laporan pembayaran pada aplikasi baru lebih cepat dan lebih stabil yaitu dengan
kecepatan request 17 – 546 ms dan 2,8 – 77,6 lebih banyak request yang berhasil
di proses.
Dari chart atau diagram diatas terlihat perbandingan antara proses
keduanya, keduanya berjalan cukup stabil dengan sama-sama memiliki tingkat
kegagalan 0%.

7) Hasil Pengujian Menu Koreksi Pembayaran/Pembatalan

• Aplikasi Lama

N Proses Request Average Throu Received/sent Error Use

O (ms) ghput (KB/Sec) (%) r
(/sec) Received Sent
1 93 369 2,7 52,52 1,87 0 1
2 447 590 8,0 155,89 5,54 1,08 5
3 Koreksi 930 1767 5,3 103,24 3,67 1,08 10
4 Pembaya 1395 4010 3,6 69,61 2,47 1,08 15
5 ran 1860 7430 2,6 50,06 1,78 1,08 20

59
6 2325 7478 3,2 62,38 2,22 1,08 25
7 2790 6377 4,6 89,57 3,18 1,08 30
Tabel 4.14 Hasil Pengujian Koreksi Pembayaran
Aplikasi Lama
Dari Hasil pengujian Proses halaman laporan tabungan pada aplikasi
lama, untuk proses dengan 1 pengguna didapatkan 93 request dengan kecepatan
rata-rata setiap requestnya adalah 386 ms, dengan throughput atau request yang
berhasil diproses tiap detik adalah 2,7. Sedangkan data yang berhasil di unduh
oleh server tiap detiknya adalah 52,52 KB dan server dapat mengirim data 1,87
KB setiap detiknya. Dari pengujian dengan 1 pengguna sampai 30 pengguna
proses login ini memiliki kegagalan proses 1,08% yaitu pada label atau URL :
http://localhost/sumberbarokah/sisbws/app/view/PERIKSA_STATUS_IZIN.ph
p?q=407082100439 .

• Aplikasi Baru

N Proses Request Average Throu Received/sent Error Use

O (ms) ghput (KB/Sec) (%) r
(/sec) Received Sent
1 35 23 40,4 6114,57 29,30 0 1
2 175 6 174.7 26423,23 126,1 0 5
4 7
3 350 5 329,9 49907,80 238,3 0 10
1
4 525 16 408,2 61763,88 294,9 0 15
Koreksi 3
5 Pembaya 700 26 426,3 64497,22 307,0 0 20
ran 8
6 875 33 448,0 67783,13 323,6 0 25
7
7 1050 48 448,1 67800,55 323,7 0 30
5
Tabel 4.15 Hasil Pengujian Koreksi Pembayaran
Aplikasi Lama
Dari hasil pengujian proses koreksi pembayaran pada aplikasi baru,
untuk proses dengan 1 pengguna didapatkan 35 request dengan kecepatan rata-
rata setiap requestnya adalah 23 ms, dengan throughput atau request yang
berhasil diproses tiap detik adalah 40,4. Sedangkan data yang berhasil di unduh
oleh server tiap detiknya adalah 6114,57 KB dan server dapat mengirim data
29,30 Kb setiap detiknya. Dari pengujian dengan 1 pengguna sampai 30
pengguna proses login ini berjalan dengan cukup stabil dan memiliki tingkat
kegagalan proses 0%.

60
 Gambar 4.23 Diagram Pengujian Koreksi Pembayaran Aplikasi
Lama dan Baru
Dari hasil kedua pengujian dengan 1 pengguna sampai 30 pengguna
didapatkan bahwa proses koreksi pembayaran aplikasi baru memiliki respon
time yang cukup jauh lebih cepat dari pada proses laporan tabungan pada
aplikasi lama, dengan perbandingan kecepatan 364 – 6329 ms lebih cepat, dan
32,4 – 67,792,55 lebih banyak request yang berhasil di proses.
Dari chart atau diagram diatas terlihat perbandingan antara keduanya
cukup jauh signifikan, pada proses koreksi pembayaran aplikasi lama jumlah
request dan throughput meningkat sesuai jumlahnya pengguna dengan tingkat
kegagalan 1,08% yaitu dengan ada 1 request yang tidak dapat diproses
sedangkan proses koreksi pembayaran pada aplikasi baru berjalan stabil
dengan kecepatan request yang dapat terselesaikan 284 ms tingkat kegagalan
0%.

4.6 Evaluasi Pengujian Aplikasi

Setelah dilakukan pengujian menggunakan Apache Jmeter dan pengujian
langgung oleh pengguna ada beberapa menu yang perlu di evaluasi untuk
pengembangan selanjutnya, berikut diantaranya :

NO Menu Perbaikan/
Pengembangan
1 Login Menggunakan sweetalert untuk jendela
dialog

61
2 CRUD Data Siswa/i Menambahkan upload foto, ditambahakan
history update dan delete
3 Tabungan Ditambahkan nominal rupiah
4 Pembayaran Ditambahkan nominal rupiah
5 Laporan Tabungan Menambahkan laporan khusus 1 bulan
6 Laporan Pembayaran Menambahkan laporan khusus 1 bulan
7 Koreksi Pembayaran -
Tabel 4.16 Tabel Evaluasi Pengujian Aplikasi
Dengan kecepatan response time yang cukup stabil pada setiap menu
yang ada pada aplikasi baru maka beberapa penambahan fitur tersebut dapat
dilakukan untuk pengembangan selanjutnya.

62
 BAB V
PENUTUP
5.1 Kesimpulan
Dari beberapa pengujian yang telah dilakukan pada didapatkan bahwa
beberapa proses yang dilakukan pada aplikasi baru rata-rata memiliki respon
time yang lebih cepat throughput lebih besar stabil dari pada aplikasi lama
administrasi Pondok Pesantren Sumber Barokah Karawang. Namun untuk
proses CRUD data siswa/i aplikasi lama lebih stabil dari pada aplikasi baru.
Selain itu pada aplikasi lama memiliki tingkat error 1,11% untuk transaksi
tabungan, 1,74% untuk transaksi pembayaran dan 7,45% untuk laporan
tabungan.

5.2 Saran
Pada Penelitian dan pengembangan yang telah dilakukan ini, tentu saja
masih banyak kekurangan dan kelemahan, Oleh karena itu ada beberapa hal
yang perlu diperhatikan dalam pengenbangan kedepannya, anatara lain :
1. Sistem informasi ini baru dapat dijangkau hanya disekitar Pondok
Pesantren saja, disarankan agar dapat dijangkau oleh orangtua siswa
sehingga dapat mengetahui transaksi yang teldah dilakukan oleh
anaknya di Pondok Pesantren
2. Untuk Sistem informasi khususnya bagian Administrasi/Keuangan
perlu adanya sistem keamanan data yang baik sehingga data dapat lebih
aman.

63
 DAFTAR PUSTAKA
Abidin, Z. and Purbawanto, S. (2015) ‘Pemahaman Siswa Terhadap Pemanfaatan
Media Pembelajaran Berbasis Livewire Pada Mata Pelajaran Teknik Listrik Kelas
X Jurusan Audio Video Di Smk Negeri 4 Semarang’, Edu Elektrika Journal, 4(1),
pp. 38–49.
Aditya, P., Erna, K. and Dina, A. (2020) ‘Komparasi Penggunaan Framework
Codeigniter Vs Php Native Pada Sistem Informasi Manajemen Surat Sekretariat
Dprd Pemalang’, Jurnal SCRIPT, 8(1), pp. 1–6.
Aziz, A. and Tampati, T. (2015) ‘Analisis Web Server untuk Pengembangan
Hosting Server Institusi: Pembandingan Kinerja Web Server Apache dengan
Nginx’, Multinetics, 1(2), p. 12. doi: 10.32722/vol1.no2.2015.pp12-20.
Bhaswara, F. A., Sarno, R. and Sunaryono, D. (2017) ‘Perbandingan Kemampuan
Database NoSQL dan SQL dalam Kasus ERP Retail’, Jurnal Teknik ITS, 6(2), pp.
510–514. doi: 10.12962/j23373539.v6i2.24031.
Budiman, S. et al. (2021) ‘Perbandingan Performa SQL dan NoSQL Dengan PHP
Pada 5 Juta Data’, IJCIT (Indonesian Journal on Computer and Information
Technology), 6(1), pp. 38–42. doi: 10.31294/ijcit.v6i1.9692.
Chandra and Yakobus, A. (2019) ‘Analisis Performansi Antara Apache & Nginx
Web Server Dalam Menangani Client Request’, Jurnal Sistem dan Informatika
(JSI), 14(1), pp. 48–56. doi: 10.30864/jsi.v14i1.248.
Christopher, H., Unsong, Y. and Andjarwirawan, J. (2021) ‘Analisa Kinerja Apache
dan Nginx dalam Arsitektur Microservice Menggunakan Siege’, Jurnal Infa, pp. 2–
6.
Dio Lavarino, W. Y. (2016) ‘RANCANG BANGUN E – VOTING BERBASIS
WEBSITE DI UNIVERSITAS NEGERI SURABAYA’, Jurnal Manajemen
Informatika, 17(1), pp. 1–13.
Endra, R. Y. et al. (2021) ‘Analisis Perbandingan Bahasa Pemrograman PHP
Laravel dengan PHP Native pada Pengembangan Website’, EXPERT: Jurnal
Manajemen Sistem Informasi dan Teknologi, 11(1), p. 48. doi:
10.36448/expert.v11i1.2012.
Eriton, R., Muldina Negara, R. and Sanjoyo Dwi, D. (2017) ‘Analisis Performasi
Framework Codeigniter Dan Laravel Menggunakan Web Server Apache’, Analisis
Performasi Framework Codeigniter dan Laravel Menggunakan Web Server
APACHE, 4(3), pp. 3565–3572.
Fadhilah, M. R. et al. (2018) ‘PERANCANGAN DAN IMPLEMENTASI
DATABASE SERVER DENGAN MARIADB DAN LINUX CENTOS (STUDI
KASUS: PT. INFOMEDIA NUSANTARA) Design and Implementation of
Database Server MariaDB and Linux CentOS (Case Study PT. Infomedia
Nusantara)’, Proceeding of Applied Science, 4(3), p. 2601.
Fadli, A. et al. (2020) ‘Analisis Perbandingan Unjuk Kerja Database SQL dan
Database NoSQL Untuk Mendukung Era Big Data’, Jurnal Nasional Teknik
Elektro, 9(3). doi: 10.25077/jnte.v9n3.774.2020.
Helmud, E. (2021) ‘Optimasi Basis Data Oracle Menggunakan Complex View
Studi Kasus : Pt. Berkat Optimis Sejahtera (Pt.Bos) Pangkalpinan’, Jurnal
Informatika, 7(1), pp. 80–86.
Hutama Muliana et al. (2018) ‘Analisis Perbandingan Kinerja Web Server Apache

64
dan Nginx pada VPS dengan Menggunakan HTTPERF untuk Sistem Operasi
CentOS’, p. 18.
Ibrahim, U., Acquah, J. B. H. and Twum, F. (2018) ‘Comparative Analysis of
Codeigniter and Laravel in Relation To Object-Relational Mapping, Load Testing
and Stress Testing’, International Research Journal of Engineering and
Technology, 5(2), p. 5. Available at: www.irjet.net.
Irza, I. F., Zulhendra, Z. and Efrizon, E. (2017) ‘Analisis Perbandingan Kinerja
Web Server Apache dan Nginx Menggunakan Httperf Pada Portal Berita (Studi
Kasus beritalinux.com)’, Voteteknika (Vocational Teknik Elektronika dan
Informatika), 5(2). doi: 10.24036/voteteknika.v5i2.8489.
Jaiswal, G. and Agrawal, A. P. (2015) ‘Comparative analysis of Relational and
graph databases’, IJIACS International Journal of Innovations & Advancement in
Computer Science, 4, pp. 181–183.
Janev, M., Delipetrev, B. and Ristova, S. (2015) ‘Performance benchmark of PHP
frameworks with database select methods’, International Conference for young
researchers, Technical Sciences, Industrial Management, 63(12), pp. 38–41.
Junaidi, A. (2016) ‘Studi Perbandingan Performansi Antar Mongodb Dan Mysql
Menggunakan Php Dalam Lingkungan Big Data’, Prosiding Annual Research
Seminar 2016, 2(1), pp. 460–465.
Kapoor, A. (2020) ‘Comparitive Study on Web Development using core PHP &
Laravel Framework’, International Journal of Advance Science and Technology,
29(10), pp. 2660–2663.
Kinanti, T. A. (2021) ‘Perbandingan Kinerja Database MongoDB dan Cassandra
Menggunakan YCSB’, Researchgate, (January), p. 02.
Kouw, I. W. K. et al. (2020) ‘Membangun sistem informasi pendaftaran siswa baru
Berbasis web dengan metode mdd (model driven development) di raudhatul athfal
nahjussalam’, Jurnal Sistem Informasi, 3(1), pp. 30–52.
Laaziri, M. et al. (2019) ‘A Comparative study of PHP frameworks performance’,
Procedia Manufacturing, 32, pp. 864–871. doi: 10.1016/j.promfg.2019.02.295.
Latif, U. K. and Kusumasari, T. F. (2018) ‘Comparison Between Yii Frameworks
and Laravel in 3 Different Version for Viewing Large Data of Shipyard Industry in
Indonesia’, International Journal of Innovation in Enterprise System, 2(01), pp. 13–
18. doi: 10.25124/ijies.v2i01.12.
Lubis, J. H. (2017) ‘Analisa Performansi Query Pada Database Smell’, Jurnal
Manajemen dan Informatika Pelita Nusantara, 21(1), pp. 42–49. Available at:
http://e-jurnal.pelitanusantara.ac.id/index.php/mantik/article/view/188/105.
Maanari, J. I. et al. (2013) ‘Perancangan Basis Data Perusahaan Distribusi Dengan
Menggunakan Oracle’, Jurnal Teknik Elektro dan Komputer, 2(2). doi:
10.35793/jtek.2.2.2013.1719.
Noviyanti, P. et al. (2018) ‘Perbandingan Query Response Time pada Model Query
View dan Cross Product’, e-Jurnal JUSITI (Jurnal Sistem Informasi dan Teknologi
Informasi), 7–2(2), pp. 131–141. doi: 10.36774/jusiti.v7i2.248.
Praba, A. D. and Hariyanto (2020) ‘Performansi Web Server Apache dan Nginx
Pada Aplikasi penjualan Online’, Indonesian Journal on Networking and Security,
9(3), pp. 1–6.
Prasena, R. R. and Sama, H. (2020) ‘Studi Komparasi Pengembangan
Websitedengan Framework Codeigniter Dan Laravel’, Conference on Business,
Social Sciences and Innovation Technology, 1(1), pp. 613–621. Available at:

65
https://journal.uib.ac.id/index.php/cbssit/article/view/1469/969.
Prasetyo, B., Pattiasina, T. J. and Soetarmono, A. N. (2015) ‘Perancangan dan
Pembuatan Sistem Informasi’, Teknika, 4(1), pp. 12–16.
Rakhmawati, N. A. et al. (2019) ‘Benchmarking MySQL and NoSQL Databases on
Egovbench Application’, Journal of Information Technology and Its Utilization,
2(1), p. 18. doi: 10.30818/jitu.2.1.2080.
Riswandi, Kasim and Raharjo, M. F. (2020) ‘Evaluasi Kinerja Web Server Apache
menggunakan Protokol HTTP2’, Journal of Engineering, Technology, and Applied
Science, 2(1), pp. 19–31. doi: 10.36079/lamintang.jetas-0201.92.
Rosid, M. A. (2017) ‘Implementasi JSON untuk Minimasi Penggunaan Jumlah
Kolom Suatu Tabel Pada Database PostgreSQL’, JOINCS (Journal of Informatics,
Network, and Computer Science), 1(1), p. 33. doi: 10.21070/joincs.v1i1.802.
Salsabila, N. S. et al. (2021) ‘Analisa Perbandingan Kemampuan Database NoSQL
dan SQL’, ResearchGate, (January).
Saputra, A. (2012) ‘Manajemen Basis Data Mysql’, Jurnal Berita Dirgantara,
13(4), pp. 155–162. Available at:
http://www.jurnal.lapan.go.id/index.php/berita_dirgantara/article/view/1733/1568.
Saputra, D. (2018) ‘Analisis Perbandingan Performa Web Service Rest
Menggunakan Framework Laravel, Django Dan Ruby On Rails Untuk Akses Data
Dengan’, Jurnal Bangkit Indonesia, 7(2), p. 17. doi:
10.52771/bangkitindonesia.v7i2.90.
Satryawan, E. (2016) ‘Studi Komparatif Prestasi Belajar Mahasiswa Antara
Penerima Beasiswa Dengan Tidak Penerima Beasiswa Di Fakultas Ekonomi Dan
Bisnis Universitas Pendidikan Ganesha Angkatan 2011’, Jurnal Program Studi
Pendidikan Ekonomi (JPPE), 7(2).
Satwika, I. K. S. and Semadi, K. N. (2020) ‘Perbandingan Performansi Web Server
Apache Dan Nginx Dengan Menggunakan Ipv6’, SCAN - Jurnal Teknologi
Informasi dan Komunikasi, 15(1), pp. 10–15. doi: 10.33005/scan.v15i1.1847.
Selamet, R. (2008) ‘Peranan sql dari waktu ke waktu’, Media Informatika, 7(3), pp.
158–163.
Setialana, P., Adji, T. B. and Ardiyanto, I. (2017) ‘Perbandingan Performa
Relational, Document-Oriented dan Graph Database Pada Struktur Data Directed
Acyclic Graph’, Jurnal Buana Informatika, 8(2), pp. 77–86. doi:
10.24002/jbi.v8i2.1079.
Setiawan, D. and Kurniasih, N. C. (2020) ‘PENGARUH BIAYA BAHAN BAKU
DAN BIAYA TENAGA KERJA TERHADAP LABA BERSIH PADA PT.
SATWA PRIMA UTAMA (Studi pada RJ Farm Amir Atanudin Kp. Pasir Jati Desa
Lebak Wangi Kecamatan Arjasari Kabupaten Bandung)’, Jurnal Ilmiah Akuntansi,
11(April), pp. 55–64.
Silalahi, M. (2018) ‘Perbandingan Performansi Database Mongodb Dan Mysql
Dalam Aplikasi File Multimedia Berbasis Web’, Computer Based Information
System Journal, 6(1), p. 63. doi: 10.33884/cbis.v6i1.574.
Sinuraya, J. (2017) ‘Metode Pencarian Data Menggunakan Query Hash Join Dan
Query Nested Join’, Teknovasi, 4(1), pp. 24–50.
Standsyah, R. E. and Restu, I. S. (2017) ‘Implementasi Phpmyadmin Pada
Rancangan Sistem Pengadministrasian’, Jurnal UJMC, Volume 3, Nomor 2, Hal.
38 - 44, 3, pp. 38–44. Available at: http://e-
jurnal.unisda.ac.id/index.php/ujmc/article/download/467/251/.

66
Suliyanti, W. N. (2019) ‘Studi Literatur Basis Data SQL dan NoSQL’, Jurnal Kilat,
8(1), pp. 48–51. doi: 10.33322/kilat.v8i1.460.
Yudhiastari, M. (2021) ‘Analisis Kinerja Web Server Apache Dan Litespeed
Menggunakan Httperf Pada Virtual Private Server ( VPS )’, XVI, pp. 24–32.

67