Peningkatan Kinerja Server Aplikasi Web GIS Berbasis PostgreSQL dan MapServer

(1)

ABSTRACT

AURIZA RAHMAD AKBAR. Performance Improvement of Web GIS Application Server Based on PostgreSQL and MapServer. Under the direction of HARI AGUNG ADRIANTO.

The PHP MapScript-based web GIS application with a huge amount of geographic data is very slow to load. In this paper, we will scale-up the server to bring the real potential out of the hardware. We will also use caching technique to speed-up both the PHP scripts and the map generation, using APC (Alternative PHP Cache) and TileCache respectively. APC can be used as opcode cache and data cache to speed-up PHP-based web application in general. TileCache solution offers faster map generation and lower resource consumption.

(2)

PENINGKATAN KINERJA SERVER APLIKASI WEB GIS

BERBASIS POSTGRESQL DAN MAPSERVER

AURIZA RAHMAD AKBAR

DEPARTEMEN ILMU KOMPUTER

FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM

INSTITUT PERTANIAN BOGOR

(3)

ABSTRACT

AURIZA RAHMAD AKBAR. Performance Improvement of Web GIS Application Server Based on PostgreSQL and MapServer. Under the direction of HARI AGUNG ADRIANTO.

The PHP MapScript-based web GIS application with a huge amount of geographic data is very slow to load. In this paper, we will scale-up the server to bring the real potential out of the hardware. We will also use caching technique to speed-up both the PHP scripts and the map generation, using APC (Alternative PHP Cache) and TileCache respectively. APC can be used as opcode cache and data cache to speed-up PHP-based web application in general. TileCache solution offers faster map generation and lower resource consumption.

(4)

PENINGKATAN KINERJA SERVER APLIKASI WEB GIS

BERBASIS POSTGRESQL DAN MAPSERVER

AURIZA RAHMAD AKBAR

Skripsi

sebagai salah satu syarat untuk memperoleh gelar

Sarjana Komputer pada

Departemen Ilmu Komputer

DEPARTEMEN ILMU KOMPUTER

FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM

INSTITUT PERTANIAN BOGOR

(5)

Judul Skripsi : Peningkatan Kinerja Server Aplikasi Web GIS Berbasis PostgreSQL dan MapServer

Nama : Auriza Rahmad Akbar

NIM : G64050089

Menyetujui: Dosen Pembimbing,

Hari Agung Adrianto, S.Kom, M.Si NIP: 19760917 200501 1 001

Mengetahui: Ketua Departemen,

Dr. Ir. Sri Nurdiati, M.Sc NIP: 19601126 198601 2 001

(6)

PRAKATA

Alhamdulillaahi rabbil 'aalamiin, washshalaatu wassalaamu 'alaa rasuulillaah. Puji dan syukur penulis panjatkan kepada Allah subhaanahu wa ta'aala atas rahmat dan hidayah-Nya sehingga tugas akhir dengan judul “Peningkatan Kinerja Server Aplikasi Web GIS Berbasis PostgreSQL dan MapServer” ini dapat diselesaikan dengan baik. Penelitian ini dilaksanakan dari bulan Maret hingga Juni 2011, bertempat di Pusat Pengkajian Perencanaan dan Pengembangan Wilayah (P4W) LPPM IPB Kampus Baranangsiang dengan menggunakan server dari PT. Sucofindo.

Terima kasih penulis sampaikan kepada bapak Hari Agung atas bimbingan dan arahannnya selama pengerjaan tugas akhir ini, serta bapak Toto Haryanto dan bapak Hendra Rahmawan yang telah banyak memberikan kritik dan saran selama pengujian tugas akhir ini. Penulis juga mengucapkan terima kasih kepada semua pihak yang telah membantu dalam penyelesaian tugas akhir ini. Semoga karya ilmiah ini bermanfaat.

Bogor, Oktober 2011

(7)

RIWAYAT HIDUP

Penulis dilahirkan pada tanggal 5 Maret 1987 di Demak sebagai anak pertama dari empat bersaudara dari pasangan Sukid Raharjo dan Sudarmi. Penulis lulus dari SMA Negeri 1 Surakarta pada tahun 2005.

(8)

DAFTAR ISI

Halaman

DAFTAR TABEL...vii

DAFTAR GAMBAR...vii

PENDAHULUAN Latar Belakang...1

Tujuan...1

Ruang Lingkup...1

TINJAUAN PUSTAKA PostgreSQL...1

PostGIS...1

MapServer...1

TileCache...1

OpenLayers...1

Scale-up...1

Benchmarking...2

METODOLOGI PENELITIAN Aplikasi Web GIS dan Data Geografis...2

Prosedur Benchmark...2

HASIL DAN PEMBAHASAN Lingkungan Pengujian...3

Spesifikasi Server...3

Sistem Operasi...3

Waktu Eksekusi PHP...3

Konsumsi RAM...3

Kinerja Awal...4

PostgreSQL...4

Scale-up...4

Koneksi Maksimum...5

Memori Kerja...5

Apache...5

Scale-up...5

Keep Alive...5

Directory Index...6

Mematikan Modul AutoIndex dan CGI...6

Hasil Keseluruhan...6

PHP...6

Perbaiki Pesan Peringatan...7

Perbaiki Include Path...7

Opcode Cache...7

Data Cache...7

Hindari Include Once...8

Data Cache Parametrik...8

MapServer...9

Koneksi Database...9

Proyeksi...10

Level of Detail (LOD)...10

Indeks GiST...10

TileCache...11

Implementasi...11

Cara Kerja...11

(9)

Halaman

Metode Benchmark...12 Konfigurasi OpenLayers...12 Hasil Benchmark...12 KESIMPULAN DAN SARAN

(10)

DAFTAR TABEL

Halaman

1. Konsumsi RAM per proses...4

2. Kinerja server awal...4

3. Kinerja server setelah scale-up PostgreSQL...4

4. Kinerja server setelah scale-up Apache...5

5. Kinerja server setelah menurunkan KeepAliveTimeout Apache...6

6. Kinerja server setelah mematikan modul AutoIndex dan CGI Apache...6

7. Kinerja server setelah memperbaiki pesan peringatan PHP...7

8. Kinerja server setelah memperbaiki include path PHP...7

9. Kinerja server setelah instalasi APC...7

10. Kinerja server setelah implementasi data cache...8

11. Kinerja server setelah penggantian include_once...8

12. Kinerja server setelah implementasi data cache parametrik...9

13. Perbandingan kinerja server WMS MapServer dengan TileCache...12

DAFTAR GAMBAR Halaman 1. Prosedur benchmark...2

2. Alokasi RAM server...4

3. Kinerja server sebelum dan setelah scale-up PostgreSQL untuk halaman peta...5

4. Kinerja server setelah konfigurasi Apache untuk halaman peta...6

5. Kinerja server setelah konfigurasi Apache untuk halaman indeks...6

6. Kinerja server setelah konfigurasi PHP untuk halaman peta...9

7. Kinerja server setelah konfigurasi PHP untuk halaman indeks...9

8. Peta sebelum implementasi LOD...10

9. Peta setelah implementasi LOD...10

10. Peta pada extent tertentu...11

11. Perbandingan kecepatan MapServer setelah konfigurasi...11

12. Perbandingan arsitektur web GIS...11

13. Tile peta untuk objek benchmark...12

(11)

PENDAHULUAN Latar Belakang

Aplikasi web GIS (Geographic Information System) 'Scibun' yang dikembangkan oleh PT. Sucofindo untuk Kementerian Pertanian memiliki data geografis yang besar, yaitu hampir 600 MB dalam bentuk teks SQL. Data geografis tersebut merupakan data perkebunan kelapa sawit, karet, dan kakao di hampir seluruh provinsi di Indonesia. Dengan data sebesar itu, waktu yang diperlukan oleh Scibun untuk menggambar peta sangat lama, bisa lebih dari 10 detik.

Oleh karena itu, perlu dilakukan konfigurasi untuk meningkatkan kinerja server. Scibun menggunakan PostgreSQL untuk menyimpan data geografis dan MapServer (PHP MapScript) untuk menggambar peta.

Tujuan

Penelitian ini bertujuan untuk meningkatkan kinerja server sehingga aplikasi web GIS

2. Konfigurasi server difokuskan pada aplikasi server PostgreSQL, Apache, PHP, dan MapServer.

3. TileCache dan OpenLayers akan dicoba sebagai aplikasi web GIS alternatif.

4. Benchmark dilakukan pada jaringan

loopback.

TINJAUAN PUSTAKA PostgreSQL

PostgreSQL adalah ORDBMS (Object Relational Database Management System) open source dengan reputasi yang baik dalam kehandalan, integritas data, dan correctness. PostgreSQL dapat berjalan pada sistem operasi Linux, UNIX, maupun Windows. PostgreSQL mendukung penuh ACID (atomicity, consistency, isolation, durability) dan sebagian besar standar ANSI SQL 92/2003. PostgreSQL juga menyediakan antarmuka pemrograman

untuk berbagai bahasa serta dokumentasi yang lengkap. PostgreSQL sangat scalable, mampu menangani kuantitas data yang besar dan mengakomodasi banyak pengguna secara konkuren (PostgreSQL Global Development Group 2009).

PostGIS

PostGIS menambahkan dukungan untuk objek geografis pada PostgreSQL. PostGIS menjadikan server PostgreSQL dapat digunakan sebagai database spasial untuk sistem informasi geografis. PostGIS mendukung standar fungsi, tipe data, dan operasi database spasial dari OGC (Open Geospatial Consortium) (PostGIS Team 2010).

MapServer

MapServer adalah program penggambar data geografis open source yang ditulis dalam bahasa C. MapServer mendukung berbagai dikembangkan oleh MetaCarta. TileCache hanya membutuhkan akses tulis ke harddisk, kemampuan menjalankan skrip CGI Python, dan WMS yang akan di-cache untuk dapat membuat cache dari server WMS apapun. Hasilnya kemudian dapat ditampilkan pada klien yang mendukung WMS-C, seperti OpenLayers (TileCache 2010).

OpenLayers

OpenLayers adalah pustaka JavaScript open source untuk menampilkan data peta pada web browser modern. OpenLayers menyediakan API JavaScript untuk membuat aplikasi web GIS yang interaktif seperti Google Maps (OpenLayers 2011).

Scale-up

(12)

Benchmarking

Meskipun sering dikritik, benchmark adalah cara yang efektif dan terjangkau dalam menjalankan eksperimen. Intinya, benchmark

adalah sebuah sampel dari suatu domain tugas; sampel ini kemudian dieksekusi oleh komputer. Pengukuran kinerja dilakukan selama proses eksekusi. Sebuah benchmark menyediakan medan yang setara untuk ide-ide yang saling berlawanan, dan jika benchmark tersebut cukup representatif, benchmark dapat menghasilkan perbandingan yang dapat diulang dan objektif. Paling tidak, benchmark dapat menyingkirkan pendekatan yang keliru dan klaim yang berlebihan (Tichy 1997).

METODOLOGI PENELITIAN Aplikasi Web GIS dan Data Geografis

Aplikasi web GIS Scibun digunakan untuk menguji kinerja server. Scibun ditulis dalam bahasa PHP dan menggunakan ekstensi PHP MapScript untuk menggambar peta.

Data geografis yang digunakan adalah hasil survey perkebunan oleh PT. Sucofindo. Namun, halaman peta yang diuji hanya peta awal, yaitu peta administrasi yang terdiri dari tiga layer

data geografis, yaitu provinsi, kabupaten, dan jalan. Hal ini dilakukan karena pada saat penelitian, data pada layer perkebunan belum lengkap seluruhnya.

Selain halaman peta, halaman awal (indeks) Scibun juga digunakan untuk menguji kinerja server. Hal ini dilakukan supaya tidak hanya halaman peta saja yang menjadi lebih cepat, tetapi juga untuk keseluruhan halaman aplikasi web.

Prosedur Benchmark

Benchmark dilakukan secara sistematis, yaitu dengan mengkonfigurasi satu opsi dalam satu waktu, kemudian dibandingkan hasilnya. Tidak semua opsi diuji, hanya beberapa opsi yang dianggap mempengaruhi kinerja server saja. Jika ternyata hasil konfigurasi untuk opsi tersebut meningkatkan kinerja server, maka konfigurasi tersebut akan tetap dipertahankan. Tetapi jika tidak, konfigurasi pada opsi tersebut dikembalikan seperti semula. Diagram alur untuk prosedur benchmark untuk satu iterasi dapat dilihat pada Gambar 1.

Penjelasan dari langkah-langkah diagram alur pada Gambar 1 di atas adalah sebagai berikut:

• Tuning: mengkonfigurasi salah satu opsi pada aplikasi server.

• Benchmark: menjalankan program

benchmark untuk mengukur kinerja server.

• Faster?: membandingkan kinerja server setelah konfigurasi dengan yang sebelumnya. Kinerja server diukur dengan metrik transaction per second.

• Rollback: jika ternyata hasil konfigurasi tidak meningkatkan kinerja server, maka konfigurasi opsi tersebut dikembalikan seperti semula dan kembali melakukan

tuning.

Benchmark dilakukan pada setiap komponen aplikasi server. Urutan komponen server yang akan dikonfigurasi adalah PostgreSQL, Apache, PHP, dan MapServer. TileCache akan dicoba jika semua komponen di atas telah dikonfigurasi secara optimal.

Secara umum, program 'siege' digunakan

untuk mensimulasikan pengguna dalam waktu bersamaan (konkuren). Benchmark dilakukan pada tingkat konkurensi pengguna 4, 8, 16, 32, 64, 128, 256, dan 512. Jika benchmark pada tingkat konkurensi tertentu terjadi kegagalan transaksi lebih dari 1%, maka benchmark

dihentikan. Artinya, server tidak dapat melayani permintaan pada tingkat konkurensi tersebut dengan baik. Metrik yang dibandingkan dari hasil benchmark ini adalah nilai transaction per second.

(13)

Opsi benchmark dibedakan antara halaman peta dengan halaman indeks. Benchmark pada halaman peta hanya dilakukan sebanyak empat kali permintaan karena loading halaman ini cukup lama, sedangkan benchmark pada halaman indeks dilakukan selama 60 detik.

Benchmark dilakukan sebanyak tiga kali ulangan pada tiap tingkat konkurensi, kemudian diambil rataannya. Di antara tiap ulangan, diberikan jeda 30 detik agar jumlah proses anak server PostgreSQL dan Apache kembali normal. Server tidak di-restart supaya cache aplikasi web tetap ada. Jika cache hilang, kinerja server akan menurun dan mempengaruhi hasil

benchmark. Berikut adalah contoh skrip shell

untuk mengotomatisasi prosedur benchmark

seperti di atas.

#!/bin/bash

MAP="http://localhost/scibun/map.php" IDX="http://localhost/scibun/index.php" for c in 4 8 16 32 64 128 256 512; do echo "konkurensi = $c"

for i in 1 2 3; do prosesor dengan arsitektur 64-bit (x86-64). Jumlah RAM pada server ini adalah 2 GB.

Scale-up perlu dilakukan pada server untuk memanfaatkan jumlah RAM ini secara optimal. Berikut adalah spesifikasi server ini.

Name: Extron NetSystem E400

CPU: Intel Xeon E5606 Quad Core 2.13 GHz RAM: UDIMM DDR3 2 GB - 1333 ECC

Harddisk: SATA 500 GB, 7200 RPM Network: 2x Gigabit Ethernet NIC

Kecepatan tulis dan baca harddisk pada server adalah 88 MB/s dan 107 MB/s. Metode pengukuran kecepatan harddisk dilakukan menggunakan program 'dd' dengan perintah di bawah ini.

# dd if=/dev/zero of=bigfile bs=8k \ count=500000 && sync

# dd if=bigfile of=/dev/null bs=8k

Nilai count didapat dari jumlah total RAM dikalikan dua, kemudian dibagi dengan bs

(blocksize) sebesar 8 kB. Tujuan dari besar file

dua kali dari jumlah RAM adalah untuk menghindari disk caching ke RAM.

S

istem Operasi

Sistem operasi yang dipilih untuk server ini adalah Debian GNU/Linux 6.0, kernel 2.6.32-5-amd64. Debian merupakan distribusi GNU/Linux yang banyak digunakan sebagai server web. Menurut data survei bulan Juni 2011 dari W3Techs, 9.3% situs web tersibuk di dunia memakai Debian.

Perangkat lunak server memakai distribusi 64-bit. Keuntungan arsitektur 64-bit dari segi kinerja adalah kecepatan server akan meningkat. Kinerja server Apache meningkat 39.2% dengan menggunakan perangkat lunak 64-bit (Tonkikh 2006).

Server hanya diinstal perangkat lunak yang dibutuhkan. Semua paket aplikasi diunduh dari repositori resmi Debian dengan pilihan distribusi versi stable. Aplikasi server yang dipakai pada server ini antara lain:

• PostgreSQL 8.4.7

Nilai waktu eksekusi maksimum skrip PHP

default adalah 30 detik. Karena permintaan data spasial yang berukuran besar, maka waktu 30 detik ini terkadang tidak cukup, sehingga banyak permintaan yang terhenti di tengah jalan dan mengakibatkan kegagalan akses. Untuk mengatasinya, opsi waktu eksekusi maksimum ditambah menjadi 60 detik. Berikut adalah perintah untuk mengubah opsi ini.

(14)

Tabel 1. Konsumsi RAM per proses dapat dilihat pada Tabel 2. Server hanya mampu melayani permintaan halaman peta dengan baik sampai tingkat konkurensi 16. Kinerja server menurun drastis pada tingkat konkurensi 32. Adapun untuk halaman indeks, server masih mampu melayani permintaan untuk tingkat konkurensi yang lebih tinggi lagi.

Tabel 2. Kinerja server awal

Konkurensi Peta Indeks

Konfigurasi server PostgreSQL terletak pada

/etc/postgresql/8.4/main/postgresql.conf.

Penjelasan dari PostgreSQL Global Develop-ment Group (2009) mengenai opsi-opsi yang akan dikonfigurasi adalah sebagai berikut:

• shared_buffers: Opsi ini mengatur jumlah RAM yang dialokasikan sebagai shared buffer. Nilai yang disarankan adalah 25% dari jumlah RAM yang tersedia. Nilai awalnya adalah 24 MB.

• effective_cache_size: Opsi ini menunjuk-kan ukuran cache yang tersedia bagi query planner. Jika cache mencukupi, maka akan digunakan index scan daripada sequential scan biasa. Nilai awalnya adalah 128 MB.

• max_connections: Opsi ini mengatur jumlah koneksi maksimum yang dapat dilayani oleh server dalam satu waktu. Opsi ini digunakan untuk meminimalkan disk swapping. Nilai awalnya adalah 100.

• work_mem: Opsi ini mengatur jumlah RAM

yang dialokasikan untuk operasi sorting

internal. Nilai awalnya adalah 1 MB.

Scale-up

shared_buffers = 256MB effective_cache_size = 768MB max_connections = 32

Konfigurasi PostgreSQL perlu dilakukan

scale-up untuk memanfaatkan RAM pada server secara optimal. Alokasi RAM server dapat dilihat pada Gambar 2. Jumlah RAM yang dialokasikan untuk PostgreSQL dan sistem operasi adalah 1024 MB. Nilai shared_buffers

adalah 25%-nya, yaitu 256 MB. Nilai

effective_cache_size adalah 75%-nya, yaitu

768 MB (Smith 2010). Nilai max_connections

didapat dari jumlah alokasi RAM untuk PostgreSQL dibagi dengan rataan konsumsi RAM per proses PostgreSQL (Temme 2007). Jika tidak terjadi swapping, maka nilai ini dapat dinaikkan lagi.

koneksi_max= alokasi RAM konsumsi RAM per proses

Dari rumus di atas, didapat nilai

max_connections: 768 MB / ((50+6)/2) MB = 768 / 28 ≈ 27. Setelah dilakukan benchmark, ternyata masih ada RAM yang tersisa, sehingga nilai max_connections dapat dinaikkan lagi. Pada saat max_connections 32, penggunaan

RAM sudah optimal tanpa terjadi swapping. Hasil konfigurasi ini dapat dilihat pada Tabel 3 dan Gambar 3. Kinerja server secara umum sama seperti kondisi awal. Akan tetapi, server sekarang mampu melayani permintaan halaman peta dengan baik sampai tingkat konkurensi 256. Artinya, konfigurasi scale-up

ini telah berhasil memperbaiki kemampuan server dalam melayani permintaan pada konkurensi yang lebih tinggi.

Tabel 3. Kinerja server setelah scale-up

PostgreSQL

(15)

Koneksi Maksimum menyebabkan swapping berlebihan. Akibatnya, server menjadi sangat lambat, karena prosesor harus berulang kali mengambil data dari swap disk.

Jadi, jumlah koneksi perlu dibatasi agar server tetap berjalan optimal. Jika permintaan melebihi jumlah koneksi, maka kelebihan permintaan tersebut langsung ditolak, sehingga tidak mengganggu jalannya permintaan lain server. Hal ini disebabkan query data geografis ke server PostgreSQL tidak terdapat operasi

sorting yang kompleks.

Apache

Konfigurasi utama server web Apache terletak pada /etc/apache2/apache2.conf. Penjelasan dari Apache Software Foundation (2008) mengenai opsi-opsi yang akan dikonfigurasi adalah sebagai berikut:

• MaxClients: Opsi ini mengatur jumlah koneksi maksimum yang dapat diproses

secara konkuren. Nilai ini juga menunjukkan jumlah proses anak maksimum yang dapat dibuat untuk melayani permintaan. Nilai awalnya adalah 100.

• KeepAliveTimeout: Opsi ini mengatur berapa detik server akan menunggu untuk melayani permintaan selanjutnya dari koneksi yang sama, sebelum koneksi tersebut diputus. Nilai awalnya adalah 15.

• DirectoryIndex: Opsi ini berisi urutan daftar berkas yang akan ditampilkan jika klien mengakses sebuah direktori. Urutan awalnya adalah: index.html, index.cgi, index.pl, klien maksimum ini didapat dari alokasi RAM untuk Apache dibagi dengan dengan konsumsi RAM per proses Apache (Temme 2007). Hasil perhitungan untuk jumlah klien maksimum adalah sebagai berikut: 1024 MB / 16 MB = 64.

Hasil scale-up dapat dilihat pada Tabel 4. Kinerja server meningkat secara signifikan pada tingkat konkurensi di atas 64. Kinerja halaman peta dan indeks masing-masing meningkat 5% dan 10%.

Tabel 4. Kinerja server setelah scale-up Apache

Penurunan waktu KeepAliveTimeout hanya

sedikit meningkatkan kinerja server. Hasilnya dapat dilihat pada Tabel 5. Kinerja halaman peta dan indeks masing-masing meningkat 2% dan 0.3% pada tingkat konkurensi 64 ke atas.

Hal ini dikarenakan benchmark server hanya dilakukan di localhost saja, sehingga efek jaringan tidak terlihat. KeepAlive sangat berguna bagi halaman yang memiliki banyak objek berukuran kecil dan bagi klien yang memiliki koneksi internet yang lambat.

Gambar 3. Kinerja server sebelum dan setelah

scale-up PostgreSQL untuk halaman peta.

(16)

Tabel 5. Kinerja server setelah menurunkan direktori saja, misalnya http://localhost/scibun/. Server kemudian melihat opsi ini untuk mencari berkas indeks yang akan ditampilkan. Karena langsung sebesar 0.4% pada tingkat konkurensi 128.

Mematikan Modul AutoIndex dan CGI

# a2dismod autoindex cgi

Modul Apache yang tidak digunakan sebaiknya dimatikan, karena modul ini akan menambah konsumsi RAM per proses Apache. Selain itu, modul AutoIndex juga dapat menjadi celah keamanan bagi server. Jika modul ini aktif, klien dapat menjelajahi isi direktori server dengan leluasa.

Hasil konfigurasi ini dapat dilihat pada Tabel 6. Kinerja halaman peta dan indeks masing-masing meningkat 5% dan 0.2% pada tingkat konkurensi 64 ke atas.

Tabel 6. Kinerja server setelah mematikan modul AutoIndex dan CGI Apache

meningkat setelah dilakukan beberapa konfigurasi di atas. Perbandingan kinerja server sebelum dan sesudah konfigurasi Apache untuk halaman peta dan indeks dapat dilihat masing-masing pada Gambar 4 dan 5. Kinerja server untuk halaman indeks juga menjadi lebih stabil pada tingkat konkurensi di atas 64.

PHP

Konfigurasi PHP secara umum dilakukan dengan cara mengubah kode sumber PHP Scibun. Pengubahan ini diusahakan seminimal mungkin tanpa mengubah fungsi aplikasi web. Selain itu juga ditambahkan modul caching

pada PHP untuk meningkatkan kinerja server. Gambar 4. Kinerja server setelah konfigurasi

Apache untuk halaman peta.

(17)

Perbaiki Pesan Peringatan melaporkan pesan peringatan. Potongan kode di bawah ini perlu ditambahkan pada bagian paling atas kode sumber PHP supaya hanya pesan kesalahan yang akan dilaporkan.

<?php

error_reporting(E_ERROR); ?>

Hasil perbaikan ini dapat dilihat pada Tabel 7. Kinerja halaman peta dan indeks masing-masing meningkat 1.6% dan 0.3% pada tingkat konkurensi 64 ke atas. Tapi perlu diingat bahwa solusi di atas adalah solusi sementara. Solusi yang ideal adalah dengan memperbaiki semua pesan peringatan sehingga kinerja dan keamanan aplikasi web meningkat.

Tabel 7. Kinerja server setelah memperbaiki pesan peringatan PHP

Setelah menelusuri system call Apache pada halaman indeks, ternyata ada satu include path

yang kurang tepat. Akibatnya PHP akan

Hasil perbaikan ini dapat dilihat pada Tabel 8. Kinerja halaman indeks meningkat 0.3% pada tingkat konkurensi 64 ke atas, sedangkan untuk halaman peta tidak ditemukan include path yang bermasalah.

Tabel 8. Kinerja server setelah memperbaiki

include path PHP

PHP adalah interpreted language. Skrip PHP dikompilasi menjadi opcode untuk kemudian dijalankan oleh interpreter PHP. Hasil kompilasi ini perlu disimpan ke dalam suatu cache, sehingga server tidak perlu melakukan kompilasi ulang setiap kali halaman web diakses.

Salah satu implementasi opcode cache untuk PHP adalah APC (Alternative PHP Cache). APC akan menyimpan opcode hasil kompilasi ke dalam shared memory secara otomatis. Kinerja aplikasi web PHP semakin meningkat karena opcode disimpan di dalam RAM.

Pengaruh opcode cache pada Scibun dapat dilihat pada Tabel 9. Kinerja halaman peta dan indeks meningkat masing-masing 2% dan 76% pada tingkat konkurensi 64 sampai 256. Kinerja halaman peta hanya meningkat sedikit karena waktu prosesor lebih banyak digunakan untuk menggambar peta.

Tabel 9. Kinerja server setelah instalasi APC

Konkurensi Peta Indeks dari cache, sehingga kinerja server meningkat. Ekstensi PHP 'XDebug' dapat digunakan untuk mengidentifikasi bagian kode yang menjadi

(18)

kode PHP untuk mengambil daftar provinsi dari

database yang telah ditambahkan dengan fungsi APC.

public function getProvinsiList() { $result = apc_fetch('provinsi_list'); if ($result === FALSE) {

$sql = 'SELECT * FROM provinsi'; $result = $this->db->getAll($sql); apc_store('provinsi_list', $result); } masuknya query dari klien. Jadi teknik caching

peta ini hanya berlaku untuk gambar peta awal, tidak untuk keseluruhan halaman peta. Berikut adalah contoh potongan kode PHP untuk menggambar peta.

if ($this->gbShowQueryResults) { $img = $this->map->drawQuery(); $url = $img->saveWebImage(); } else {

$url = apc_fetch('initial_map_url'); if ($url === FALSE or

!file_exists($WEBROOT.$url)) { $img = $this->map->draw(); $url = $img->saveWebImage(); apc_store('initial_map_url', $url); }

}

Hasil implementasi data cache ini dapat dilihat pada Tabel 10. Kinerja rata-rata halaman peta meningkat tajam sebesar 128 kali lipat. Akan tetapi peningkatan kinerja ini hanya berlaku untuk halaman peta awal saja, yaitu peta administrasi. Teknik caching peta lainnya perlu dicari untuk mengatasi kekurangan tersebut.

Tabel 10. Kinerja server setelah implementasi

data cache

Pernyataan include_once dan require_once

akan memeriksa dulu apakah berkas sudah pernah disertakan sebelumnya atau tidak. Pernyataan ini sebaiknya diganti dengan pernyataan include biasa. Ekstensi PHP 'inclued' dapat digunakan untuk menelusuri hierarki include aplikasi web PHP.

Hasil penggantian include_once menjadi

include dapat dilihat pada Tabel 11. Kinerja halaman peta dan indeks meningkat masing-masing 0.3% dan 0.9%.

Tabel 11. Kinerja server setelah penggantian

include_once

Fungsi untuk mengambil data dari database

kebanyakan memakai parameter untuk memilih data yang diinginkan. Parameter tersebut dipakai dalam klausa WHERE pada query. Hasil dari fungsi ini dapat disimpan dalam

cache dengan teknik data cache parametrik. Berikut contoh fungsi PHP untuk mengambil daftar kabupaten dari database berdasarkan parameter provinsi. Nama parameter ditambahkan pada nama cache APC untuk membedakannya dari cache yang berjenis sama tetapi dengan parameter yang berbeda.

public function getKabupatenList($idprov) { $result = apc_fetch('kab_list'.$idprov); if ($result === FALSE) {

$sql = 'SELECT * FROM kabupaten '. 'WHERE idprov = '.$idprov; $result = $this->db->getAll($sql); apc_store('kab_list'.$idprov, $result); }

return $result; }

(19)

Tabel 12. Kinerja server setelah implementasi

APC sangat bermanfaat untuk meningkatkan kinerja server pada aplikasi web PHP. Pemakaian APC sebagai opcode dan data cache

dapat meningkatkan kinerja aplikasi web PHP

Prosedur benchmark MapServer berbeda dari prosedur sebelumnya. Benchmark

MapServer menggunakan program 'shp2img'

untuk menguji kinerja mapfile. Program ini dijalankan dalam mode debug sebanyak lima kali ulangan. Berikut adalah contoh penggunaan program ini serta keluarannya.

$ shp2img -m administrasi.map \ -map_debug 3 -c 5 -o out.png We will draw 5 times...

msDrawMap(): Layer 0 (provinsi), 4.858s msDrawMap(): Layer 1 (kabupaten), 0.558s msDrawMap(): Layer 2 (jalan), 5.106s msDrawMap(): Drawing Label Cache, 0.000s msDrawMap() total time: 10.524s

msSaveImage() total time: 0.056s ...

Opsi-opsi mapfile yang akan dikonfigurasi dijelaskan pada daftar berikut ini (MapServer Team 2011).

• PROCESSING "CLOSE_CONNECTION=DEFER": Jika opsi ini aktif, maka koneksi database Proyeksi dapat ditentukan dengan kata kunci PROJ.4 atau melalui kode EPSG.

• MAXSCALEDENOM: Jika penyebut skala peta melebihi nilai opsi ini, maka layer tidak akan digambar. Opsi ini dapat digunakan di dalam objek layer dan class.

Koneksi Database

Data geografis mapfile pada tiap layer

diambil dari database yang sama. Opsi

PROCESSING "CLOSE_CONNECTION=DEFER" harus

diaktifkan supaya koneksi database tidak langsung ditutup jika MapServer telah selesai menggambar satu layer. Koneksi ini dapat dimanfaatkan ulang, sehingga layer selanjutnya tidak perlu membuat koneksi baru ke database

yang sama. Berikut adalah contoh penulisan opsi ini pada mapfile.

Gambar 7. Kinerja server setelah konfigurasi PHP untuk halaman indeks.

(20)

LAYER ...

CONNECTIONTYPE POSTGIS DATA "the_geom FROM provinsi" PROCESSING "CLOSE_CONNECTION=DEFER" mengambil kata kunci PROJ.4 yang bersesuaian dengan kode EPSG. Jadi, kedua proyeksi tersebut pada dasarnya sama. Berikut adalah contoh dua cara penulisan objek proyeksi.

PROJECTION EPSG menambah waktu yang dibutuhkan oleh MapServer untuk menggambar peta sebesar 0.1%, dari 10.45 detik menjadi 10.47 detik. Jadi, penulisan objek proyeksi sebaiknya langsung memakai kata kunci PROJ.4.

Level of Detail (LOD)

Opsi MAXSCALEDENOM digunakan untuk mengimplementasikan LOD pada mapfile. Selain meningkatkan kinerja, LOD juga berfungsi untuk mengurangi kerumitan pada tampilan peta. Berikut adalah contoh penulisan opsi ini pada mapfile. Opsi ini dapat digunakan untuk objek layer maupun class. digambar, layer 'kabupaten' akan digambar jika skala peta melebihi 1:4 000 000, sedangkan

layer 'jalan' akan digambar jika skala peta melebihi 1:1 000 000.

Implementasi LOD mengurangi waktu yang diperlukan oleh MapServer untuk menggambar peta awal sebesar 54%, dari 10.45 detik menjadi 4.86 detik.

Indeks GiST

GiST (Generalized Search Tree) menyediakan indeks spasial untuk kolom geometris pada PostGIS. Indeks GiST bermanfaat untuk mempercepat pencarian data spasial. Berikut adalah contoh perintah SQL untuk membuat indeks GiST pada sebuah kolom geometris di tabel 'jalan' (PostGIS Team 2010).

# CREATE INDEX jalan_the_geom ON jalan USING GIST (the_geom);

# VACUUM ANALYZE jalan;

Benchmark pada mapfile dilakukan pada

extent peta tertentu. Hal ini dilakukan agar pengaruh indeks GiST terlihat. Jika seluruh peta yang digambar, maka indeks tidak akan dipakai. Berikut adalah perintah yang dipakai untuk menggambar peta pada extent tertentu saja. Hasil gambar peta dengan extent ini dapat dilihat pada Gambar 10.

$ shp2img -m administrasi.map \ -map_debug 3 -c 5 -o out.png \

-e 105.32259 -1.73887 105.66626 -1.56686

Gambar 8. Peta sebelum implementasi LOD.

(21)

Hasil pemakaian indeks GiST ini mengurangi waktu yang diperlukan oleh MapServer untuk menggambar peta sebesar 23%, dari 0.49 detik menjadi 0.38 detik.

Hasil Keseluruhan

Implementasi LOD mampu mengurangi waktu yang dibutuhkan MapServer untuk menggambar peta lebih dari 50%. Perbandingan kecepatan MapServer sebelum dan sesudah konfigurasi ditunjukkan pada Gambar 11.

Waktu loading halaman peta awal (tanpa menggunakan cache peta) berkurang dari 10 detik lebih menjadi 6 detik. Penggunaan indeks GiST juga mempercepat loading halaman peta saat di-zoom pada extent tertentu. Konfigurasi LOD dan indeks GiST ini sangat penting dalam meningkatkan kinerja MapServer.

TileCache

Pada pembahasan sebelumnya, metode

caching peta dengan APC masih memiliki kekurangan yang mendasar, yaitu tidak semua peta dapat dibuat cache-nya. TileCache adalah alternatif caching peta yang akan digunakan untuk mengatasi kekurangan tersebut.

Implementasi

Implementasi TileCache memerlukan arsitektur web GIS yang baru. Arsitektur lama dengan PHP MapScript sudah sulit untuk ditingkatkan lagi kinerjanya. Arsitektur baru ini semuanya mengimplementasikan standar OGC, yaitu server WMS MapServer, server WMS-C TileCache, dan klien WMS OpenLayers. Arsitektur web GIS ditunjukkan pada Gambar 12. Garis putus-putus menunjukkan arsitektur TileCache yang baru.

Server TileCache menggunakan modul CGI Apache. Program CGI MapServer juga perlu diinstal untuk menyediakan server WMS.

Mapfile juga harus ditambahkan dukungan untuk WMS. Selain itu ruang harddisk untuk menyimpan tile peta juga perlu dipersiapkan.

Cara Kerja

Jika TileCache sudah berjalan, maka semua

tile peta yang pernah diminta oleh klien akan disimpan ke dalam cache.

Seeding dan Pemrosesan Citra

Cache tile peta dapat dibangkitkan secara otomatis dengan program 'tilecache_seed'. Arsitektur TileCache pada Gambar 12 menggunakan metode ini. TileCache tidak perlu meminta tile peta ke server WMS, karena tile

peta sampai level zoom tertentu sudah ada semua di dalam cache.

Tile peta di dalam cache yang dihasilkan oleh proses seeding dapat diproses lebih lanjut. Program 'optipng' akan digunakan untuk klien dengan koneksi yang lambat.

Berikut adalah contoh perintah untuk

seeding dan optimisasi citra PNG. Gambar 10. Peta pada extent tertentu.

Gambar 12. Perbandingan arsitektur web GIS.

(22)

# tilecache_seed \

"http://localhost/cgi/tilecache.cgi?" \ administrasi 0 9 \

"95.0111,-12.267,141.007,6.0777" # cd /var/www/tilecache/

# chown -R www-data:www-data *

# find -name "*png" | nice xargs optipng -q

Metode Benchmark

Benchmark TileCache dilakukan dengan dua cara. Cara pertama: memakai ekstensi 'Firebug' untuk Firefox. Metrik yang dibandingkan adalah waktu loading halaman peta pada OpenLayers. Program siege tidak dapat dipakai karena OpenLayers menggunakan Ajax untuk meminta tile peta dari server, sehingga output

program siege menjadi tidak valid.

Cara kedua: program siege akan dipakai

dalam benchmark untuk satu permintaan tile

peta langsung ke server WMS MapServer dan TileCache. Metrik yang dibandingkan adalah nilai transaction per second.

Berikut adalah alamat WMS untuk tile peta tersebut. Alamat pertama akan meminta gambar peta dari server WMS MapServer. Alamat kedua akan meminta tile peta dari TileCache. Kedua alamat tersebut memiliki parameter yang sama, sehingga tile yang dihasilkan adalah sama. Skala tile peta ini adalah 1:28 000 000.

Tile peta yang digunakan sebagai objek

benchmark kedua ditunjukkan pada Gambar 13.

http://localhost/cgi-bin/administrasi

Konfigurasi server TileCache terletak pada

/etc/tilecache.cfg. Konfigurasi untuk layer

'administrasi' di atas adalah sebagai berikut.

[cache]

Konfigurasi OpenLayers yang digunakan dalam benchmark pertama yaitu:

• ukuran viewport: 1000 × 500 piksel

• ukuran tile: 256 × 256 piksel

• buffer: 0

Hasil Benchmark

Waktu yang diperlukan OpenLayers untuk menampilkan peta dari server WMS MapServer dan TileCache masing-masing adalah 5.04 detik dan 0.66 detik. TileCache mengurangi waktu

loading peta sebesar 87%.

Perbandingan kinerja TileCache dengan server WMS MapServer dalam melayani permintaan satu tile peta ditunjukkan pada Tabel 13 dan Gambar 14. Kinerja TileCache unggul 100 kali lipat dari server WMS pada tingkat konkurensi di bawah 32. Kinerja TileCache sangat stabil di setiap tingkat konkurensi.

Tabel 13. Perbandingan kinerja server WMS MapServer dengan TileCache

(23)

KESIMPULAN DAN SARAN

sesuai dengan jumlah RAM server.

2. Instalasi APC sebagai opcode dan data

Jika setelah mengikuti langkah-langkah di atas kinerja server masih kurang memuaskan, maka TileCache dapat digunakan sebagai alternatif. TileCache mampu meningkatkan kinerja (transaction per second) server WMS hingga 100 kali lipat. Akan tetapi, implementasi TileCache memerlukan arsitektur yang berbeda, sehingga solusi TileCache ini tidak bisa langsung ditambahkan ke dalam aplikasi web GIS berbasis PHP MapScript yang lama.

Saran

Kode sumber PHP perlu dikaji ulang untuk meningkatkan kinerja aplikasi web. Penggunaan pustaka PHP dan JavaScript yang berlebihan akan memperlambat kinerja aplikasi web. Selain itu perlu diterapkan frontend engineering

untuk meningkatkan responsivitas aplikasi web pada sisi klien. Documentation: Release 5.6.6. http://mapserver.org/MapServer-56.pdf

OpenLayers. 2011. OpenLayers: Free Maps for The Web. http://openlayers.org/ [29 Juni 2011]

PostGIS Team. 2010. PostGIS 1.5.1 Manual. http://postgis.refractions.net/download/postg is-1.5.1.pdf

PostgreSQL Global Development Group. 2009.

PostgreSQL 8.4.6 Documentation. http://www.postgresql.org/files/documentati on/pdf/8.4/postgresql-8.4.6-A4.pdf

Smith G. 2010. Server Configuration Tuning in PostgreSQL.

Caching. http://tilecache.org/ [29 Juni 2011] Tonkikh A. 2006. Benchmarks: AMD64 in 32bit

mode vs 64bit mode.

(24)

Tujuan

loopback.

PostGIS

MapServer

OpenLayers

Scale-up

(25)

Tujuan

loopback.

PostGIS

MapServer

OpenLayers

Scale-up

(26)

Benchmarking

tuning.

(27)

Benchmarking

tuning.

(28)

seperti di atas.

#!/bin/bash

S

istem Operasi

(29)

seperti di atas.

#!/bin/bash

S

istem Operasi

(30)

Tabel 1. Konsumsi RAM per proses dapat dilihat pada Tabel 2. Server hanya mampu melayani permintaan halaman peta dengan baik sampai tingkat konkurensi 16. Kinerja server menurun drastis pada tingkat konkurensi 32. Adapun untuk halaman indeks, server masih mampu melayani permintaan untuk tingkat konkurensi yang lebih tinggi lagi.

Tabel 2. Kinerja server awal

Konfigurasi server PostgreSQL terletak pada

/etc/postgresql/8.4/main/postgresql.conf.

Penjelasan dari PostgreSQL Global Develop-ment Group (2009) mengenai opsi-opsi yang akan dikonfigurasi adalah sebagai berikut:

• shared_buffers: Opsi ini mengatur jumlah RAM yang dialokasikan sebagai shared buffer. Nilai yang disarankan adalah 25% dari jumlah RAM yang tersedia. Nilai awalnya adalah 24 MB.

• effective_cache_size: Opsi ini menunjuk-kan ukuran cache yang tersedia bagi query planner. Jika cache mencukupi, maka akan digunakan index scan daripada sequential scan biasa. Nilai awalnya adalah 128 MB.

• max_connections: Opsi ini mengatur jumlah koneksi maksimum yang dapat dilayani oleh server dalam satu waktu. Opsi ini digunakan untuk meminimalkan disk swapping. Nilai awalnya adalah 100.

• work_mem: Opsi ini mengatur jumlah RAM

yang dialokasikan untuk operasi sorting

internal. Nilai awalnya adalah 1 MB.

Scale-up

shared_buffers = 256MB effective_cache_size = 768MB max_connections = 32

Konfigurasi PostgreSQL perlu dilakukan

scale-up untuk memanfaatkan RAM pada server secara optimal. Alokasi RAM server dapat dilihat pada Gambar 2. Jumlah RAM yang dialokasikan untuk PostgreSQL dan sistem operasi adalah 1024 MB. Nilai shared_buffers

adalah 25%-nya, yaitu 256 MB. Nilai

effective_cache_size adalah 75%-nya, yaitu

768 MB (Smith 2010). Nilai max_connections

didapat dari jumlah alokasi RAM untuk PostgreSQL dibagi dengan rataan konsumsi RAM per proses PostgreSQL (Temme 2007). Jika tidak terjadi swapping, maka nilai ini dapat dinaikkan lagi.

koneksi_max= alokasi RAM konsumsi RAM per proses

Dari rumus di atas, didapat nilai

max_connections: 768 MB / ((50+6)/2) MB = 768 / 28 ≈ 27. Setelah dilakukan benchmark, ternyata masih ada RAM yang tersisa, sehingga nilai max_connections dapat dinaikkan lagi. Pada saat max_connections 32, penggunaan

RAM sudah optimal tanpa terjadi swapping. Hasil konfigurasi ini dapat dilihat pada Tabel 3 dan Gambar 3. Kinerja server secara umum sama seperti kondisi awal. Akan tetapi, server sekarang mampu melayani permintaan halaman peta dengan baik sampai tingkat konkurensi 256. Artinya, konfigurasi scale-up

ini telah berhasil memperbaiki kemampuan server dalam melayani permintaan pada konkurensi yang lebih tinggi.

Tabel 3. Kinerja server setelah scale-up

PostgreSQL

(31)

Koneksi Maksimum menyebabkan swapping berlebihan. Akibatnya, server menjadi sangat lambat, karena prosesor harus berulang kali mengambil data dari swap disk.

Jadi, jumlah koneksi perlu dibatasi agar server tetap berjalan optimal. Jika permintaan melebihi jumlah koneksi, maka kelebihan permintaan tersebut langsung ditolak, sehingga tidak mengganggu jalannya permintaan lain server. Hal ini disebabkan query data geografis ke server PostgreSQL tidak terdapat operasi

sorting yang kompleks.

Apache

Konfigurasi utama server web Apache terletak pada /etc/apache2/apache2.conf. Penjelasan dari Apache Software Foundation (2008) mengenai opsi-opsi yang akan dikonfigurasi adalah sebagai berikut:

• MaxClients: Opsi ini mengatur jumlah koneksi maksimum yang dapat diproses

secara konkuren. Nilai ini juga menunjukkan jumlah proses anak maksimum yang dapat dibuat untuk melayani permintaan. Nilai awalnya adalah 100.

• KeepAliveTimeout: Opsi ini mengatur berapa detik server akan menunggu untuk melayani permintaan selanjutnya dari koneksi yang sama, sebelum koneksi tersebut diputus. Nilai awalnya adalah 15.

• DirectoryIndex: Opsi ini berisi urutan daftar berkas yang akan ditampilkan jika klien mengakses sebuah direktori. Urutan awalnya adalah: index.html, index.cgi, index.pl, klien maksimum ini didapat dari alokasi RAM untuk Apache dibagi dengan dengan konsumsi RAM per proses Apache (Temme 2007). Hasil perhitungan untuk jumlah klien maksimum adalah sebagai berikut: 1024 MB / 16 MB = 64.

Hasil scale-up dapat dilihat pada Tabel 4. Kinerja server meningkat secara signifikan pada tingkat konkurensi di atas 64. Kinerja halaman peta dan indeks masing-masing meningkat 5% dan 10%.

Tabel 4. Kinerja server setelah scale-up Apache

Penurunan waktu KeepAliveTimeout hanya

sedikit meningkatkan kinerja server. Hasilnya dapat dilihat pada Tabel 5. Kinerja halaman peta dan indeks masing-masing meningkat 2% dan 0.3% pada tingkat konkurensi 64 ke atas.

Hal ini dikarenakan benchmark server hanya dilakukan di localhost saja, sehingga efek jaringan tidak terlihat. KeepAlive sangat berguna bagi halaman yang memiliki banyak objek berukuran kecil dan bagi klien yang memiliki koneksi internet yang lambat.

Gambar 3. Kinerja server sebelum dan setelah

scale-up PostgreSQL untuk halaman peta.

(32)

Tabel 5. Kinerja server setelah menurunkan direktori saja, misalnya http://localhost/scibun/. Server kemudian melihat opsi ini untuk mencari berkas indeks yang akan ditampilkan. Karena langsung sebesar 0.4% pada tingkat konkurensi 128.

Mematikan Modul AutoIndex dan CGI

# a2dismod autoindex cgi

Modul Apache yang tidak digunakan sebaiknya dimatikan, karena modul ini akan menambah konsumsi RAM per proses Apache. Selain itu, modul AutoIndex juga dapat menjadi celah keamanan bagi server. Jika modul ini aktif, klien dapat menjelajahi isi direktori server dengan leluasa.

Hasil konfigurasi ini dapat dilihat pada Tabel 6. Kinerja halaman peta dan indeks masing-masing meningkat 5% dan 0.2% pada tingkat konkurensi 64 ke atas.

Tabel 6. Kinerja server setelah mematikan modul AutoIndex dan CGI Apache

meningkat setelah dilakukan beberapa konfigurasi di atas. Perbandingan kinerja server sebelum dan sesudah konfigurasi Apache untuk halaman peta dan indeks dapat dilihat masing-masing pada Gambar 4 dan 5. Kinerja server untuk halaman indeks juga menjadi lebih stabil pada tingkat konkurensi di atas 64.

PHP

Konfigurasi PHP secara umum dilakukan dengan cara mengubah kode sumber PHP Scibun. Pengubahan ini diusahakan seminimal mungkin tanpa mengubah fungsi aplikasi web. Selain itu juga ditambahkan modul caching

pada PHP untuk meningkatkan kinerja server. Gambar 4. Kinerja server setelah konfigurasi

Apache untuk halaman peta.

(33)

Perbaiki Pesan Peringatan melaporkan pesan peringatan. Potongan kode di bawah ini perlu ditambahkan pada bagian paling atas kode sumber PHP supaya hanya pesan kesalahan yang akan dilaporkan.

<?php

error_reporting(E_ERROR); ?>

Hasil perbaikan ini dapat dilihat pada Tabel 7. Kinerja halaman peta dan indeks masing-masing meningkat 1.6% dan 0.3% pada tingkat konkurensi 64 ke atas. Tapi perlu diingat bahwa solusi di atas adalah solusi sementara. Solusi yang ideal adalah dengan memperbaiki semua pesan peringatan sehingga kinerja dan keamanan aplikasi web meningkat.

Tabel 7. Kinerja server setelah memperbaiki pesan peringatan PHP

Setelah menelusuri system call Apache pada halaman indeks, ternyata ada satu include path

yang kurang tepat. Akibatnya PHP akan

Hasil perbaikan ini dapat dilihat pada Tabel 8. Kinerja halaman indeks meningkat 0.3% pada tingkat konkurensi 64 ke atas, sedangkan untuk halaman peta tidak ditemukan include path yang bermasalah.

Tabel 8. Kinerja server setelah memperbaiki

include path PHP

PHP adalah interpreted language. Skrip PHP dikompilasi menjadi opcode untuk kemudian dijalankan oleh interpreter PHP. Hasil kompilasi ini perlu disimpan ke dalam suatu cache, sehingga server tidak perlu melakukan kompilasi ulang setiap kali halaman web diakses.

Salah satu implementasi opcode cache untuk PHP adalah APC (Alternative PHP Cache). APC akan menyimpan opcode hasil kompilasi ke dalam shared memory secara otomatis. Kinerja aplikasi web PHP semakin meningkat karena opcode disimpan di dalam RAM.

Pengaruh opcode cache pada Scibun dapat dilihat pada Tabel 9. Kinerja halaman peta dan indeks meningkat masing-masing 2% dan 76% pada tingkat konkurensi 64 sampai 256. Kinerja halaman peta hanya meningkat sedikit karena waktu prosesor lebih banyak digunakan untuk menggambar peta.

Tabel 9. Kinerja server setelah instalasi APC

Konkurensi Peta Indeks dari cache, sehingga kinerja server meningkat. Ekstensi PHP 'XDebug' dapat digunakan untuk mengidentifikasi bagian kode yang menjadi