Temukan dan perbaiki 15 hambatan kinerja

"Kemacetan" adalah istilah deskriptif yang luar biasa. Ini menggambarkan kendala buatan pada beberapa bentuk komunikasi, interaksi, atau transfer informasi. Dan itu membuat orang percaya bahwa kombinasi ajaib dari keberuntungan, uang, dan kecerdikan dapat menghancurkan kemacetan itu dan membiarkan semua hal baik mengalir.

Masalah dengan kemacetan kinerja adalah bahwa mereka sulit untuk diidentifikasi. Apakah itu CPU? Jaringan? Sedikit kode yang kikuk? Seringkali, pelakunya yang paling jelas sebenarnya adalah hilir dari sesuatu yang lebih besar dan lebih membingungkan. Dan ketika teka-teki kinerja tetap tidak terpecahkan, manajemen TI mungkin menemukan dirinya dihadapkan pada pilihan Hobson antara mengakui ketidaktahuan dan membuat alasan.

Untungnya, seperti diagnosis medis atau pekerjaan detektif, pengalaman membantu. Berdasarkan pengalaman bertahun-tahun kami dalam mendalami dan bereksperimen, kami telah mengumpulkan 15 penyakit yang paling mungkin - dan solusi yang disarankan - untuk membantu operasi TI Anda melacak dan memecahkan masalah kinerja.

Beberapa dari kemacetan ini lebih jelas daripada yang lain. Kemungkinan besar, Anda memiliki sesuatu untuk dikatakan tentang spoiler licik Anda sendiri (dan kami ingin mendengar cerita Anda tentang mereka). Namun dengan mengidentifikasi pembunuh kecepatan umum di seluruh disiplin ilmu TI, kami berharap dapat memulai pencarian Anda untuk menciptakan infrastruktur berkinerja tertinggi yang dimungkinkan oleh sumber daya Anda.

No. 1: Mungkin bukan servernya

Peningkatan server digunakan untuk membuat semua perbedaan, itulah mengapa gergaji lama "Ketika semuanya gagal, buang lebih banyak perangkat keras padanya" tetap ada hari ini. Itu masih benar dalam beberapa kasus. Tapi seberapa banyak TI yang benar-benar intensif dalam komputasi? Umumnya, Anda dapat menghemat banyak waktu dan uang dengan mengalihkan perhatian Anda dari perangkat keras server. Ujung bawah spektrum server memiliki lebih dari cukup tenaga kuda untuk menangani tugas sehari-hari.

Inilah salah satu contoh konkretnya. Pada jaringan dengan lebih dari 125 pengguna, pengontrol domain Windows tua tampaknya siap untuk diganti. Server ini awalnya menjalankan Windows 2000 Server dan ditingkatkan ke Windows Server 2003 beberapa waktu lalu, tetapi perangkat kerasnya tetap tidak berubah. HP ML330 dengan CPU 1Ghz dan RAM 128MB ini berfungsi sebagai pengontrol domain Active Directory yang menjalankan semua peran AD FSMO, menjalankan layanan DHCP dan DNS, serta menjalankan IAS (Layanan Otentikasi Internet).

Molase, bukan? Faktanya, itu sebenarnya melakukan pekerjaan dengan baik. Penggantinya adalah HP DL360 G4 dengan CPU 3Ghz, RAM 1GB, dan drive SCSI 72GB yang mencerminkan. Dengan semua layanan tersebut, hampir tidak ada beban sama sekali - dan perbedaan kinerjanya tidak terlalu mencolok.

Sangat mudah untuk mengidentifikasi aplikasi yang akan memakan semua CPU dan memori Anda, tetapi mereka cenderung sangat terspesialisasi. Untuk hampir semua hal lainnya, kotak komoditas yang sederhana akan berhasil.

No. 2: Mempercepat kueri tersebut

Anda dapat membuat aplikasi paling bagus di dunia, tetapi jika akses ke server database back-end menciptakan hambatan, pengguna akhir atau pelanggan Anda tidak akan senang. Jadi, sesuaikan kueri database tersebut dan maksimalkan kinerja.

Tiga ukuran dasar dapat membantu Anda meningkatkan kinerja kueri. Pertama, sebagian besar produk database menyertakan alat (seperti DB2 UDB untuk iSeries 'Visual Explain) yang dapat membedah kueri Anda selama pengembangan, memberikan umpan balik pada sintaks dan perkiraan waktu dari berbagai bagian pernyataan SQL. Dengan menggunakan informasi ini, temukan bagian terpanjang dari kueri dan uraikan lebih jauh untuk melihat bagaimana Anda dapat mempersingkat waktu eksekusi. Beberapa produk database juga menyertakan alat saran kinerja, seperti Monitor Diagnostik Database Otomatis Oracle, yang memberikan rekomendasi (seperti menyarankan Anda membuat indeks baru) untuk mempercepat kueri.

Selanjutnya, aktifkan alat pemantauan database di server pementasan. Anda mungkin menggunakan produk pemantauan pihak ketiga, seperti NetVigil Fidelia, jika database Anda tidak memiliki dukungan pemantauan. Dengan monitor diaktifkan, hasilkan lalu lintas ke server database menggunakan skrip pengujian beban. Periksa data yang dikumpulkan untuk melihat bagaimana kinerja kueri Anda saat sedang dimuat; informasi ini dapat mengarahkan Anda ke beberapa penyesuaian kueri lebih lanjut.

Jika Anda memiliki sumber daya server yang cukup untuk meniru lingkungan produksi beban kerja campuran dengan cukup dekat, Anda dapat menjalankan putaran ketiga penyetelan kueri menggunakan alat pengujian beban, seperti OpenSTA, ditambah pemantauan database untuk melihat bagaimana kueri Anda bekerja bersama aplikasi lain yang mencapai database.

Saat kondisi database berubah - dengan pertumbuhan volume, penghapusan rekaman, dan sebagainya - terus lakukan pengujian dan penyesuaian. Seringkali sepadan dengan usaha.

No.3: Berapa biayanya, perlindungan virus?

Perlindungan virus pada server kritis merupakan kebutuhan dasar, terutama untuk server Windows. Namun, dampaknya bisa menyakitkan. Beberapa pemindai virus lebih menonjol daripada yang lain dan dapat mengurangi kinerja server secara signifikan.

Coba jalankan tes kinerja dengan dan tanpa pemindai virus Anda berjalan untuk menentukan dampaknya. Jika Anda melihat peningkatan yang nyata tanpa pemindai, saatnya mencari vendor lain. Periksa juga fitur tertentu. Nonaktifkan pemindaian waktu nyata, dan sering kali Anda akan meningkatkan kinerja.

Tidak peduli seberapa baik logika bisnis Anda ditulis, saat Anda menerapkannya ke tingkat menengah, Anda perlu menyesuaikan lingkungan runtime server aplikasi untuk memaksimalkan kinerja.

Seperti stereo antik dengan banyak sekali tombol untuk mengutak-atik kualitas suara, server aplikasi dari vendor seperti BEA, IBM, dan Oracle, menyediakan serangkaian kontrol yang memusingkan. Triknya adalah memutar kenop dengan cara yang benar, tergantung pada atribut aplikasi Anda.

No. 4: Memaksimalkan tingkat menengah

Tidak peduli seberapa baik logika bisnis Anda ditulis, saat Anda menerapkannya ke tingkat menengah, Anda perlu menyesuaikan lingkungan runtime server aplikasi untuk memaksimalkan kinerja.

Seperti stereo antik dengan banyak sekali tombol untuk mengutak-atik kualitas suara, server aplikasi dari vendor seperti BEA, IBM, dan Oracle, menyediakan serangkaian kontrol yang memusingkan. Triknya adalah memutar kenop dengan cara yang benar, tergantung pada atribut aplikasi Anda.

Misalnya, jika aplikasi Anda berat servlet, Anda akan ingin mengaktifkan cache servlet. Demikian pula, jika aplikasi Anda menggunakan banyak pernyataan SQL untuk mendukung basis pengguna yang besar, Anda akan ingin mengaktifkan cache pernyataan yang sudah disiapkan dan menyetel ukuran maksimum cache sehingga cukup besar untuk mendukung beban kerja yang dimaksudkan.

Salah satu area utama di mana penyetelan kinerja benar-benar dapat membantu adalah dengan kumpulan koneksi database. Tetapkan koneksi minimum atau maksimum terlalu rendah dan Anda pasti akan membuat hambatan. Setel terlalu tinggi dan Anda mungkin akan melihat perlambatan akibat tambahan overhead yang diperlukan untuk mempertahankan kumpulan koneksi yang lebih besar.

Jika Anda mengetahui beban kerja yang dimaksudkan, sesuaikan runtime server aplikasi dengan mengaktifkan alat pemantauan kinerja seperti IBM's Tivoli Performance Viewer for WebSphere pada server aplikasi pementasan. Hasilkan jumlah beban kerja yang Anda harapkan dengan menggunakan alat penghasil beban, lalu simpan hasil pemantauan dan putar kembali untuk menganalisis kenop mana yang perlu disesuaikan.

Saat dalam produksi, sebaiknya aktifkan pemantauan pasif dengan overhead rendah untuk mengawasi waktu proses. Jika beban kerja Anda berubah dari waktu ke waktu, Anda sebaiknya menjalankan tinjauan kinerja baru.

No. 5: Mengoptimalkan konektivitas jaringan

Sebagian besar server perusahaan tingkat menengah sekarang memiliki NIC gigabit ganda - tetapi kebanyakan dari mereka tidak menggunakan pipa kedua. Selain itu, harga sakelar gigabit telah turun drastis. Dengan tautan 120MBps ke server file Anda, sejumlah klien 100 megabit dapat mencapai akses file kecepatan kabel secara bersamaan.

Bahkan tanpa peralihan gigabit, ikatan NIC harus menjadi kebutuhan pokok. Paling sederhana, menggabungkan dua NIC memberi Anda redundansi, tetapi menambahkan penyeimbangan beban transmisi, dan Anda dapat secara efektif menggandakan bandwidth keluar. Menggunakan tim dengan bantuan sakelar akan memberikan efek yang sama pada lalu lintas masuk. Hampir setiap vendor server utama menawarkan driver tim NIC - dan ada juga utilitas pihak ketiga. Ini adalah peningkatan bandwidth yang besar dan murah.

No 6: Menutup server Web Anda

Apakah benar-benar ada banyak hal yang dapat Anda lakukan untuk menyetel server Web dan memaksimalkan kinerja? Faktanya, ada - terutama dengan menyesuaikan beberapa pengaturan penting agar sesuai dengan lalu lintas produksi yang Anda harapkan.

Untuk server Web yang sudah berproduksi, mulailah dengan mengumpulkan statistik server Web waktu nyata (sebagian besar server Web utama memiliki fungsionalitas tersebut di dalamnya). Kemudian pindah ke staging untuk menentukan parameter mana, jika ada, yang perlu disesuaikan.

Aktifkan alat pemantauan kinerja server Web di server pementasan. Jalankan uji beban dan periksa parameter yang relevan, seperti waktu respons, byte yang dikirim dan diterima, serta jumlah permintaan dan respons.

Parameter utama yang ingin Anda sesuaikan tergantung pada volume lalu lintas termasuk pengaturan caching, threading, dan koneksi.

Aktifkan caching untuk konten yang sering digunakan; beberapa server Web mengizinkan Anda untuk menyimpan file secara dinamis berdasarkan penggunaan, sedangkan yang lain meminta Anda untuk menentukan apa yang akan di-cache. Pastikan ukuran cache maksimum Anda cukup untuk lalu lintas yang Anda harapkan. Dan jika server Web Anda mendukung akselerasi cache, aktifkan juga.

Untuk pengaturan threading dan koneksi, atur minimum dan maksimum sesuai dengan beban kerja yang diharapkan. Untuk koneksi, Anda juga harus menentukan jumlah maksimum permintaan per koneksi dan pengaturan batas waktu koneksi. Jangan tetapkan salah satu dari nilai ini terlalu kecil atau terlalu besar, atau pelambatan dapat terjadi.

No 7: Celakalah WAN

Pikirkan Anda perlu mengklaim kembali bandwidth WAN? Anda dapat dengan mudah menghabiskan banyak uang untuk peralatan pembentuk lalu lintas atau mesin cache dalam upaya untuk mengendalikan penggunaan bandwidth WAN. Tapi bagaimana jika bukan pipanya?

Hal pertama yang pertama: Sebelum Anda membeli sesuatu, dapatkan gambaran yang kuat tentang lalu lintas apa yang melintasi WAN. Alat analisis jaringan seperti Ethereal, ntop, Network Instrument's Observer, atau WildPacket's EtherPeek NX dapat memberi Anda gambaran baru tentang apa yang sebenarnya ada di kawat.

Anda mungkin mendapati bahwa waktu replikasi untuk Active Directory Anda disetel terlalu rendah dan hanya dengan mengonfigurasi interval replikasi yang lebih lama dapat memberi Anda ruang bernapas selama hari kerja. Apakah beberapa pengguna di pemetaan lokasi jarak jauh berbagi ke server yang salah dan menarik file besar di seluruh WAN tanpa menyadarinya? Apakah sisa-sisa jaringan IPX yang telah lama dinonaktifkan masih beredar? Beberapa masalah WAN bermuara pada kesalahan konfigurasi aplikasi, di mana lalu lintas diarahkan ke WAN ketika seharusnya tetap lokal. Laporan rutin tentang pola lalu lintas WAN akan menghemat uang dan sakit kepala.

No. 8: Ayo bermain bagus

Terlalu sering, aplikasi, layanan Web, dan situs Web dari berbagai departemen di seluruh perusahaan bersaing untuk sumber daya server. Meskipun masing-masing komponen ini mungkin disetel dengan baik, aplikasi dari departemen lain yang juga menggunakan kluster produksi yang sama mungkin memiliki kueri yang kurang tepat atau beberapa masalah lain, yang pada akhirnya memengaruhi pengguna atau pelanggan Anda.

Dalam waktu dekat, yang dapat Anda lakukan adalah bekerja dengan administrator sistem Anda dan departemen yang mengalami masalah kinerja untuk mendapatkan penyelesaian bagi pengguna atau pelanggan Anda. Untuk jangka panjang, buat komunitas di semua departemen yang menggunakan cluster produksi tempat objek Anda diterapkan. Bekerja di seluruh tim untuk memastikan bahwa ada dana yang memadai untuk lingkungan pementasan yang benar-benar mewakili lingkungan produksi beban kerja campuran. Pada akhirnya, Anda ingin mengembangkan serangkaian tolok ukur yang dapat digunakan untuk memvalidasi kinerja beban kerja campuran di lingkungan pementasan.

No. 9: Menyimpan, membentuk, membatasi, astaga!

Jika WAN Anda benar-benar berukuran kecil - dan Anda tidak mampu membeli jaringan frame-relay jarak jauh - pembentukan lalu lintas dan caching dapat membantu melepaskan penyumbatan pipa.

Konfigurasi pembentuk lalu lintas lebih merupakan seni daripada sains. Memprioritaskan aplikasi sering kali lebih bersifat politis daripada teknis, tetapi mungkin memiliki efek luar biasa pada performa jaringan yang dirasakan.

Caching adalah binatang yang berbeda sama sekali. Ini membutuhkan lebih sedikit pekerjaan daripada pembentukan lalu lintas, tetapi dampaknya kemungkinan akan lebih kecil. Mesin cache menyimpan dan menyajikan salinan lokal dari data yang biasa diakses untuk mengurangi lalu lintas WAN. Sisi negatifnya adalah konten dinamis tidak dapat benar-benar disimpan dalam cache, sehingga email tidak akan menikmati kinerja yang sama.

10: Penambalan prediktif

Anda tiba di tempat kerja pada hari Senin hanya untuk mengetahui bahwa sekelompok desktop macet atau bahwa kinerja aplikasi penting telah melambat hingga merayap. Setelah menyelidiki, Anda menentukan bahwa tambalan yang diterapkan selama akhir pekan adalah penyebabnya.

Itulah mengapa Anda membutuhkan alat yang mendukung rollback patch. Lebih baik lagi, sertakan pengujian patch sebagai bagian dari strategi pengelolaan patch Anda. Pertama, Anda harus melakukan inventarisasi rutin dari aplikasi dan teknologi yang digunakan di desktop dan server. Kebanyakan alat manajemen sistem, seperti Microsoft SMS, memiliki kemampuan untuk melakukan inventarisasi untuk Anda secara otomatis.

Selanjutnya, mereplikasi aplikasi dan teknologi ke dalam lingkungan pementasan. Jika sistem operasi dan perangkat lunak infrastruktur Anda tidak menyertakan alat pengujian tambalan, dapatkan alat pihak ketiga seperti FLEXnet AdminStudio atau Wise Package Studio.

Sebagai alternatif, Anda dapat menulis beberapa skrip untuk menjalankan platform atau teknologi secara fungsional dengan patch terbaru sedang dimainkan. Anda perlu mengulangi skenario ini (dan menyesuaikan skrip) saat tambalan baru tiba dan saat perubahan perangkat lunak dilakukan.