Kebutuhan Performa: Pengguna dan Administrator
Pengguna menilai performa aplikasi berdasarkan pengalaman mereka:
- Apakah aplikasi cepat merespons?
- Apakah ikon hourglass ditampilkan saat operasi latar belakang dilakukan?
- Apakah aplikasi diluncurkan dan ditutup dengan cepat?
- Apakah kesalahan ditangani dengan cara yang dapat dimengerti?
Untuk meringkas, pengguna ingin aplikasi menjadi cepat dan dapat diprediksi.
Sebaliknya, administrator sering menilai performa aplikasi tentang seberapa efisien menggunakan sumber daya jaringan. Administrator mungkin bertanya:
- Apakah aplikasi memiliki overhead rendah dan penggunaan jaringan yang efisien?
- Apakah jumlah koneksi minimum yang digunakan, sehingga server saya dapat melayani pengguna sebanyak mungkin?
- Apakah saya terus-menerus memanggil helpdesk?
Singkatnya, administrator ingin aplikasi menskalakan.
Praktik Terbaik untuk Kebutuhan Performa
Saat mengembangkan aplikasi Windows Sockets, persyaratan performa ini diterjemahkan ke dalam aturan yang berguna.
Memiliki aplikasi jaringan yang diinisialisasi dengan cepat.
Antarmuka pengguna seharusnya tidak perlu menunggu respons jaringan. Beberapa tugas dapat dilakukan sebelum jaringan tersedia, atau tanpa jaringan. Jika jaringan tidak merespons, pengguna mungkin memerlukan antarmuka pengguna untuk operasi sederhana, seperti menutup aplikasi.
Jangan menunggu jaringan dimatikan.
Aplikasi server klien yang ditulis dengan benar menangani pemutusan abortif dengan anggun. Jangan memulai operasi yang berpotensi panjang, seperti menyinkronkan file atau folder dengan server, yang tidak dapat terganggu saat dimatikan. Jaringan tidak responsif secara konsisten, sehingga bahkan operasi kecil dapat terbukti memakan waktu. Berikan umpan balik positif bagi pengguna, termasuk indikasi kemajuan dan perkiraan waktu penyelesaian.
Pastikan antarmuka pengguna responsif.
Responsivitas aplikasi membantu menghilangkan panggilan helpdesk yang tidak perlu. Pedoman yang baik untuk respons interaktif adalah 500 milidetik. Pengguna menyadari jeda lebih dari 500 milidetik sebagai jeda performa. Aplikasi harus cukup responsif untuk memberi pengguna keyakinan tentang aplikasi.
Memeriksa kesalahan jaringan.
Tidak semua kesalahan jaringan sangat penting. Misalnya, aplikasi yang telah menerima atau memposting semua datanya kemungkinan dapat mengabaikan kesalahan saat menutup koneksi. Jangan asumsikan jaringan atau pengguna tersedia; menangani kesalahan tanpa intervensi pengguna, atau mengabaikannya jika kesalahan bersifat nonkritis.
Aplikasi harus menentukan waktu habis yang wajarnya sendiri.
Misalnya, permintaan Windows Sockets connect() dapat memblokir dalam beberapa kondisi selama 21 detik. Aplikasi mungkin perlu memperkenalkan waktu habis mereka sendiri yang sesuai untuk pengguna mereka.
Minimalkan overhead protokol.
Menghemat bandwidth jaringan sebagian tentang meminimalkan overhead protokol yang dikeluarkan oleh aplikasi Anda. Ini juga tentang menghilangkan lalu lintas jaringan yang tidak perlu. Protokol dengan overhead header yang lebih rendah dapat digunakan untuk mentransfer data aplikasi. Misalnya, saat mengirim data nonkritis atau berulang dalam jumlah yang lebih kecil, gunakan UDP dibandingkan dengan TCP untuk mengurangi overhead yang terkait dengan pembentukan dan pemeliharaan koneksi. Jika data yang sama harus dikirim ke beberapa penerima, pertimbangkan multicast. Ketahuilah bahwa aplikasi UDP tidak dikontrol aliran—mendorong di luar bandwidth yang tersedia dapat menyebabkan kegagalan jaringan bencana. Utilitas Netstat dapat digunakan dengan opsi -e dan -s untuk menampilkan statistik untuk berbagai protokol.
Menghemat sumber daya sistem.
Sumber daya sistem dapat dikonsumsi dengan cepat jika penahanan yang tepat tidak digunakan. Misalnya, soket dan koneksi TCP menggunakan sumber daya. Jangan gunakan beberapa koneksi TCP per klien di mana seseorang akan melayani tujuan aplikasi.
Untuk aplikasi transaksi, pengalaman pengguna yang baik dan pemanfaatan jaringan yang rendah bukanlah tujuan yang bertentangan. Jaringan adalah penyempitan. Aplikasi intensif jaringan menghabiskan lebih banyak waktu menunggu, dan aplikasi jaringan yang ditulis dengan baik dirancang untuk meminimalkan waktu tunggu yang tidak perlu, baik untuk antarmuka pengguna maupun untuk transmisi jaringan.
Topik terkait