Peningkatan Kinerja Server Aplikasi Web GIS Berbasis PostgreSQL dan MapServer
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.
Keywords: server, performance, web GIS, mapserver, postgresql, tilecache.
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
BOGOR
2011
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.
Keywords: server, performance, web GIS, mapserver, postgresql, tilecache.
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
BOGOR
2011
Judul Skripsi
Nama
NIM
: Peningkatan Kinerja Server Aplikasi Web GIS Berbasis PostgreSQL dan
MapServer
: Auriza Rahmad Akbar
: 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
Tanggal Lulus:
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
Auriza Rahmad Akbar
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.
Pada tahun yang sama, penulis diterima sebagai mahasiswa Institut Pertanian Bogor (IPB) melalui
jalur USMI. Penulis kemudian memilih jurusan Ilmu Komputer setelah menyelesaikan tahun
pertamanya di IPB. Pada tahun 2008, penulis melaksanakan kegiatan praktik lapang di Lembaga
Pengembangan Insani selama dua bulan. Penulis pernah menjadi asisten mata kuliah Pemrosesan
Paralel pada tahun akademik 2008/2009. Selama mengerjakan skripsi, penulis juga membantu
instalasi dan integrasi aplikasi web GIS Scibun yang dikembangkan oleh PT. Sucofindo ke dalam
server Linux.
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
Hasil Keseluruhan..............................................................................................................9
MapServer...............................................................................................................................9
Koneksi Database..............................................................................................................9
Proyeksi...........................................................................................................................10
Level of Detail (LOD)......................................................................................................10
Indeks GiST.....................................................................................................................10
Hasil Keseluruhan............................................................................................................11
TileCache...............................................................................................................................11
Implementasi....................................................................................................................11
Cara Kerja........................................................................................................................11
Seeding dan Pemrosesan Citra.........................................................................................11
Halaman
Metode Benchmark..........................................................................................................12
Konfigurasi OpenLayers..................................................................................................12
Hasil Benchmark..............................................................................................................12
KESIMPULAN DAN SARAN
Kesimpulan............................................................................................................................13
Saran......................................................................................................................................13
DAFTAR PUSTAKA..................................................................................................................13
vi
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
14. Perbandingan kinerja server WMS MapServer dengan TileCache.......................................13
vii
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
Scibun dapat berjalan lebih cepat. Selain itu,
akan dicoba alternatif lain yang tidak terlalu
membebani prosesor, yaitu TileCache.
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
format input dan output. MapServer juga
menyediakan
antarmuka
untuk
bahasa
pemrograman seperti PHP dan Python.
MapServer mendukung berbagai standar dari
OGC (MapServer Team 2011).
TileCache
Ruang Lingkup
Penelitian ini
sebagai berikut:
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).
memiliki
ruang lingkup
1. Server memakai sistem operasi Debian
GNU/Linux.
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
TileCache adalah implementasi WMS-C
(Web Map Service Caching) open source yang
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
Scale-up adalah teknik untuk meningkatkan
kinerja server dengan menambah sumber daya.
Hal ini mencakup konfigurasi server supaya
sumber daya tersebut dapat dimanfaatkan secara
optimal (Michael et al. 2007).
1
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.
Gambar 1. Prosedur benchmark.
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.
2
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
echo " ulangan ke-$i"
siege -b -c $c $MAP -r 4 2>>map.txt
sleep 30
siege -b -c $c $IDX -t 60s 2>>idx.txt
sleep 30
done
done
HASIL DAN PEMBAHASAN
Lingkungan Pengujian
Spesifikasi Server
Server untuk aplikasi web GIS memiliki
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.
Sistem Operasi
Sistem operasi yang dipilih untuk server ini
adalah Debian GNU/Linux 6.0, kernel 2.6.32-5amd64.
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
PostGIS 1.5.1
Apache 2.2.16
PHP 5.3.3
MapServer 5.6.5
TileCache 2.03
Waktu Eksekusi PHP
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.
# editor /etc/php5/apache2/php.ini
max_execution_time = 60
Konsumsi RAM
Konsumsi RAM aplikasi server diukur
dengan menggunakan program 'htop', yaitu
dengan mencatat nilai tertinggi pada kolom
RES (resident memory) untuk setiap proses
aplikasi server Apache dan PostgreSQL.
Konsumsi RAM server saat idle adalah 54 MB,
sedangkan konsumsi RAM untuk satu proses
aplikasi server setelah melayani permintaan
untuk halaman peta dan indeks pada tingkat
konkurensi 16 dapat dilihat pada Tabel 1.
3
Tabel 1. Konsumsi RAM per proses
Halaman
PostgreSQL
Apache
Peta
50 MB
90 MB
Gambar 2. Alokasi RAM server.
Indeks
6 MB
16 MB
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.
Kinerja Awal
Kinerja awal server secara keseluruhan
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
4
8
16
32
Peta
trx/s gagal
0.31
0%
0.31
0%
0.31
0%
0.05
8%
Indeks
trx/s
gagal
78.81
0%
80.48
0%
80.12
0%
79.67
0%
PostgreSQL
Konfigurasi server PostgreSQL terletak pada
/etc/postgresql/8.4/main/postgresql.conf.
Penjelasan dari PostgreSQL Global Development Group (2009) mengenai opsi-opsi yang
akan dikonfigurasi adalah sebagai berikut:
•
•
•
•
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 menunjukkan 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.
shared_buffers:
Scale-up
koneksi max =
Dari
alokasi RAM
konsumsi RAM per proses
rumus
di atas, didapat nilai
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.
max_connections:
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
Konkurensi
4
8
16
32
64
128
256
512
Peta
trx/s gagal
0.31
0%
0.31
0%
0.31
0%
0.62
0%
1.21
0%
2.21
0%
4.17
0%
6.82 10%
Indeks
trx/s
gagal
78.88
0%
80.61
0%
80.07
0%
79.83
0%
79.28
0%
73.45
0%
70.42
0%
71.78
16%
shared_buffers = 256MB
effective_cache_size = 768MB
max_connections = 32
4
8
7
6
•
trx / sec
5
4
3
•
2
1
0
4
8
16
32
64
128
256
512
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,
index.php, index.xhtml, dan index.htm.
konkurensi
sebelum
sesudah
Scale-up
MaxClients 64
Gambar 3. Kinerja server sebelum dan setelah
scale-up PostgreSQL untuk halaman peta.
Koneksi Maksimum
max_connections = 100
Penambahan jumlah koneksi belum tentu
meningkatkan kinerja server. Kinerja server
justru turun menjadi 0.05 transaction/second
pada tingkat konkurensi 32. Jumlah koneksi
yang melebihi kapasitas RAM ini akan
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
yang sedang diproses.
Memori Kerja
work_mem = 8MB
Peningkatan memori kerja dari 1 MB
menjadi 8 MB tidak meningkatkan kinerja
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
Jumlah RAM yang dialokasikan untuk
server Apache adalah 1024 MB. Satu proses
Apache memerlukan jumlah RAM sebesar 16
MB untuk melayani halaman indeks. Jumlah
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
Konkurensi
64
128
256
512
Peta
trx/s gagal
1.21
0%
2.35
0%
4.50
0%
6.93 18%
Indeks
trx/s
gagal
78.48
0%
78.93
0%
78.85
1%
78.77
16%
Keep Alive
KeepAliveTimeout 2
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.
5
Tabel 5. Kinerja server setelah menurunkan
KeepAliveTimeout Apache
Konkurensi
64
128
256
512
Peta
trx/s gagal
1.21
0%
2.37
0%
4.51
0%
7.42 14%
Indeks
trx/s
gagal
79.00
0%
79.13
0%
78.96
1%
78.78
9%
meningkat
setelah
dilakukan
beberapa
konfigurasi di atas. Perbandingan kinerja server
sebelum dan sesudah konfigurasi Apache untuk
halaman peta dan indeks dapat dilihat masingmasing pada Gambar 4 dan 5. Kinerja server
untuk halaman indeks juga menjadi lebih stabil
pada tingkat konkurensi di atas 64.
10
9
8
Directory Index
7
Konfigurasi ini hanya berlaku untuk
halaman indeks. Biasanya klien mengakses
halaman hanya dengan menuliskan nama
direktori saja, misalnya http://localhost/scibun/.
Server kemudian melihat opsi ini untuk mencari
berkas indeks yang akan ditampilkan. Karena
nama berkas halaman indeks Scibun adalah
'index.php', maka server akan redirect menuju
http://localhost/scibun/index.php.
Hasil konfigurasi ini meningkatkan kinerja
halaman indeks yang diakses tidak secara
langsung sebesar 0.4% pada tingkat konkurensi
128.
6
trx / sec
# editor /etc/apache2/mod-enabled/dir.conf
DirectoryIndex index.php index.html
5
4
3
2
1
0
4
8
16
32
64
128 256 512
konkurensi
sebelum
sesudah
Gambar 4. Kinerja server setelah konfigurasi
Apache untuk halaman peta.
82
80
# a2dismod autoindex cgi
78
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.
76
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
Konkurensi
64
128
256
512
Peta
trx/s gagal
1.21
0%
2.36
0%
4.50
1%
8.83 14%
Indeks
trx/s
gagal
79.42
0%
79.19
0%
79.22
1%
78.57
9%
Hasil Keseluruhan
trx / sec
Mematikan Modul AutoIndex dan CGI
74
72
70
68
66
64
4
8
16
32
64
128 256 512
konkurensi
sebelum
sesudah
Gambar 5. Kinerja server setelah konfigurasi
Apache untuk halaman indeks.
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.
Kinerja server Apache secara keseluruhan
6
Perbaiki Pesan Peringatan
Setelah melihat log kesalahan Apache,
ternyata Scibun banyak menimbulkan pesan
peringatan. Hal ini disebabkan oleh penulisan
kode PHP yang kurang cermat. Selain
memperlambat kinerja server, berkas log
kesalahan juga akan memenuhi harddisk jika
server banyak diakses.
Cara
mengatasinya
adalah
dengan
memperbaiki kode PHP yang bermasalah.
Namun karena keterbatasan waktu, diambil
jalan pintas yaitu mengatur supaya PHP tidak
melaporkan pesan peringatan. Potongan kode di
bawah ini perlu ditambahkan pada bagian
paling atas kode sumber PHP supaya hanya
pesan kesalahan yang akan dilaporkan.
Hasil perbaikan ini dapat dilihat pada Tabel
7. Kinerja halaman peta dan indeks masingmasing 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
Konkurensi
64
128
256
512
Peta
trx/s gagal
1.21
0%
2.36
0%
4.51
0%
9.38 16%
Indeks
trx/s
gagal
79.56
0%
79.45
0%
79.50
1%
78.72
9%
Perbaiki Include Path
Setelah menelusuri system call Apache pada
halaman indeks, ternyata ada satu include path
yang kurang tepat. Akibatnya PHP akan
mencari berkas yang akan disertakan tersebut
pada setiap include path. Hal ini tentunya
membuang waktu prosesor tanpa guna. Untuk
mengatasinya, include path perlu diperbaiki
sesuai dengan path berkas yang akan
disertakan.
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
Konkurensi
64
128
256
512
Indeks
trx/s
79.74
79.78
79.69
78.85
gagal
0%
0%
1%
8%
Opcode Cache
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
4
8
16
32
64
128
256
512
Peta
trx/s gagal
0.31
0%
0.31
0%
0.31
0%
0.62
0%
1.22
0%
2.40
0%
4.64
0%
8.40 15%
Indeks
trx/s
gagal
146.36
0%
154.08
0%
153.56
0%
152.74
0%
138.29
0%
141.99
0%
141.33
1%
141.82
5%
Data Cache
APC juga dapat digunakan sebagai data
cache. Tujuannya adalah untuk mengurangi
koneksi ke database. Data langsung diambil
dari cache, sehingga kinerja server meningkat.
Ekstensi PHP 'XDebug' dapat digunakan untuk
mengidentifikasi bagian kode yang menjadi
bottleneck. Berikut adalah contoh potongan
7
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);
}
return $result;
}
Alamat URL (Uniform Resource Locator)
gambar peta yang dihasilkan oleh PHP
MapScript juga dapat disimpan dalam cache.
Akan tetapi, hanya tampilan peta awal yang
memungkinkan,
karena
tampilan
peta
selanjutnya selalu berubah seiring dengan
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
Konkurensi
4
8
16
32
64
128
256
512
Peta
trx/s
80.00
80.00
81.01
81.53
81.53
81.01
75.52
72.97
gagal
0%
0%
0%
0%
0%
0%
0%
5%
Hindari Include Once
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
dapat dilihat pada Tabel 11. Kinerja
halaman peta dan indeks meningkat masingmasing 0.3% dan 0.9%.
include
Tabel 11. Kinerja server setelah penggantian
include_once
Konkurensi
4
8
16
32
64
128
256
512
Peta
trx/s gagal
80.00 0%
80.00 0%
81.01 0%
81.53 0%
81.79 0%
80.88 0%
76.82 0%
73.48 4%
Indeks
trx/s
gagal
147.77
0%
154.57
0%
154.43
0%
153.96
0%
139.76
0%
140.70
0%
143.61
1%
145.31
5%
Data Cache Parametrik
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;
}
Hasil implementasi data cache parametrik
ini dapat dilihat pada Tabel 12. Kinerja halaman
peta meningkat 41%. Persentase kegagalan
server juga menurun dari 5% menjadi 1% pada
tingkat konkurensi 512.
8
Tabel 12. Kinerja server setelah implementasi
data cache parametrik
4
8
16
32
64
128
256
512
120
Peta
trx/s
114.29
114.29
116.36
117.43
116.89
116.89
106.56
95.87
gagal
0%
0%
0%
0%
0%
0%
0%
1%
100
trx / sec
Konkurensi
140
80
60
40
20
0
4
8
•
Jika
opsi ini aktif, maka koneksi database
PostgreSQL akan tetap terbuka dan dapat
dipakai ulang oleh layer MapServer
selanjutnya.
PROJECTION:
Opsi ini mengatur jenis
proyeksi untuk objek peta dan layer.
Proyeksi dapat ditentukan dengan kata kunci
PROJ.4 atau melalui kode EPSG.
sesudah
180
160
140
trx / sec
120
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.
PROCESSING "CLOSE_CONNECTION=DEFER":
128 256 512
Gambar 6. Kinerja server setelah konfigurasi
PHP untuk halaman peta.
MapServer
•
64
konkurensi
APC sangat bermanfaat untuk meningkatkan
kinerja server pada aplikasi web PHP.
Pemakaian APC sebagai opcode dan data cache
dapat meningkatkan kinerja aplikasi web PHP
dari dua sampai 100 kali lipat atau lebih.
Perbandingan kinerja server sebelum dan
sesudah konfigurasi PHP untuk halaman peta
dan indeks dapat dilihat masing-masing pada
Gambar 6 dan 7.
Opsi-opsi mapfile yang akan dikonfigurasi
dijelaskan pada daftar berikut ini (MapServer
Team 2011).
32
sebelum
Hasil Keseluruhan
$ 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
...
16
100
80
60
40
20
0
4
8
16
32
64
128 256 512
konkurensi
sebelum
sesudah
Gambar 7. Kinerja server setelah konfigurasi
PHP untuk halaman indeks.
•
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.
9
LAYER
...
CONNECTIONTYPE POSTGIS
DATA "the_geom FROM provinsi"
PROCESSING "CLOSE_CONNECTION=DEFER"
...
END
Penggunaan opsi ini mengurangi waktu
yang diperlukan oleh MapServer untuk
menggambar peta sebesar 0.8%, dari 10.54
detik menjadi 10.45 detik.
Gambar 8. Peta sebelum implementasi LOD.
Proyeksi
Penulisan objek proyeksi dapat dilakukan
dengan dua cara: kata kunci PROJ.4 dan kode
EPSG. Walaupun lebih ringkas, cara kedua
harus melihat berkas referensi dahulu untuk
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
"proj=longlat"
"ellps=WGS84"
"datum=WGS84"
"no_defs"
END
PROJECTION
"init=epsg:4326"
END
Penulisan objek proyeksi dengan kode
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.
LAYER
NAME 'Jalan'
...
CLASS
NAME 'Jalan Arteri'
...
MAXSCALEDENOM 1000000
END
CLASS
NAME 'Jalan Kolektor'
...
MAXSCALEDENOM 250000
END
END
Gambar 9. Peta setelah implementasi LOD.
Contoh implementasi LOD dapat dilihat
pada Gambar 8 dan 9. Perinciannya adalah
sebagai berikut: layer 'provinsi' akan selalu
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
10
Implementasi
Gambar 10. Peta pada extent tertentu.
Hasil pemakaian indeks GiST ini
mengurangi waktu yang diperlukan oleh
MapServer untuk menggambar peta sebesar
23%, dari 0.49 detik menjadi 0.38 detik.
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.
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.
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
8
Jika TileCache sudah berjalan, maka semua
tile peta yang pernah diminta oleh klien akan
dibuat cache-nya. Permintaan dari klien
selanjutnya akan diambil dari cache tile peta.
Jika tile peta yang dimaksud tidak ada dalam
cache, maka TileCache akan meminta tile peta
ke server WMS, dan kemudian hasilnya
disimpan ke dalam cache.
6
Seeding dan Pemrosesan Citra
12
10
waktu (detik)
Gambar 12. Perbandingan arsitektur web GIS.
4
2
0
Sebelum
Sesudah
Gambar 11. Perbandingan kecepatan
MapServer setelah konfigurasi.
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.
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
mengoptimalkan ukuran citra PNG. Sebanyak
9101 tile peta hasil seeding berkurang ukuran
totalnya sebesar 53%, yaitu dari 13.4 MB
menjadi 6.3 MB dengan program ini. Ukuran
tile peta yang lebih kecil ini bermanfaat bagi
klien dengan koneksi yang lambat.
Berikut adalah contoh perintah
seeding dan optimisasi citra PNG.
untuk
11
# 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
?LAYERS=provinsi,kabupaten,jalan
&FORMAT=image/png
&SERVICE=WMS
&VERSION=1.1.1
&REQUEST=GetMap
&STYLES=
&SRS=EPSG:4326
&BBOX=112.5,22.5,135,0
&WIDTH=256
&HEIGHT=256
http://localhost/cgi-bin/tilecache.cgi
?LAYERS=administrasi
&FORMAT=image/png
&SERVICE=WMS
&VERSION=1.1.1
&REQUEST=GetMap
&STYLES=
&SRS=EPSG:4326
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.
Keywords: server, performance, web GIS, mapserver, postgresql, tilecache.
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
BOGOR
2011
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.
Keywords: server, performance, web GIS, mapserver, postgresql, tilecache.
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
BOGOR
2011
Judul Skripsi
Nama
NIM
: Peningkatan Kinerja Server Aplikasi Web GIS Berbasis PostgreSQL dan
MapServer
: Auriza Rahmad Akbar
: 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
Tanggal Lulus:
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
Auriza Rahmad Akbar
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.
Pada tahun yang sama, penulis diterima sebagai mahasiswa Institut Pertanian Bogor (IPB) melalui
jalur USMI. Penulis kemudian memilih jurusan Ilmu Komputer setelah menyelesaikan tahun
pertamanya di IPB. Pada tahun 2008, penulis melaksanakan kegiatan praktik lapang di Lembaga
Pengembangan Insani selama dua bulan. Penulis pernah menjadi asisten mata kuliah Pemrosesan
Paralel pada tahun akademik 2008/2009. Selama mengerjakan skripsi, penulis juga membantu
instalasi dan integrasi aplikasi web GIS Scibun yang dikembangkan oleh PT. Sucofindo ke dalam
server Linux.
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
Hasil Keseluruhan..............................................................................................................9
MapServer...............................................................................................................................9
Koneksi Database..............................................................................................................9
Proyeksi...........................................................................................................................10
Level of Detail (LOD)......................................................................................................10
Indeks GiST.....................................................................................................................10
Hasil Keseluruhan............................................................................................................11
TileCache...............................................................................................................................11
Implementasi....................................................................................................................11
Cara Kerja........................................................................................................................11
Seeding dan Pemrosesan Citra.........................................................................................11
Halaman
Metode Benchmark..........................................................................................................12
Konfigurasi OpenLayers..................................................................................................12
Hasil Benchmark..............................................................................................................12
KESIMPULAN DAN SARAN
Kesimpulan............................................................................................................................13
Saran......................................................................................................................................13
DAFTAR PUSTAKA..................................................................................................................13
vi
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
14. Perbandingan kinerja server WMS MapServer dengan TileCache.......................................13
vii
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
Scibun dapat berjalan lebih cepat. Selain itu,
akan dicoba alternatif lain yang tidak terlalu
membebani prosesor, yaitu TileCache.
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
format input dan output. MapServer juga
menyediakan
antarmuka
untuk
bahasa
pemrograman seperti PHP dan Python.
MapServer mendukung berbagai standar dari
OGC (MapServer Team 2011).
TileCache
Ruang Lingkup
Penelitian ini
sebagai berikut:
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).
memiliki
ruang lingkup
1. Server memakai sistem operasi Debian
GNU/Linux.
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
TileCache adalah implementasi WMS-C
(Web Map Service Caching) open source yang
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
Scale-up adalah teknik untuk meningkatkan
kinerja server dengan menambah sumber daya.
Hal ini mencakup konfigurasi server supaya
sumber daya tersebut dapat dimanfaatkan secara
optimal (Michael et al. 2007).
1
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.
Gambar 1. Prosedur benchmark.
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.
2
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
echo " ulangan ke-$i"
siege -b -c $c $MAP -r 4 2>>map.txt
sleep 30
siege -b -c $c $IDX -t 60s 2>>idx.txt
sleep 30
done
done
HASIL DAN PEMBAHASAN
Lingkungan Pengujian
Spesifikasi Server
Server untuk aplikasi web GIS memiliki
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.
Sistem Operasi
Sistem operasi yang dipilih untuk server ini
adalah Debian GNU/Linux 6.0, kernel 2.6.32-5amd64.
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
PostGIS 1.5.1
Apache 2.2.16
PHP 5.3.3
MapServer 5.6.5
TileCache 2.03
Waktu Eksekusi PHP
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.
# editor /etc/php5/apache2/php.ini
max_execution_time = 60
Konsumsi RAM
Konsumsi RAM aplikasi server diukur
dengan menggunakan program 'htop', yaitu
dengan mencatat nilai tertinggi pada kolom
RES (resident memory) untuk setiap proses
aplikasi server Apache dan PostgreSQL.
Konsumsi RAM server saat idle adalah 54 MB,
sedangkan konsumsi RAM untuk satu proses
aplikasi server setelah melayani permintaan
untuk halaman peta dan indeks pada tingkat
konkurensi 16 dapat dilihat pada Tabel 1.
3
Tabel 1. Konsumsi RAM per proses
Halaman
PostgreSQL
Apache
Peta
50 MB
90 MB
Gambar 2. Alokasi RAM server.
Indeks
6 MB
16 MB
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.
Kinerja Awal
Kinerja awal server secara keseluruhan
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
4
8
16
32
Peta
trx/s gagal
0.31
0%
0.31
0%
0.31
0%
0.05
8%
Indeks
trx/s
gagal
78.81
0%
80.48
0%
80.12
0%
79.67
0%
PostgreSQL
Konfigurasi server PostgreSQL terletak pada
/etc/postgresql/8.4/main/postgresql.conf.
Penjelasan dari PostgreSQL Global Development Group (2009) mengenai opsi-opsi yang
akan dikonfigurasi adalah sebagai berikut:
•
•
•
•
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 menunjukkan 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.
shared_buffers:
Scale-up
koneksi max =
Dari
alokasi RAM
konsumsi RAM per proses
rumus
di atas, didapat nilai
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.
max_connections:
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
Konkurensi
4
8
16
32
64
128
256
512
Peta
trx/s gagal
0.31
0%
0.31
0%
0.31
0%
0.62
0%
1.21
0%
2.21
0%
4.17
0%
6.82 10%
Indeks
trx/s
gagal
78.88
0%
80.61
0%
80.07
0%
79.83
0%
79.28
0%
73.45
0%
70.42
0%
71.78
16%
shared_buffers = 256MB
effective_cache_size = 768MB
max_connections = 32
4
8
7
6
•
trx / sec
5
4
3
•
2
1
0
4
8
16
32
64
128
256
512
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,
index.php, index.xhtml, dan index.htm.
konkurensi
sebelum
sesudah
Scale-up
MaxClients 64
Gambar 3. Kinerja server sebelum dan setelah
scale-up PostgreSQL untuk halaman peta.
Koneksi Maksimum
max_connections = 100
Penambahan jumlah koneksi belum tentu
meningkatkan kinerja server. Kinerja server
justru turun menjadi 0.05 transaction/second
pada tingkat konkurensi 32. Jumlah koneksi
yang melebihi kapasitas RAM ini akan
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
yang sedang diproses.
Memori Kerja
work_mem = 8MB
Peningkatan memori kerja dari 1 MB
menjadi 8 MB tidak meningkatkan kinerja
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
Jumlah RAM yang dialokasikan untuk
server Apache adalah 1024 MB. Satu proses
Apache memerlukan jumlah RAM sebesar 16
MB untuk melayani halaman indeks. Jumlah
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
Konkurensi
64
128
256
512
Peta
trx/s gagal
1.21
0%
2.35
0%
4.50
0%
6.93 18%
Indeks
trx/s
gagal
78.48
0%
78.93
0%
78.85
1%
78.77
16%
Keep Alive
KeepAliveTimeout 2
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.
5
Tabel 5. Kinerja server setelah menurunkan
KeepAliveTimeout Apache
Konkurensi
64
128
256
512
Peta
trx/s gagal
1.21
0%
2.37
0%
4.51
0%
7.42 14%
Indeks
trx/s
gagal
79.00
0%
79.13
0%
78.96
1%
78.78
9%
meningkat
setelah
dilakukan
beberapa
konfigurasi di atas. Perbandingan kinerja server
sebelum dan sesudah konfigurasi Apache untuk
halaman peta dan indeks dapat dilihat masingmasing pada Gambar 4 dan 5. Kinerja server
untuk halaman indeks juga menjadi lebih stabil
pada tingkat konkurensi di atas 64.
10
9
8
Directory Index
7
Konfigurasi ini hanya berlaku untuk
halaman indeks. Biasanya klien mengakses
halaman hanya dengan menuliskan nama
direktori saja, misalnya http://localhost/scibun/.
Server kemudian melihat opsi ini untuk mencari
berkas indeks yang akan ditampilkan. Karena
nama berkas halaman indeks Scibun adalah
'index.php', maka server akan redirect menuju
http://localhost/scibun/index.php.
Hasil konfigurasi ini meningkatkan kinerja
halaman indeks yang diakses tidak secara
langsung sebesar 0.4% pada tingkat konkurensi
128.
6
trx / sec
# editor /etc/apache2/mod-enabled/dir.conf
DirectoryIndex index.php index.html
5
4
3
2
1
0
4
8
16
32
64
128 256 512
konkurensi
sebelum
sesudah
Gambar 4. Kinerja server setelah konfigurasi
Apache untuk halaman peta.
82
80
# a2dismod autoindex cgi
78
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.
76
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
Konkurensi
64
128
256
512
Peta
trx/s gagal
1.21
0%
2.36
0%
4.50
1%
8.83 14%
Indeks
trx/s
gagal
79.42
0%
79.19
0%
79.22
1%
78.57
9%
Hasil Keseluruhan
trx / sec
Mematikan Modul AutoIndex dan CGI
74
72
70
68
66
64
4
8
16
32
64
128 256 512
konkurensi
sebelum
sesudah
Gambar 5. Kinerja server setelah konfigurasi
Apache untuk halaman indeks.
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.
Kinerja server Apache secara keseluruhan
6
Perbaiki Pesan Peringatan
Setelah melihat log kesalahan Apache,
ternyata Scibun banyak menimbulkan pesan
peringatan. Hal ini disebabkan oleh penulisan
kode PHP yang kurang cermat. Selain
memperlambat kinerja server, berkas log
kesalahan juga akan memenuhi harddisk jika
server banyak diakses.
Cara
mengatasinya
adalah
dengan
memperbaiki kode PHP yang bermasalah.
Namun karena keterbatasan waktu, diambil
jalan pintas yaitu mengatur supaya PHP tidak
melaporkan pesan peringatan. Potongan kode di
bawah ini perlu ditambahkan pada bagian
paling atas kode sumber PHP supaya hanya
pesan kesalahan yang akan dilaporkan.
Hasil perbaikan ini dapat dilihat pada Tabel
7. Kinerja halaman peta dan indeks masingmasing 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
Konkurensi
64
128
256
512
Peta
trx/s gagal
1.21
0%
2.36
0%
4.51
0%
9.38 16%
Indeks
trx/s
gagal
79.56
0%
79.45
0%
79.50
1%
78.72
9%
Perbaiki Include Path
Setelah menelusuri system call Apache pada
halaman indeks, ternyata ada satu include path
yang kurang tepat. Akibatnya PHP akan
mencari berkas yang akan disertakan tersebut
pada setiap include path. Hal ini tentunya
membuang waktu prosesor tanpa guna. Untuk
mengatasinya, include path perlu diperbaiki
sesuai dengan path berkas yang akan
disertakan.
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
Konkurensi
64
128
256
512
Indeks
trx/s
79.74
79.78
79.69
78.85
gagal
0%
0%
1%
8%
Opcode Cache
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
4
8
16
32
64
128
256
512
Peta
trx/s gagal
0.31
0%
0.31
0%
0.31
0%
0.62
0%
1.22
0%
2.40
0%
4.64
0%
8.40 15%
Indeks
trx/s
gagal
146.36
0%
154.08
0%
153.56
0%
152.74
0%
138.29
0%
141.99
0%
141.33
1%
141.82
5%
Data Cache
APC juga dapat digunakan sebagai data
cache. Tujuannya adalah untuk mengurangi
koneksi ke database. Data langsung diambil
dari cache, sehingga kinerja server meningkat.
Ekstensi PHP 'XDebug' dapat digunakan untuk
mengidentifikasi bagian kode yang menjadi
bottleneck. Berikut adalah contoh potongan
7
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);
}
return $result;
}
Alamat URL (Uniform Resource Locator)
gambar peta yang dihasilkan oleh PHP
MapScript juga dapat disimpan dalam cache.
Akan tetapi, hanya tampilan peta awal yang
memungkinkan,
karena
tampilan
peta
selanjutnya selalu berubah seiring dengan
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
Konkurensi
4
8
16
32
64
128
256
512
Peta
trx/s
80.00
80.00
81.01
81.53
81.53
81.01
75.52
72.97
gagal
0%
0%
0%
0%
0%
0%
0%
5%
Hindari Include Once
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
dapat dilihat pada Tabel 11. Kinerja
halaman peta dan indeks meningkat masingmasing 0.3% dan 0.9%.
include
Tabel 11. Kinerja server setelah penggantian
include_once
Konkurensi
4
8
16
32
64
128
256
512
Peta
trx/s gagal
80.00 0%
80.00 0%
81.01 0%
81.53 0%
81.79 0%
80.88 0%
76.82 0%
73.48 4%
Indeks
trx/s
gagal
147.77
0%
154.57
0%
154.43
0%
153.96
0%
139.76
0%
140.70
0%
143.61
1%
145.31
5%
Data Cache Parametrik
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;
}
Hasil implementasi data cache parametrik
ini dapat dilihat pada Tabel 12. Kinerja halaman
peta meningkat 41%. Persentase kegagalan
server juga menurun dari 5% menjadi 1% pada
tingkat konkurensi 512.
8
Tabel 12. Kinerja server setelah implementasi
data cache parametrik
4
8
16
32
64
128
256
512
120
Peta
trx/s
114.29
114.29
116.36
117.43
116.89
116.89
106.56
95.87
gagal
0%
0%
0%
0%
0%
0%
0%
1%
100
trx / sec
Konkurensi
140
80
60
40
20
0
4
8
•
Jika
opsi ini aktif, maka koneksi database
PostgreSQL akan tetap terbuka dan dapat
dipakai ulang oleh layer MapServer
selanjutnya.
PROJECTION:
Opsi ini mengatur jenis
proyeksi untuk objek peta dan layer.
Proyeksi dapat ditentukan dengan kata kunci
PROJ.4 atau melalui kode EPSG.
sesudah
180
160
140
trx / sec
120
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.
PROCESSING "CLOSE_CONNECTION=DEFER":
128 256 512
Gambar 6. Kinerja server setelah konfigurasi
PHP untuk halaman peta.
MapServer
•
64
konkurensi
APC sangat bermanfaat untuk meningkatkan
kinerja server pada aplikasi web PHP.
Pemakaian APC sebagai opcode dan data cache
dapat meningkatkan kinerja aplikasi web PHP
dari dua sampai 100 kali lipat atau lebih.
Perbandingan kinerja server sebelum dan
sesudah konfigurasi PHP untuk halaman peta
dan indeks dapat dilihat masing-masing pada
Gambar 6 dan 7.
Opsi-opsi mapfile yang akan dikonfigurasi
dijelaskan pada daftar berikut ini (MapServer
Team 2011).
32
sebelum
Hasil Keseluruhan
$ 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
...
16
100
80
60
40
20
0
4
8
16
32
64
128 256 512
konkurensi
sebelum
sesudah
Gambar 7. Kinerja server setelah konfigurasi
PHP untuk halaman indeks.
•
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.
9
LAYER
...
CONNECTIONTYPE POSTGIS
DATA "the_geom FROM provinsi"
PROCESSING "CLOSE_CONNECTION=DEFER"
...
END
Penggunaan opsi ini mengurangi waktu
yang diperlukan oleh MapServer untuk
menggambar peta sebesar 0.8%, dari 10.54
detik menjadi 10.45 detik.
Gambar 8. Peta sebelum implementasi LOD.
Proyeksi
Penulisan objek proyeksi dapat dilakukan
dengan dua cara: kata kunci PROJ.4 dan kode
EPSG. Walaupun lebih ringkas, cara kedua
harus melihat berkas referensi dahulu untuk
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
"proj=longlat"
"ellps=WGS84"
"datum=WGS84"
"no_defs"
END
PROJECTION
"init=epsg:4326"
END
Penulisan objek proyeksi dengan kode
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.
LAYER
NAME 'Jalan'
...
CLASS
NAME 'Jalan Arteri'
...
MAXSCALEDENOM 1000000
END
CLASS
NAME 'Jalan Kolektor'
...
MAXSCALEDENOM 250000
END
END
Gambar 9. Peta setelah implementasi LOD.
Contoh implementasi LOD dapat dilihat
pada Gambar 8 dan 9. Perinciannya adalah
sebagai berikut: layer 'provinsi' akan selalu
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
10
Implementasi
Gambar 10. Peta pada extent tertentu.
Hasil pemakaian indeks GiST ini
mengurangi waktu yang diperlukan oleh
MapServer untuk menggambar peta sebesar
23%, dari 0.49 detik menjadi 0.38 detik.
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.
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.
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
8
Jika TileCache sudah berjalan, maka semua
tile peta yang pernah diminta oleh klien akan
dibuat cache-nya. Permintaan dari klien
selanjutnya akan diambil dari cache tile peta.
Jika tile peta yang dimaksud tidak ada dalam
cache, maka TileCache akan meminta tile peta
ke server WMS, dan kemudian hasilnya
disimpan ke dalam cache.
6
Seeding dan Pemrosesan Citra
12
10
waktu (detik)
Gambar 12. Perbandingan arsitektur web GIS.
4
2
0
Sebelum
Sesudah
Gambar 11. Perbandingan kecepatan
MapServer setelah konfigurasi.
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.
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
mengoptimalkan ukuran citra PNG. Sebanyak
9101 tile peta hasil seeding berkurang ukuran
totalnya sebesar 53%, yaitu dari 13.4 MB
menjadi 6.3 MB dengan program ini. Ukuran
tile peta yang lebih kecil ini bermanfaat bagi
klien dengan koneksi yang lambat.
Berikut adalah contoh perintah
seeding dan optimisasi citra PNG.
untuk
11
# 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
?LAYERS=provinsi,kabupaten,jalan
&FORMAT=image/png
&SERVICE=WMS
&VERSION=1.1.1
&REQUEST=GetMap
&STYLES=
&SRS=EPSG:4326
&BBOX=112.5,22.5,135,0
&WIDTH=256
&HEIGHT=256
http://localhost/cgi-bin/tilecache.cgi
?LAYERS=administrasi
&FORMAT=image/png
&SERVICE=WMS
&VERSION=1.1.1
&REQUEST=GetMap
&STYLES=
&SRS=EPSG:4326