BAB II LANDASAN TEORITIK
2.1 Landasan Teori dan Konsep Penilaian performance atau kinerja suatu sistem komputer adalah hal yang relatif karena setiap orang memiliki persepsi yang berbeda untuk hal ini . Secara umum penilaian performance suatu sistem dapat langsung dilihat dari beberapa hal antara lain: •
Response time untuk user interaktif
•
Total waktu yang diperlukan untuk batch job
•
Jumlah laporan yang dapat diselesaikan setiap hari
•
Waktu yang diperlukan sistem untuk stabil kembali setelah terjadi kerusakan
•
Tidak ada keluhan mengenai kinerja yang buruk
•
Tidak perlu dilakukan perubahan pada sistem untuk memperbaiki kinerjanya Pendefinisian yang jelas mengenai kinerja sistem yang diharapkan sangat
mutlak diperlukan sebelum melakukan sizing sistem. Evaluasi sistem hardware mutlak diperlukan sebelum kita menentukan sistem yang akan dipakai. Untuk mencapai performance yang baik suatu sistem harus dapat
memenuhi tiga
persyaratan yaitu : 1. Sistem hardware tersebut harus memiliki kapasitas yang memadai untuk menjalankan suatu aplikasi, referensi
kapasitas hardware tersebut dapat
dilihat dari kebutuhan minimum hardware yang terdapat pada petunjuk installasi suatu aplikasi, server-proven matrix dan sumber-sumber lainnya. 2. Sistem hardware tersebut harus dipersiapkan untuk menampung kapasitas maksimum dari sumber-sumber yang akan dijalankan. Sumber-sumber yang dimaksud di sini dapat berupa data, aplikasi dan user. 3. Secara berkala dilakukan
monitoring, tuning
serta upgrade sistem jika
diperlukan (Understanding IBM pSeries Performance and Sizing, 2000). 2.1.1 Kinerja server Memperkirakan dan mengevaluasi kinerja server yang efektif
dapat
mengikuti langkah-langkah dari panduan umum analisa dan tuning server. Meskipun tidak ada buku atau panduan yang benar-benar sesuai untuk semua situasi, ada beberapa langkah yang dapat dijadikan dasar untuk sebuah analisa
dan tuning
server. Tidak semua langkah-langkah tersebut dapat diterapkan pada semua situasi bahkan beberapa saran dan petunjuk yang tidak mungkin dilakukan pada sistem yang sudah ada. Sebagai contoh , kita harus memisahkan beban kerja yang saling berbenturan untuk tiap transaksi. Hal ini akan sangat sulit dilakukan karena aplikasi yang menjalankan transaksi tersebut berada dalam satu server yang sama. Untuk mengantisipasi masalah di atas, ketika akan membuat performancemanagement , tentukan terlebih dahulu tujuan utama yang akan kita capai. Berikut ini adalah beberapa hal yang sering dijadikan tujuan utama, di antaranya : •
Respons-time yang cepat untuk user interaktif
•
Kinerja sistem yang optimal performance tanpa harus membeli hardware tambahan.
Pengukuran performance sistem atau server yang sering dilakukan saat ini adalah dengan cara Benchmarking. Jika diartikan secara umum, benchmarking adalah suatu proses membandingkan dua atau lebih server atau komponen server untuk menentukan performance terbaik atau tercepat. Terdapat dua tipe benchmark yang umum yaitu Synthetic dan Real World. Synthetic Benchmark tidak menampilkan penggunaan resource sesungguhnya Whetstone dan Dhrystone merupakan contoh benchmark sintetis yang banyak digunakan untuk mengukur kinerja komputer. Benchmark sintetis berupa program pendek yang dibuat menyerupai tingkah-laku program aplikasi yang ada. Melalui kajian mendalam terhadap berbagai program aplikasi yang ada, dibuat suatu program pendek yang merupakan gabungan dari berbagai komputasi matematis, kalang (loop), pemanggilan fungsi, dan sebagainya. Real World Benchmark mengacu pada pengukuran performance sistem berdasarkan beban kerja pada kondisi sebenarnya. Penerapan benchmark ini yaitu dengan cara mengoperasikan server yang akan diukur performancenya dalam operasional harian lalu diamati apa yang akan terjadi dengan server tersebut. Secara umum kegunaan benchmark adalah untuk mengukur performance, namun benchmark juga dapat digunakan untuk pegujian bagian hardware atau aplikasi yang baru diproduksi.
Jika kita sudah terbiasa bekerja dalam sebuah transaction-oriented system yang besar tentunya kita pernah mendengar TPC Benchmark atau TPC test. TPC Benchmark telah menjadi standard de facto dalam pengukuran performance sistem yang besar dan kompleks. Ada empat jenis TPC test yaitu: •
TPCa : digunakan untuk pengukuran transaksi on-line .
•
TPCb : digunakan untuk pengukuran server database.
•
TPCc : merupakan versi update dari On-line Transaction Process.
•
TPCd : digunakan untuk Decision Support Test. Berikut ini akan diulas salah satu benchmark yang banyak dipergunakan,
yakni SPEC, yang dikembangkan oleh System Performance Evaluation Corporation. Uraian tentang benchmark SPEC ini dimaksudkan untuk menjelaskan cara pengukuran kinerja komputer dengan membandingkan waktu eksekusi yang diperlukan oleh suatu komputer untuk satu program tertentu dengan waktu eksekusi pada komputer rujukan. Pada bagian berikutnya diuraikan mengenai kelemahan pengukuran kinerja berbasis 'waktu eksekusi program' tersebut dan alternatif lain yang dapat dilakukan untuk memperbaiki pengukuran kinerja komputer tersebut. Sebagai
upaya
untuk
mendapatkan
tolok-ukur
baku
agar
dapat
membandingkan kinerja berbagai sistem komputer, sekelompok perusahaan besar antara lain: DEC, Hewlett-Packard, IBM, Intel, dan Sun sepakat membentuk lembaga non-profit yang diberi nama System Performance Evaluation Corporation. Lembaga ini ditugasi untuk mengembangkan dan memberi dukungan terhadap pembakuan benchmark kinerja komputer.
Sebelum membuat program untuk mengukur kinerja komputer, SPEC telah mempelajari sejumlah program yang umum dipakai, menganalisis algoritma dan bahasa mesinnya, menentukan cara mengukur kinerja komputer, dan menentukan rumusan untuk membuat rerata skor kinerja komputer dari skor-skor yang diperoleh masing-masing elemen benchmark. Benchmark SPEC terdiri atas dua kelompok program. Satu kelompok merupakan program-program yang dititik-beratkan pada operasi atas bilangan integer dan satu kelompok lainnya dititik-beratkan pada operasi atas bilangan floating-point. Perangkat benchmark pertama yang dibuat diperkenalkan pada tahun 1989, karenanya disebut SPEC89. Pada tahun 1992 dimunculkan versi baru, dan dengan demikian SPEC89 tidak digunakan lagi. SPEC92 terdiri atas 20 program yang terbagi menjadi dua kelompok, yakni untuk operasi bilangan integer dan untuk operasi bilangan floating-point. Saat ini, SPEC92 juga sudah tidak digunakan lagi karena telah dimunculkan perangkat benchmark baru yakni SPEC95. Pada SPEC95 ini, komputer rujukan yang digunakan sebagai pembanding berubah dari semula VAX-11/780 menjadi Sun SPARCstation 10/40. Dengan demikian, bila dikatakan skor SPECint95 adalah 5.0, maka berarti sistem yang diuji 5 kali lebih cepat dibanding Sun SPARCstation 10/40. SPEC95, yang diperkenalkan pada bulan Agustus 1995, merupakan perangkat benchmark yang terdiri atas dua bagian, yakni CINT95 (ditulis dalam bahasa C) dan CFP95 (ditulis dalam bahasa Fortran). CINT95 merupakan bagian dari perangkat SPEC95 yang mengukur kinerja komputer terhadap operasi bilangan
integer, yang diasumsikan mewakili program aplikasi bisnis. Bagian lain, yakni CFP95, mengukur kinerja komputer terhadap operasi bilangan floating-point yang diasumsikan mewakili program aplikasi ilmiah-numerik (Reilly, Jeff . 1995. SPEC Describes SPEC95 Products and Benchmarks).
Tabel 2.1.Elemen-elemen CINT95 Nama Program
Deskripsi
Waktu Referensi (Detik)
099.go
Program kecerdasan buatan, menjalankan program permainan Go melawan dirinya sendiri
4600
124.m88ksim
Simulator cip mikroprosesor Motorola 88100, menjalankan program uji Dhrystone dan program uji memori Melakukan kompilasi untuk bahasa mesin prosesor SPARC berbasis kompilator GNU C versi 2.5.3.
1900
129.compress
Program pemampat (compress) dan pengurai (decompress) file teks sebesar 16 MB yang bekerja dalam-memori (in-memory), dengan metode pengkodean Limpel-Ziv adaptif
1800
130.li
Interpreter bahasa LISP
1900
132.ijpeg
Program pemampat dan pengurai citra (image) dengan berbagai parameter, yang bekerja dalam-memori.
2400
134.perl
Melakukan manipulasi numerik dan teks (anagram dan pemfaktoran bilangan prima)
1900
147.vortex
Membuat dan memanipulasi tiga basis data yang saling berkaitan
2700
126.gcc
1700
Tabel 2.2.Elemen-elemen CFP95 Nama Program 101.tomcatv
Deskripsi Mewakili program bidang dinamika fluida/ translasi geometris. Membangkitkan sistem koordinat dua-dimensi pada domain geometris umum.
Waktu Referensi (Detik) 3700
102.swim
Model perairan dangkal dengan 1024x1024 kisi Simulasi Monte Carlo, bidang fisika kuantum. Melakukan perhitungan massa partikel elementer berdasarkan teori Quark-Gluon
8600
104.hydro2d
Bidang astrofisika, menyelesaikan persamaan hidrodinamik Navier Stokes untuk menghitung semburan galaktik
2400
107.mgrid
Bidang elektromagnetis, memecahkan persoalan medan potensial 3 dimensi multikisi (multigrid)
2500
110.applu
Bidang dinamika menyelesaikan sistem pivoting
fluida/matematika, matriks dengan
2200
125.turb3d
Simulasi turbulensi homogen isotropik dalam kubus
4100
141.apsi
Pemecahan persoalan berkaitan dengan temperatur, angin, serta kecepatan dan distribusi polutan
2100
145.fppp
Menyelesaikan derivasi multielektron , bidang kimia kuantum
9600
146.wave5
Penyelesaian persamaan Maxwell pada jaring Cartesian
3000
103.su2cor
1400
Bencmark SPEC95 mengukur dan membandingkan kinerja komputer dalam tiga kategori pilihan:
1. Kinerja terhadap bilangan integer versus floating point 2. Kinerja dengan kompilasi agresif versus kompilasi konservatif 3. Kecepatan versus throughput
Berdasarkan pilihan-pilihan tersebut, SPEC95 memungkinkan dibuatnya ukuran komposit sebagai berikut:
Tabel 2.3. Pilihan Ukuran Kinerja Komposit Metode Kompilasi
Kecepatan
Throughput
Kompilasi Agresif
SPECint95
SPECint_rate95
SPECfp95
SPECfp_rate95
SPECint_base95
SPECint_rate_base95
SPECfp_base95
SPECfp_rate_base95
Kompilasi Konservatif
Yang dimaksud ukuran komposit adalah bahwa skor indivual dihitung untuk tiap-tiap elemen program (8 elemen pada CINT95 dan 10 elemen pada CFP95) dalam CINT95 atau CFP95 dan hasilnya digunakan untuk menghitung ukuran komposit ini. Untuk pengukuran kecepatan, setiap elemen benchmark memiliki SPECratio. SPECratio adalah referensi waktu SPEC dibagi dengan waktupelaksanaan (runtime) tiap-tiap elemen program pada sistem yang diukur. Ukuran komposit kecepatan dapat dihitung sebagai berikut:
Tabel 2.4. Ukuran komposit kecepatan
1
SPECint95
Rerata geometris dari 8 buah SPECratio (satu untuk tiap elemen program CINT95) bila masing-masing elemen program dikompilasi dengan optimisasi agresif.
2
SPECint_base95 Rerata geometris dari 8 buah SPECratio (satu untuk tiap elemen program CINT95) bila masing-masing elemen program dikompilasi dengan optimisasi konservatif
3
SPECfp95
Rerata geometris dari 10 rasio ternormalisasi (satu untuk tiap elemen program CFP95) bila masing-masing elemen program dikompilasi dengan optimisasi agresif.
4
SPECfp_base95
Rerata geometris dari 10 rasio ternormalisasi (satu untuk tiap elemen program CFP95) bila masing-masing elemen program dikompilasi dengan optimisasi agresif.
Sumber: Reilly, Jeff . 1995. SPEC Describes SPEC95 Products and Benchmarks
Benchmark lainnya Selain SPEC95, berbagai benchmark dikembangkan untuk mengukur kinerja komputer. Berikut ini disajikan beberapa contoh beserta deskripsi singkatnya untuk memberikan gambaran mengenai perbedaan masing-masing. Whetstone merupakan benchmark sintetik yang dikembangkan oleh Curnow dan Wichman pada tahun 1976 (Sharp dan Bacon, 1994). Benchmark ini dimaksudkan untuk mengukur kinerja komputer dalam mengolah bilangan floating point dan digunakan untuk membandingkan arsitektur maupun kompilator teroptimisasi yang dijalankannya. Program semula dibuat dalam bahasa Algol dengan kompilator Algol 60 yang menterjemahkannya menjadi instruksi untuk mesin Whetstone imajiner (Sill, 1996). Kelemahan benchmark Whetstone adalah kecilnya ukuran modul/program benchmark sehingga sistem memori di luar cache tidak teruji, dan dengan optimisasi kompilator dengan mudah didapatkan skor benchmark tinggi tanpa mengubah sistem yang diuji (Sill, 1996).
Dhrystone juga merupakan benchmark sintetik yang dikembangkan oleh Reinhold Weicker pada awal tahun 1980-an dan difokuskan untuk mengukur kinerja komputer atas bilangan integer dan string (Sharp dan Bacon, 1994:68). Program asli ditulis dalam bahasa Ada, dan kemudian diterjemahkan ke dalam bahasa-bahasa lain. Sama seperti Whetstone, program benchmark Dhrystone memiliki ukuran yang terlalu kecil (sekitar 1,5 KB) sehingga tidak dapat menguji sistem di luar cache. Optimisasi kompilator juga dapat dilakukan untuk mempertinggi skor perolehan (Sill, 1996). Benchmark iCOMP dikembangkan oleh Intel untuk membandingkan kinerja prosesor-prosesor yang ada di pasaran. Ketika prosesor generasi 486 diperkenalkan, di pasaran muncul berbagai versi mulai 486SX, 486DX2, dan sebagainya. Agar calon pembeli memiliki gambaran ringkas kinerja prosesor, Intel mengembangan angka indeks yang merupakan angka kinerja prosesor dibandingkan dengan kinerja prosesor rujukan. Benchmark ini khusus mengukur kinerja prosesor dan tidak mencerminkan kinerja komputer secara keseluruhan (Sharp dan Bacon, 1994:68). Popularitas iCOMP terutama karena benchmark ini hampir selalu menjadi ukuran kinerja prosesor-prosesor Intel dalam iklan-iklannya (setidaknya sampai generasi Pentium). Kritik terhadap Benchmark Pengukuran kinerja komputer dengan benchmark yang ada saat ini banyak dikritik karena seperti orang buta meraba gajah. Bergantung pada bagian yang dipegang, gajah bisa didefinisikan sebagai tinggi seperti pohon kelapa, panjang dan
kecil seperti ular, atau lebar dan tipis seperti kipas (Gustafson dan Todi, 1998). Benchmark yang ada cenderung mengukur satu aspek dari kinerja komputer dan hasilnya digunakan untuk menggeneralisasi kinerja keseluruhan. Menyadari masalah itu, benchmark Perfect Club dan SPEC mengembangkan apa yang disebut suite aplikasi (yakni sekumpulan aplikasi terdiri atas elemenelemen program yang masing-masing mengukur berbagai aspek perilaku sistem agar diperoleh gambaran sistem lebih lengkap). Suite semacam itu biasanya sulit dipangkalkan (porting) ke komputer lain, terutama komputer paralel, dan bila berhasil dipangkalkan diperlukan waktu berjam-jam untuk mengeksekusinya (Gustafson dan Todi, 1998). Menurut Gustafson dan Todi (1998) aplikasi semacam itu tetaplah hanya mengukur satu titik sampel dari kinerja komputer sementara yang diperlukan adalah mengukur seluruh rentang kinerja komputer. Benchmark-benchmark tersebut memiliki satu karakteristik yang sama, yakni ukuran masalahnya dibuat tetap. Komputer-komputer dibandingkan dari segi berapa lama diperlukan waktu untuk menyelesaikan masalah tersebut. Karena benchmark harus dapat dieksekusi pada banyak jenis komputer, maka ukuran masalah dipilih sedemikian rupa sehingga diharapkan semua komputer sasaran uji dapat menjalankan benchmark dengan baik. Benchmark dengan Pendekatan Lain Benchmark dengan pendekatan lain juga dibuat oleh peneliti di Ames Laboratory, dikenal dengan nama HINT (Hierarchial INTegration). HINT tidak mematok ukuran masalah (problem size) maupun waktu komputasi. QUIPS
merupakan satuan yang digunakan untuk mengukur banyaknya usaha yang dilakukan komputer pada rentang waktu tertentu. Gustafson, peneliti yang mengembangkan HINT, tidak menginginkan waktu yang terlalu singkat untuk melakukan pengukuran karena kebanyakan komputer bekerja sangat cepat pada awalnya, lalu mulai menurun kecepatannya setelah banyak terjadi kemelesetan (miss) cache dan mulai menggunakan memori utama atau bahkan harus mengakses data pada harddisk (Gustafson dan Snell, 1997). Meskipun belum sepopuler benchmark lain, misalnya SPEC95, HINT diklaim sebagai benchmark yang memungkinkan pembandingan yang adil terhadap perbedaan-perbedaan ekstrim dalam hal arsitektur komputer, kineja absolut, kapasitas memori, dan taraf presisi komputasi. Saat ini HINT masih belum banyak diuji dan belum cukup populer untuk digunakan sebagai tolok-ukur kinerja komputer universal. Ada beberapa hal yang perlu dipertimbangkan dalam melakukan benchmark antara lain: •
Pastikan bahwa segala sesuatu yang akan diukur up to date.
•
Tentukan jenis pengujian yang akan dilakukan.
•
Pengujian yang dilakukan harus konsisten.
•
Ulangi pengujian beberapa kali untuk memastikan akurasi pengukuran.
•
Lakukan monitoring terhadap server, network dan benchmark.
•
Pahami apa yang dilakukan dalam benchmark.
•
Lakukan review terhadap contoh hasil sebelum memulai kembali.
Komputer sistem merupakan suatu hal yang kompleks, meskipun sebuah server kecil dengan sebuah prosesor tetapi server tersebut terdiri dari banyak komponen yang memerlukan pengoperasian khusus. Ketika melakukan benchmark pastikan bahwa operating system, application drivers, server-specific firmware dan driver merupakan versi terbaru. Selain itu kita juga perlu melakukan monitoring tidak hanya pada sistem operasiu dan aplikasi yang dijalankan pada server tersebut tetapi juga perlu dilakukan monitoring terhadap komponen-komponen hardwarenya. Memahami apa yang dilakukan dalam benchmark adalah merupakan kunci keberhasilan evaluasi server yang diujikan. Lakukan benchmark terhadap sistem atau komponen yang diuji beberapa kali dan amati perubahan performance-nya hal ini akan mempermudah dalam menganalisa kemungkinan adanya bottleneck pada server yang kita uji. Monitoring Tools Beberapa
alat
bantu
(tools)
yang
ada
dapat
digunakan
untuk
mengidentifikasi adanya masalah atau bottleneck pada sistem. Setiap sistem operasi komersial menyediakan
fasilitas ini. Sebagai contoh , Windows NT atau 2000
memiliki Performance Monitoring, Netware memiliki Monitor NLM. Untuk sistem operasi UNIX, para administrator menggunakan tools yang tersedia dalam core operating system. Utility seperti ps dan vmstat adalah utility yang sering digunakan untuk melakukan monitoring pada sistem operasi UNIX.
2.1.2 Panduan Pemilihan Server Pemilihan sistem yang tepat sangat penting dilakukan agar kita mendapatkan skalabilitas dan pengembangan kapasitas yang cukup untuk masa yang akan datang. Meskipun demikian banyak faktor non-teknis yang
turut berperan dan bahkan
menjadi bahan pertimbangan yang cukup menentukan dalam pemilihan sistem terutama faktor
finansial. Dalam pemilihan sistem hardware ada beberapa
komponen yang harus diperhatikan yaitu: •
Prosesor Pilihlah prosesor yang dapat menampung beban kerja maksimal ditambah batas toleransi yang cukup aman. Pastikan kita memiliki upgrade option untuk prosesor tersebut jika suatu saat kita akan melakukan pengembangan sistem.
•
Memory Perkirakan kebutuhan memory untuk semua aplikasi yang digunakan karena memory tidak dapat diupgrade jika sudah mendekati batas kapasitas tertingginya. Jadi dengan memperkirakan kebutuhan memory sejak awal akan memudahkan kita untuk melakukan penambahan memory jika diperlukan.
•
Storage (disk dan tape) Perkirakan besar keseluruhan data yang digunakan untuk menentukan jumlah dan kapasitas harddisk yang dibutuhkan dan tape untuk melakukan backup data
•
Jumlah slot Pilihlah sistem hardware yang masih memiliki expansion-slot yang tersisa. Hal ini berguna untuk pengembangan system pada masa mendatang, misalnya untuk penambahan adapter, harddisk dan sebagainya.
•
Network Pilihlah network adapter yang memiliki kapasitas memadai, hal ini untuk menghindari kemungkinan bottleneck sewaktu melakukan komunikasi data dalam jaringan. Masalah komunikasi data sering terlupakan dalam prosedur pemilihan
hardware, tapi bagian ini merupakan bagian yang penting, khususnya
sejak
bandwidth suatu jaringan menjadi bagian yang cukup menentukan dalam suatu system secara keseluruhan. Layaknya user atau aplikasi, tuntutan terhadap kualitas perangkat komunikasi data menjadi faktor yang menentukan dalam melakukan capacity planning (IBM White Paper, RS/6000 and IBM eServer pSeriesPerformance and Sizing, 2001). 2.1.3 Konsep Sizing Sistem 1. Workload (Beban kerja) Workload dapat memiliki beberapa arti yang berbeda, tergantung pada konteksnya. Dalam benchmarks, workload merupakan suatu kesatuan tes eksekusi terhadap suatu bagian aplikasi. Dalam pembahasan ini, workload diartikan sebagai beban kerja dari suatu sistem yang menjalankan satu atau beberapa aplikasi.
Karakteristik dan jenis workload harus diidentifikasi sebelum perencanaan sizing system dilakukan. Workload dapat dikategorikan sebagai berikut: •
Interaktif Pada workload interaktif user memiliki live-session pada suatu sistem, artinya seorang user bekerja langsung pada sistem menggunakan terminal text-based atau grafikal. Contoh aktivitasnya adalah input data secara on-line atau klien komputer untuk mengontrol jaringan. Untuk pekerjaan pekerjaan jenis ini diperlukan respons-time yang cepat karena data yang dimasukkan bisa saja akan langsung digunakan oleh bagian lain dalam suatu unit kerja.
•
Background Jenis workload ini memerlukan identifikasi user selama user tersebut bekerja. Jenis identifikasi yang dibutuhkan biasanya User-ID dan Password . Tetapi jenis pekerjaan ini tidak memerlukan interaksi langsung Background
dengan user.
workload biasanya terbentuk dari proses dan subsistem
interaktif service yang dilakukan oleh user seperti printer spool daemon, TCP/IP, SNA daemon atau database server proses. •
Batch Cara kerja workload jenis ini hampir sama dengan background workload, tetapi user tidak perlu memasukan kode autorisasi atau identifikasi untuk melakukan proses ini. Jenis pekerjaan ini tidak memerlukan interaksi langsung dengan user sewaktu melakukan proses input dan output. Pekerjaan yang biasanya dilakukan
dengan batch proses antara lain database file updates, report yang dibuat dalam format teks files, packet yang dikirim dalam jaringan dan lain sebagainya. 2. Aplikasi Satu hal terpenting yang harus diperhatikan sebelum melakukan sizing sistem untuk server dan workstation adalah mengetahui dengan pasti jenis dan karakteristik aplikasi yang akan dijalankan pada sistem tersebut. Pengelompokan aplikasi dapat didasarkan pada konstruksi dan cara interaksi dengan program tersebut. Konstruksi dan interaksi yang dimaksud adalah sebagai berikut: •
Monolithic
•
Modular
•
Intensive computing
•
Interactive
•
Batch
•
Clients of a local or remote server
•
Servers of local or remote clients Aplikasi Monolithic dapat menjalankan dirinya sendiri. Aplikasi ini tidak
memerlukan interaksi dari luar, contohnya proses pembuatan dan kompilasi program C-language atau Cobol. Aplikasi Modular adalah seperangkat program spesifik yang diaktifkan hanya sekali dalam satu waktu. Setiap program memiliki kaitan dengan sebuah modul, dan
setiap modul bertugas untuk setiap tugas spesifik yang sedang dilakukan user. Contohnya aplikasinya adalah data entry dan laporan operasi modul pada saat yang bersamaan. 3. Concurrent user Dalam melakukan sizing harus dipahami perbedaan antara
user yang
memiliki autorisasi untuk log-on ke dalam sistem, connected user dan concurrent user yang akan bekerja dengan suatu sistem. Dalam melakukan sizing kita harus mengacu pada workload maksimum yang akan dijalankan oleh sistem berdasarkan concurrent user bukan berdasarkan jumlah total user. Sedangkan untuk melakukan sizing harddisk dan memory kita harus mengacu pada jumlah maksimum user yang akan terhubung ke sistem (connected user). Ketika membicarakan concurrent user, asumsikan bahwa user-user tersebut memiliki pola kerja yang sama agar memudahkan kita dalam menentukan workload. Atau dengan cara lain yaitu kita melakukan pengelompokan user menjadi beberapa kelompok lalu kita melakukan sizing workload secara individual, lalu kita gabungkan kembali menjadi satu sistem secara keseluruhan. 4. Response time Response time merupakan salah satu faktor yang sering dijadikan tolok ukur baik dalam melakukan sizing ataupun benchmarking. Secara umum response time berarti waktu yang diperlukan oleh sistem untuk menyelesaikan suatu tugas atau instruksi.
Response time sangat bergantung pada konfigurasi hardware, arsitektur hardware, sistem manajemen dan workload. Response time akan menurun ketika beban kerja sistem mendekati 100 % untuk mengatasi hal ini harus dilakukan
pengurangan
tugas-tugas aktif untuk
mengembalikan sistem ke kondisi kinerja yang semestinya. Langkah-langkah yang dilakukan untuk melakukan sizing sistem antara lain: A. Melakukan sizing untuk tiap aplikasi dengan menggunakan metode sizing yang umum. Lakukan juga sizing prosesor, memory, network dan storage. Kemudian gabungkan semua hasil sizing tersebut untuk memperoleh hasil keseluruhan. B. Tambahkan perkiraan CPU, memory, dan storage yang diperlukan untuk sistem
operasi. Kemudian beri buffer sehingga
sistem
masih dapat
mengatasi beban kerja yang makin meningkat. C. Tentukan alokasi prosesor, memory dan disk I/O workload yang disizing termasuk karakteristik aplikasi yang akan dijalankan. Workload manager tidak melakukan control terhadap bandwidth network, sehingga kita harus benar-benar menjaga kondisi bandwidth network untuk tiap aplikasi dan sistem secara keseluruhan. 5. Konsep Queuing (antrian) Internal physical resources dari sebuah komputer diatur dengan konsep antrian (prosesor, I/O adapter, fisikal disk drive). Masalah sering muncul ketika sebuah sistem yang memiliki kapasitas yang sangat terbatas harus menjalankan
banyak tugas dengan antrian yang melebihi daya tampung sistem tersebut. Ketika hal ini terjadi antrian akan bertambah mengikuti model exponensial. (IBM Redbook System Management, 2000).
2.2 Perangkat Pendukung yang dipakai 2.2.1 Software Konfigurator Dalam melakukan evaluasi hingga menghasilkan suatu konfigurasi server yang ideal untuk suatu aplikasi peneliti menggunakan perangkat pendukung yaitu Server Konfigurator. Server konfigurator ini adalah software utility untuk mendisain konfigurasi server sehingga sesuai dengan kebutuhan customer, tidak overspecification atau under-specification sehingga masih mampu untuk mendukung operasional perusahaan hingga tiga tahun kemudian. A. Intel-base Server Konfigurator : 1. IBM Solution Sizing Tools
Solution Sizing Tools digunakan pada tahap awal sebelum kita membuat konfigurasi. Selama menggunakan tools ini kita harus tetap terhubung dengan internet. Setelah kita memberikan informasi jenis aplikasi yang akan dijalankan pada server tersebut serta beberapa estimasi lainnya misalkan jumlah user, quota tiap user maka
kita akan mendapat jawaban berupa konfigurasi minimal yang harus
dipenuhi untuk aplikasi tersebut. (Sumber: IBM Server Proven Portal)
2. IBM xSeries Configurator Setelah memperoleh informasi konfigurasi minimal yang diperlukan untuk suatu aplikasi, langkah berikutnya yang kita lakukan adalah membuat konfigurasi server dengan bantuan hardware konfigurator. Dalam hal ini Peneliti menggunakan IBM xSeries Configurator sebagai alat bantu dalam membuat konfigurasi hardware server. Untuk mengantisipasi kemungkinan perkembangan data dan user sebaiknya kita memberikan toleransi berupa penambahan kapasitas hardware dari konfigurasi minimal yang disarankan.
Gambar 2.1. IBM xSeries Configurator menu
Gambar 2.2. IBM xSeries Configurator wizard Sumber: IBM eServer xSeries Configurator Ver.7Bb B. UNIX-base Server Konfigurator: IBM eConfig – Configurator for e-business Berbeda dengan konfigurator untuk Intel-base yang telah dijelaskan sebelumnya, konfigurator untuk UNIX-base sifatnya lebih kompleks karena UNIXbase server umumnya digunakan untuk aplikasi spesifik atau yang sudah berskala enterprise. Karakteristik dan arsitektur hardwarenya pun sangat berbeda begitupula sistem operasinya. Untuk membuat konfigurasi UNIX-base server kita juga dapat menggunakan referensi dari Solution Sizing Tools atau berdasarkan analisa kebutuhan user secara langsung berdasarkan workload dan jumlah usernya.
Gambar 2.3. SCPortfolio session window
Sumber: IBM e-Config for e-Business Configurator
Gambar 2.4. SCPortfolio window - UserGuide Example
Sumber: IBM e-Config for e-Business Configurator
2.2.2 Teks Literatur IBM Configuration & Option Guide IBM Configuration & Option Guide adalah teks literatur yang dapat kita jadikan referensi untuk melihat contoh konfigurasi untuk aplikasi-aplikasi umum, misalkan konfigurasi untuk Mail Server, Database Server termasuk optional peripheral untuk meningkatkan performa dan utilisasi server yang akan kita buat konfigurasinya.
Gambar 2.5. Configuration & Option Guide
Sumber: IBM eServer xSeries Option Guide
