Performa Aplikasi Web

Abstrak

 Salah satu keberhasilan karakteristik pada sebuah kualitas aplikasi web adalah performa sistem. Alasannya adalah ketika mengembangkan aplikasi web, kita harus menganalisis waktu. Kita bisa menggunakan salah satu model atau metode pengukuran, tergantung pada tahap proses pembangunan. Diantaranya model operasional, jaringan antrian, dan model simulasi umum untuk melihat contoh-contoh dari teknik pemodelan. Model operasional dan jaringan antrian yang ditandai dengan tingkat ekspresif abstraksi yang tinggi dan rendah, tetapi mereka mudah untuk membuat dan menganalisis, dan mereka cocok untuk perkiraan performa awal, misalnya dengan menyebutkan hambatan performa. Benchmark sering digunakan untuk membandingkan sistem. Patokan adalah suatu proses pengukuran yang menguji sistem di bawah standar beban kerja. Setelah metode pengukuran atau pemodelan telah mendeteksi masalah performa, langkah berikutnya melibatkan langkah-langkah untuk meningkatkan performa. Dalam hal ini, kita memiliki pilihan antara up-grading perangkat keras, tuning perangkat lunak, dan menerapkan strategi caching atau replikasi untuk mempersingkat waktu respon. Selain siklus analisis performa tradisional dan performa siklus peningkatan, manajemen performa merupakan pendekatan baru yang mencoba untuk menggabungkan pengukuran, analisis, dan meningkatkan tindakan, serta untuk mengotomatisasi interaksi mereka.

Kata kunci : web, performa, model operasional, jaringan antrian, model simulasi, ekspresif abstraksi, akurasi, benchmark, patokan, up-grading, tuning, caching, replikasi, analisis

1. Pendahuluan

Salah satu keberhasilan karakteristik kualitas aplikasi Web adalah performa sistem. Terutama untuk mengirimkan antara permintaan dan menerima jawaban. Dalam hal ini,”8-detik aturan” adalah terkenal,ia mengatakan bahwa waktu respon dari 8 detik dan seterusnya, mayoritas pengguna menghentikan sambungan, tidak lagi bersedia untuk menunggu respon (tentu saja ada pengecualian untuk transaksi kritis misalnya  transaksi pembayaran, di mana kecenderungan batal lebih rendah). Performa diwujudkan dalam waktu respon yang tinggi, menyebabkan situasi di mana pengguna mengklasifikasikan situs sebagai buruk atau bahkan tidak terjangkau, mencari tempat lain untuk informasi yang mereka tertarik untuk e-commerce. Analisis dan evaluasi performa harus ada, karena itu menjadi bagian integral dari pengembangan dan pengoperasian aplikasi Web. Dalam hal ini, tiga hal yang relevan dalam praktek:

  • The “klasik” analisis performa (PA), yang menentukan jumlah performa untuk diberikan sistem (aplikasi dan platform runtime) dan tingkat beban yang diberikan (frekuensi dan jenis permintaan tiba di sistem).
  • Kapasitas perencanaan, yang mendefinisikan tingkat layanan untuk metrik performa, dan mengidentifikasi sistem yang cocok dimensioning untuk tingkat beban yang diberikan.
  • Stress test, yang menentukan beban maksimum sistem tertentu dapat memproses bawah didefinisikan tingkat layanan.

Pendekatan dasar untuk analisis performa dapat dibagi menjadi langkah-langkah berikut, terlepas dari masalah masing-masing:

  1. Menentukan sistem yang akan dipelajari dan metrik nya.
  2. Mencirikan beban kerja.
  3. Pilih teknik analisis dan alat-alat, dan menjalankan percobaan.
  4. Mewakili dan menginterpretasikan hasilnya.
  5. Jika perlu, meningkatkan dan mengoptimalkan performa sistem.

Tergantung pada masalah (analisis performa klasik, perencanaan kapasitas, stress test), masing-masing langkah-langkah, dan khususnya metode yang diterapkan dan teknik yang dibahas dalam bagian 4-8, memiliki makna yang berbeda. Untuk lebih memahami masalah, bagian 2 menjelaskan istilah “Performa”, dan Bagian 3 membahas karakteristik khusus dari performa aplikasi web. Sebagai penutup, bagian 9 memberikan pandangan tentang manajemen performa sebagai pendekatan terpadu dan otomatis untuk analisis performa dan perbaikan.

2. Apa itu Performa?

Metrik performa biasanya dinyatakan dalam waktu respon (R), throughput (X), atau pemanfaatan (U) dari sistem, tergantung pada beban yang akan diproses. Waktu respon secara umum didefinisikan sebagai waktu antara mengirimkan permintaan ke sistem dan menerima jawaban dari sistem itu. Menyatakan Throughput berapa banyak permintaan dapat dilayani per satuan waktu, dan pemanfaatan memberitahu kita persentase di mana sistem sedang sibuk. Mengambil tampilan (disederhanakan) awal, kita dapat menggambarkan beban kerja dengan jumlah permintaan yang tiba di sistem per satuan waktu, dengan asumsi hubungan linear antara beban kerja dan throughput, didefinisikan sebagai jumlah permintaan yang dilayani per satuan waktu. Meskipun throughput yang sebenarnya meningkatkan nilai linear pada beban kerja yang rendah (lihat Gambar 1), kemudian mendekati definisi atas batas asimtotik.

gbr 1

Gambar 1 kurva throughput dan waktu respon sebagai fungsi dari beban kerja.

Batas atas ditentukan oleh hambatan sistem (lihat Bagian 6 untuk perhitungan nilai ambang batas), dan bahkan bisa di drop lagi ketika sistem mendapat kelebihan beban. Jika kita ingin memaksimalkan throughput untuk melayani sebagai banyak permintaan per unit waktu mungkin, maka strategi yang mengambil sistem sedekat mungkin dengan maksimum teoritis kapasitas akan optimal. Namun,kita harus mempertimbangkan bahwa waktu respon kenaikan sejalan dengan throughput yang meningkat, yang berarti bahwa secara umum itu bukan strategi yang baik untuk memaksimalkan throughput untuk sistem informasi interaktif. Ini adalah alasan mengapa waktu respon biasanya juga digunakan sebagai metrik performa untuk aplikasi Web. Formulasi khas performa, misalnya seperti formulasi yang digunakan dalam beberapa benchmark Web (misalnya, SpecWeb; lihat bagian 6.3) menyatakan throughput maksimum, yang didefinisikan oleh permintaan HTTP disajikan dalam interval waktu tertentu, di mana nilai ambang batas yang diberikan untuk waktu respon tidak terlampaui. Ini nilai ambang yang dikenal sebagai service level agreement (SLA), dan throughput yang berkaitan nilai ini disebut sebagai kapasitas sistem nominal. Analisis performa bertujuan untuk menentukan hubungan antara indikator performa (waktu respon, throughput, dan pemanfaatan), beban kerja, dan performa yang relevan dari sistem yang diteliti. Kita dapat menggunakan pengukuran atau metode pemodelan untuk menganalisis performa. Bila menggunakan alat ukur teknik, tentu saja kita membutuhkan suatu cara untuk mengakses sistem yang ada (lihat Gambar 2).

gbr 2

Gambar 2 Tinjauan metode untuk evaluasi kinerja.

Metode pemodelan tidak selalu memerlukan sistem yang ada untuk analisis, performa abstrak mereka terkait karakteristik dari deskripsi sistem dan peta mereka untuk model. Tergantung pada kompleksitas model, kita dapat menggunakan proses tambahan analitis atau simulasi untuk menentukan ukuran performa.

3. Apa Yang Mengkarakterisasi Performa Aplikasi Web?

Bagian sebelumnya menjelaskan bahwa pengguna melihat performa aplikasi Web terutama pada waktu respon. Sebagian besar pengguna aplikasi desktop “tradisional” yang mengalami evaluasi performa dan mengetahui kegiatan sumber daya-intensif, memerlukan waktu respon lebih lama. Banyak aplikasi menawarkan informasi yang relevan bagi pengguna untuk memperkirakan waktu proses yang diperlukan untuk suatu kegiatan, atau waktu yang tersisa (misalnya, progress bar saat menyimpan file). Sayangnya, transparansi ini tidak tersedia untuk aplikasi web yang terbaik. Dan meskipun dampak dari performa buruk yang dirasakan, pengguna jarang memberikan informasi tentang penyebab masalah atau bantuan yang diberikan. Pengguna tidak dapat merasakan perbedaan yang jelas antara mengklik link yang menunjuk ke halaman HTTP statis, dan mengklik link yang memicu penciptaan dinamis halaman, tetapi waktu respon bisa sangat berbeda. Performa masing-masing Web aplikasi dapat berada di bawah nilai ambang batas yang ditetapkan, namun fluktuasi yang kuat di Web yang performa aplikasi itu sendiri dapat menyebabkan pengguna sulit untuk mendapatkan, tidak puas, dan kecewa tentang kegunaan aplikasi ini.

Internet sebagai jaringan antara klien dan server dalam bentuk yang sekarang tidak menawarkan cara untuk menjamin kualitas layanan. Sebuah penyedia layanan hanya dapat menyebarkan bandwidth yang cukup di server atau server mereplikasi, tetapi mereka tidak dapat menjamin bandwidth yang cukup sepanjang jalan ke klien. Dan pengembang tidak memiliki pengaruh pada performa klien. Oleh karena itu, penting tidaknya hanya untuk menguji fungsi Aplikasi web pada platform yang berbeda, tetapi juga untuk menjalankan tes performa melalui jaringan beberapa koneksi dan jenis klien.

Metode diketahui dari analisis “klasik” performa (lihat Gambar 2) juga dapat digunakan untuk Aplikasi web, tetapi teknik-teknik khusus dan alat-alat harus disesuaikan dengan karakteristik aplikasi web. Metode yang relevan akan dibahas dalam bagian berikut. Salah satu aspek yang paling penting dalam hal ini adalah lalu lintas dan pekerjaan karakterisasi beban, karena sangat sulit untuk memprediksi perilaku pengguna dan konteks penggunaan karena homogenitas dan sejumlah besar pengguna potensial.

Dan akhirnya, pengembangan aplikasi Web  berumur pendek, mewujudkan dirinya dalam jangka pendek pengembangan siklus dan operasi yang relatif panjang dan fase pemeliharaan. Banyak pembangunan proses tidak mengintegrasikan analisis performa untuk waktu dan alasan biaya, kompensasi kekurangan ini kemudian dengan memonitor sistem selama operasi normal.

4. Sistem Definisi dan Indikator

Setiap evaluasi performa harus dimulai dengan definisi dan batas dari System Under Test (SUT). Ketika menganalisis aplikasi Web, biasanya akan mencakup aplikasi Web (set) sendiri, server Web dan aplikasi server (hardware dan software) yang akan digunakan, koneksi jaringan antara server, antara klien dan server, dan klien itu sendiri. Analisis SUT biasanya mempelajari performa dari komponen Component Under Study (cus) lebih dekat. Misalnya, CUS bisa menjadi perangkat lunak komponen dari aplikasi Web, atau CPU dari server Web. Kita bisa, karena itu, abstrak menggambarkan SUT sebagai seperangkat komponen, yang subset telah diidentifikasi sebagai cus (lihat Gambar 3). Dalam sebuah SUT, kita membedakan antara beban menciptakan komponen, yaitu, klien,

gbr 3

Gambar 3 Komponen-berorientasi pandangan sistem sebagai kotak hitam.

dan beban-pengolahan komponen, yaitu server, yang umumnya disebut sebagai stasiun di analisis performa lingo. Dalam konteks ini, stasiun tidak hanya bisa dikendalikan secara keseluruhan, tetapi juga komponen dari sebuah server, yaitu stasiun dapat menjadi bagian sistem sewenang-wenang yang menyediakan layanan untuk klien dan membutuhkan waktu untuk proses permintaan. Dalam Tingkatan ini semua beban-komponen ke dalam menciptakan satu pun “sumber”, dan semua beban pengolahan komponen menjadi satu stasiun agregat tunggal. Ini terlihat dari SUT juga dikenal sebagai model kotak hitam untuk analisis performa. Model ini hanya terlihat pada karakteristik aliran masuk dari permintaan, dan aliran keluar dari menyelesaikan pekerjaan, dan ukuran diturunkan, seperti waktu respon sistem berarti. Metode yang digunakan untuk analisis yang terakhir disebut “multi-kelas” model, dan teknik analisis umumnya agak rumit, tapi mereka memberikan asumsi lebih rinci tentang perilaku performa aplikasi Web.

5. Karakterisasi Beban Kerja

Memilih beban kerja yang tepat sangat menentukan untuk studi evaluasi performa untuk menjadi sukses dan pasokan hasil yang berarti. Ketika memilih beban kerja model, kita harus mempertimbangkan dua dimensi (lihat Gambar 4). Kekhawatiran diferensiasi pertama yang executability dari model beban kerja yaitu ketika teknik pengukuran harus digunakan untuk evaluasi performa, atau non-executability pada teknik model aplikasi. Itu diferensiasi kedua menyangkut pembatasan untuk beban kerja yang sebenarnya (yang bisa dijalankan oleh definition), atau penggunaan beban kerja buatan, yang dihasilkan oleh generator beban dari pada oleh pengguna yang sebenarnya

gbr 4

Gambar 4 Taksonomi dari model beban kerja.

Penggunaan beban kerja nyata sebenarnya kurang signifikan untuk prediksi performa. Meskipun kita bisa mempelajari sistem di bawah beban nyata yaitu secara real-time operasi, hanya dengan mengukur itu, itu hanya akan menunjukkan kepada kita posteriori apakah dan ketika masalah performa telah terjadi. Ekstraksi Karakteristik yang dihasilkan dari mempelajari beban nyata (Williamson et al. 2005), dan menggabungkan elemen-elemen khas beban kerja nyata (misalnya, memilih permintaan khas), dan apa yang disebut beban kerja sintetis dalam percobaan adalah metode yang lebih berguna. Beban kerja sintetis berarti bahwa permintaan identik dengan yang terjadi di dunia nyata digunakan, tetapi dengan artifisial diciptakan frekuensi dan urutan. Sebagai contoh adalah mungkin untuk mempelajari bagaimana sistem akan berperilaku di bawah beban kerja berubah (yaitu, jenis yang sama permintaan, tetapi dengan tingkat kedatangan yang berbeda). Beban kerja tidak dapat bermakna jika dijelaskan oleh salah satu jenis permintaan tunggal, juga bukan berarti model itu sebagai nilai rata-rata dari himpunan semua permintaan, terutama untuk yang kompleks Aplikasi web. Seperti model beban kerja tunggal-kelas mudah untuk menangani (berkaitan dengan baik yang pemodelan dan pengukuran) dan dapat digunakan untuk perkiraan awal dari performa sistem.

6. Teknik Analytical

6.1  Analisis Operasional

Analisis operasional mengambil beberapa terukur dasar (operasional) kuantitas, terutama jumlah permintaan selesai (C) dalam periode observasi ditetapkan T, untuk melihat komponen sistem untuk tujuan analisis. Mengacu pada komponen sistem sebagai k, kita dapat menentukan throughput stasiun k, sebagai Xk = Ck / T. Jika kita memperkenalkan Bk kuantitas, untuk menentukan waktu selama stasiun itu memproses permintaan, maka kita dapat menentukan waktu layanan untuk permintaan di stasiun k sebagai sk = Bk / Ck. D permintaan untuk layanan dalam  stasiun menempatkan waktu pelayanan dalam kaitannya dengan jumlah total menyelesaikan permintaan: Dk = sk * Ck / C = Bk / C. Demikian pula, kita dapat menulis Xk = X * Ck / C untuk mendefinisikan hubungan antara throughput sistem, X, dan throughput per komponen, Xk. U pemanfaatan stasiun didefinisikan sebagai waktu selama stasiun sibuk, yaitu, Uk = Bk / T = (Bk / T) * (Ck / Ck) = (Bk / Ck) * (Ck / T) = Xk * sk = X * Dk. Hubungan ini dikenal sebagai hukum pemanfaatan. Contoh: Mari kita lihat server Web yang terdiri dari satu CPU dan dua disk. Sistem ini telah diamati oleh pengukuran selama satu jam. Sebanyak 7200 permintaan telah selesai selama periode ini. Pemanfaatannya adalah sebagai berikut: CPU = 10%, disk 1 = 30%, disk 2 = 40%. Kita bisa menggunakan informasi ini untuk menentukan permintaan layanan per komponen sebagai berikut:

                X = C / T = 7200/3600 permintaan per detik = 2 permintaan per detik

                DCPU = UCPU / X = 0,1 / 2 detik = 50 msec

                Ddisk1 = Udisk1 / X = 0,3 / 2 sec = 150 msec

                Ddisk2 = Udisk2 / X = 0,4 / 2 sec = 200 msec

Hukum Little (Little 1961) mendefinisikan hubungan antara waktu respon, throughput, dan jumlah permintaan dalam sistem (N).Jika permintaan menghabiskan waktu unit R rata-rata dalam sistem, dan jika X permintaan per satuan waktu selesai rata-rata, maka rata-rata N = R * X permintaan harus menghabiskan waktu dalam sistem. Contoh: Mari kita berasumsi bahwa waktu rata-rata respon dari semua 7200 permintaan dari atas Misalnya ditemukan menjadi 0,9 detik. Akibatnya, rata-rata N = R * X = 0,9 * 2 = 1,8 permintaan menghabiskan waktu di server Web selama periode pengamatan. Hukum kecil juga dapat diterapkan pada stasiun tunggal, dan kemudian didefinisikan sebagai Nk * = Rk Xk. Selain hukum-hukum dasar yang dapat digunakan untuk menurunkan jumlah performa dari ukuran data, analisis operasional juga menawarkan cara untuk menganalisis kemacetan. Bottleneck adalah didefinisikan sebagai stasiun yang pertama mencapai utilisasi 100% dengan meningkatnya beban. Kita bisa melihat dari hukum pemanfaatan Uk = X * Dk bahwa ini adalah stasiun dengan permintaan layanan terbesar. Kita juga dapat memperoleh batas atas untuk throughput sistem dari ini: X <1/Dk. Batas atas biasanya tidak dapat didefinisikan untuk waktu respon, tapi kita dapat mendefinisikan batas bawah keluar dari pertimbangan bahwa permintaan menghabiskan setidaknya unit Dk waktu di setiap stasiun, sehingga thatr> _kDk. Analisis menjadi lebih rumit jika kita memperkenalkan kelas yang berbeda dari permintaan. Kami tidak akan menggambarkan semua hukum operasional untuk multi-kelas secara rinci, karena formula yang sesuai dan contoh aplikasi dapat ditemukan dalam literatur, misalnya, di (Jain 1991) atau (Menasc’e dan Almeida 2002). Untuk analisis operasional, kita harus selalu tahu jumlah performa beberapa (misalnya, dari pengukuran), jumlah tambahan maka dapat diturunkan dari data yang diukur atau diperkirakan. Jaringan antrian dan model simulasi memungkinkan untuk menentukan performa dalam murni analitis Cara didasarkan hanya pada deskripsi beban kerja dan sistem.

6.2  Antrian Jaringan dan Model Simulasi

Jaringan antrian merupakan teknik pemodelan untuk semua sistem yang dicirikan oleh seperangkat komponen yang mengirimkan permintaan (disebut sumber), dan satu set komponen yang proses permintaan (Disebut stasiun, seperti yang kita ketahui dari pembahasan di atas). Sebuah sumber mengirimkan permintaan dari c tipe dengan tingkat λc ke jaringan stasiun. Berbeda dengan analisis operasional, jaringan antrian melihat permintaan diproses dalam stasiun lebih dekat, membedakan antara ruang tunggu (dan terkait waktu tunggu, Wi) dan area layanan yang sebenarnya (dengan waktu pelayanan si), seperti yang ditunjukkan pada Gambar 5.

gbr 5

Gambar 5 Sebuah stasiun dalam jaringan antrian.

Untuk stasiun tunggal, sekarang kita bisa menyiapkan grafik keadaan transisi, di mana negara ditentukan oleh jumlah permintaan dalam antrian atau di area servis. Keadaan transisi didefinisikan oleh kedatangan kali dan layanan kali masing-masing oleh kedatangan dan tingkat pelayanan. Kami sekarang dapat memvalidasi sistem seperti sehubungan dengan adanya distribusi stasioner, sehingga kita dapat menentukan probabilitas untuk jumlah permintaan dalam antrian dan dalam jangkauan layanan. Kami kemudian mengambil probabilitas ini untuk menghitung nilai yang diharapkan untuk takaran performa. Jika kita melihat bagaimana beberapa stasiun layanan seperti berinteraksi (lihat Gambar 6), setiap stasiun jaringan dipisahkan disebut dapat dilihat secara terpisah dan dianalisis dengan menghitung stasioner distribusi. Sebuah jaringan terpisah adalah jaringan di mana bercabang probabilitas dan layanan kali dari stasiun tidak tergantung pada distribusi permintaan atas stasiun lain. ini berarti bahwa kita dapat menghitung rasio kunjungan statis (berlabel vk pada Gambar 6) dan tingkat kedatangan per stasiun. Atau, kita bisa mempersiapkan sebuah diagram transisi negara untuk seluruh sistem, di mana suatu negara dijelaskan oleh vektor dengan jumlah permintaan di masing-masing stasiun layanan.

gbr 6

Gambar 6 Sebuah antrian jaringan dengan tiga stasiun layanan.

Teknik ini dikenal sebagai konvolusi, kompleksitas perhitungan meningkat secara eksponensial dengan jumlah permintaan dan stasiun (Jain 1991). Kedua solusi menggunakan dipisahkan jaringan dan yang menggunakan konvolusi menentukan probabilitas untuk distribusi permintaan seluruh komponen dan menurunkan jumlah performa tambahan dari itu.

6.3  Mengukur Pendekatan

Sebuah alat ukur pendekatan sistem yang ada (baik sistem nyata dalam operasi normal atau sistem tes). Untuk tujuan ini, pendekatan pengukuran menggunakan timer untuk mengukur waktu di welldefined sistem poin, atau menggunakan counter untuk menghitung terjadinya peristiwa tertentu, dan dasar data yang mereka kumpulkan dapat digunakan untuk menyimpulkan jumlah performa. Sebuah generator beban dapat berupa program yang ditulis sendiri atau script yang mengirimkan permintaan HTTP ke server, dan menentukan waktu respon dari perbedaan waktu klien dari pada menafsirkan respon untuk tujuan visualisasi dalam browser Web.

Tabel 1 Hardware dibandingkan software monitoring (Jain 1991, p.100)

tab 1

Suatu bentuk khusus dari alat ukur merupakan benchmark disebut. Patokan adalah buatan Model beban kerja yang berfungsi untuk membandingkan sistem. Untuk menggunakan patokan, sistem harus memproses satu set didefinisikan permintaan, dan performa sistem selama proses ini maka bisa dinyatakan dalam satu metrik tunggal. Sementara beberapa benchmark telah menjadi populer di bidang lain untuk membandingkan performa sistem (misalnya, patokan Linpack untuk menghitung superkomputer tercepat dari dunia, benchmark yang khusus menguji performa Aplikasi web dan platform eksekusi mereka masih dalam tahap awal. Salah satu contoh adalah SpecWeb patokan yang menetapkan standar beban kerja yang terdiri dari satu set permintaan statis dan dinamis.

 7. Mewakili dan Interpreting Hasil

Langkah terakhir dari studi PA biasanya melibatkan representasi dan interpretasi hasil. Untuk representasi, kita harus memutuskan mana metrik kita yang ingin diwakili dan bagaimana mereka harus divisualisasikan. Sebagian besar kasus merupakan nilai rata-rata dari jumlah performa, dan penyebaran atau persentil nilai sangat relevan untuk aplikasi Web. Sebagai contoh, kita dapat menggunakan nilai persentil untuk menentukan yang persentase permintaan kita ingin mempertahankan tingkat jasa yang telah disepakati. Memperhatikan bahwa teknik analisis yang kami pilih dapat membatasi kemungkinan mewakili hasil, misalnya semua analisis nilai rata-rata yang memungkinkan anda tentukan adalah nilai rata-rata. Bentuk lain dari pemanfaatan mewakili adalah grafik Kiviat (di sebelah kanan pada Gambar 7). Bentuk grafik menunjukkan persentase waktu menganggur dan produktif per komponen pada sumbu standar. Grafik ini bersifat biasanya berbentuk bintang dan sangat cocok untuk perbandingan beberapa sistem.

gbr 7

Gambar 7 Contoh grafik untuk memvisualisasikan pemanfaatan.

 8. Optimasi Performa Metode

Langkah-langkah untuk meningkatkan performa aplikasi web yang terutama ditujukan untuk memperpendek waktu tanggapan atau throughput meningkat. Namun, tujuan ini dapat dicapai hanya memberikan kita mengidentifikasi dan menghapus hambatan (atau hambatan) dalam suatu sistem. Kami menyebutnya komponen tertinggi dengan pemanfaatan hambatan utama, yang juga terutama membutuhkan performa meningkatkan langkah-langkah. Sebuah hambatan pada dasarnya dapat dihilangkan dengan mengurangi beban pada hambatan komponen (misalnya, mengurangi ukuran file ditransmisikan untuk menghapus beban dari jaringan), atau meningkatkan performa dari komponen itu sendiri (misalnya, meningkatkan bandwidth jaringan koneksi). Setelah kami menghapus hambatan utama, kita biasanya mengamati bahwa komponen lain akan menjadi hambatan, komponen ini dikenal sebagai hambatan sekunder. Sebuah optimal sistem dari perspektif performa sistem yang seimbang, di mana pemanfaatan semua komponen sistem (sekitar) yang sama, sehingga tidak akan ada hambatan utama. Sebuah strategi yang optimal untuk meningkatkan performa harus, karena itu, tidak hanya melihat satu pun komponen, tetapi mempertimbangkan sistem secara keseluruhan. Bagian berikut membahas metode optimasi performa dipilih; lihat (Tracy et al. 1997) atau (Killelea 2002) untuk penjelasan rinci.

 8.1  Percepatan Dalam Aplikasi Web

Kelas pertama metode berlaku untuk aplikasi Web sendiri, yang berarti bahwa itu harus diperhitungkan dalam proses pengembangan aplikasi. Kelas ini meliputi definisi oleh semua metode yang bertujuan untuk memperpendek waktu eksekusi dari aplikasi pada server, tetapi juga adaptasi dalam aplikasi Web yang mempersingkat waktu komunikasi dengan klien, atau menyebabkan waktu eksekusi lebih pendek pada klien.

 8.2  Mengurangi Waktu Transmisi

Untuk aplikasi web di mana klien dan server yang terhubung melalui WAN, jaringan sering mewakili kemacetan. Protokol internet di masa depan akan mendukung lebih banyak pilihan untuk bernegosiasi kualitas layanan antara klien dan server.

 8.3  Server Tuning

Kelas terakhir dari metode ini bertujuan untuk meningkatkan platform eksekusi aplikasi Web. Kelompok tersebut termasuk upgrade hardware terutama (ekspansi memori utama, CPU percepatan, lebih cepat disk) dan pengaturan optimal di server Web (misalnya, menonaktifkan lookup DNS untuk file log). Kami merujuk pembaca kami ke manual server Web mereka sukai dan informasi yang relevan dan forum diskusi di Internet (misalnya,. http://httpd.apache.org/docs/misc/perf.htmlorhttp://www.microsoft.com/serviceprovider/whitepapers/tuningiis.asp)

9. Kesimpulan dan Harapan Kedepan

Mengingat kecenderungan aplikasi web di mana-mana dan akan terjadi peningkatan kompleksitas konteks penggunaan, siklus performa tradisional evaluasi akan gagal karena biaya, waktu dan strategi reaktif akan gagal karena perlunya perubahan sering, yang mungkin sudah ketinggalan jaman pada saat penggunaan. Performa manajemen (Kotsis 2004) mencoba untuk mengambil pandangan yang berbeda, embedding performa prediksi metode dan metode optimalisasi performa secara langsung dan proaktif dalam sistem. Metrik performa dikumpulkan dengan langsung mengukur setiap komponen sistem, yaitu komponen adalah “sadar” dari performanya. Melihat data performa masa lalu kemudian harus membantu untuk memprediksi beban masa depan dan performa secara lokal di komponen itu sendiri, dan aktor correctively harus campur tangan sebelum masalah benar-benar dapat timbul. Konsep ini telah digunakan dalam disederhanakan formulir untuk aplikasi video conference. Sebagai contoh, server dan klien dapat bernegosiasi gambar yang sesuai dan kualitas suara, tergantung pada bandwidth yang tersedia. Beberapa bidang lainnya aplikasi juga telah berhasil. Salah satu contoh adalah kecenderungan umum ke arah adaptif komponen sistem, yang sadar konteks eksekusi mereka, sehingga mereka dapat beradaptasi dengan layanan yang sesuai. Sebuah studi rinci di bidang performa “kesadaran”, khususnya memilih sensor yang cocok, prediksi metode dan aktor, masih menjadi subyek penelitian yang sedang bekerja. Untuk menindaklanjuti kerja penelitian saat ini, kita merujuk pembaca kami untuk konferensi yang relevan, misalnya, Sigmetrics (Bersemangat dan Williamson 2005) atau maskot (Fujimoto dan Karatza 2005).

 10. Daftar Pustaka

Kappel Gerti, Proll Birgit, Reich Siegfried, “Web Engineering”, Heidelberg, Germany, 2003.

Tinggalkan Balasan

Isikan data di bawah atau klik salah satu ikon untuk log in:

Logo WordPress.com

You are commenting using your WordPress.com account. Logout / Ubah )

Gambar Twitter

You are commenting using your Twitter account. Logout / Ubah )

Foto Facebook

You are commenting using your Facebook account. Logout / Ubah )

Foto Google+

You are commenting using your Google+ account. Logout / Ubah )

Connecting to %s