Ada seorang rakan yang terlibat dalam satu projek besar yang mana melibatkan database yang akan sederhana. Menggunakan Microsoft SQL di backend dan standalone program di frontend. Sebelum projek ini segala langkah-langkah perlu telah diambil dari segi kos, pengurusan, skop kerja dan keupayaan sistem itu sendiri. Sehinggalah terjadi perkara yang sebelum ini tidak disedari. Network bandwith. Situasi: database terletak di HQ dan client terdapat di beberapa tempat yang jauh. Network yang digunakan antara satu sama lain adalah dari 128kb hingga 512kb.
Masalah: Client lambat query data yang didapati dari database. Ada mengatakan selepas login ke sistem, aplikasi akan hang sehingga 3 minit sebelum sedia digunakan. Pada mata kasar, bandwith menjadi faktor penyebab. Tapi perlu diingat, bagaimana sistem internet dapat menanggung data yang amat banyak?
Maka penyebab utama bukanlah bandwith. Setelah bertanyakan bagaimana packet SQL dihantar, didapati 1 row data yang diquery akan mengandungi beberapa column, diasingkan dengan beberapa separator dalam 1 packet. Ini menunjukkan packet SQL agak besar. Ini amat tidak sesuai untuk penghantaran data dalam WAN sebesar 1MB/s. Ianya hanya sesuai dalam network LAN, 10MB/s ke atas dan tiada gangguan langsung seperti WAN.
Keadaan ini amat tidak sesuai jika SQL diletakkan dalam network WAN yang mana bandwith untuk ke LAN dalam 128kb/s atau 512kb/s atau 1Mb/s sekali pun. Kelambatan data yang diquery bukan sahaja bandwidth yang sempit tetapi juga gangguan disepanjang perjalanan data di dalam network.
Apa yang boleh dibuat masa ini tanpa kos adalah reconfigure aplikasi di client dengan tidak query apa-apa data sehingga diminta oleh pengguna. Tidak seperti yang berlaku di mana data diquery semua data selepas login dan data itu tidak berguna sangat.
Keduanya, hanya query data yang diminta oleh pengguna dan bukannya query semua data serta hadnya ditentukan diaplikasi.
Ketiga, kalau boleh kecilkan packet.
Sekurang-kurangnya, dapat mengelakkan projek jadi projek gajah putih.