Ada dua kelemahan utama:
Beban Anda tidak terdistribusi secara merata. Sesi lengket akan tetap, karena itu namanya. Meskipun permintaan awal akan didistribusikan secara merata, Anda mungkin berakhir dengan sejumlah besar pengguna yang menghabiskan lebih banyak waktu daripada yang lain. Jika semua ini awalnya diatur ke server tunggal, server itu akan memiliki lebih banyak beban. Biasanya, ini tidak benar-benar akan berdampak besar, dan dapat dikurangi dengan memiliki lebih banyak server di cluster Anda.
Proksi pengguna konglomerat menjadi IP tunggal, yang semuanya akan dikirim ke server tunggal. Sementara itu biasanya tidak ada salahnya, lagi selain meningkatkan beban server individu, proksi juga dapat beroperasi dalam sebuah cluster. Permintaan ke F5 Anda dari sistem seperti itu tidak harus dikirim kembali ke server yang sama jika permintaan tersebut keluar dari server proxy yang berbeda di cluster proxy mereka.
AOL pada satu titik menggunakan cluster proxy, dan benar-benar kacau dengan load balancers dan sesi lengket. Sebagian besar penyeimbang beban sekarang akan menawarkan sesi lengket berdasarkan dari rentang bersih C-Class, atau dengan kasus F5, sesi lengket berbasis cookie yang menyimpan simpul akhir dalam cookie permintaan web.
Sementara sesi berbasis cookie harus berfungsi, saya punya beberapa masalah dengan mereka, dan biasanya memilih sesi berbasis IP. NAMUN BESAR: Saya kebanyakan bekerja pada aplikasi internal - jarak tempuh DMZ mungkin bervariasi.
Semua yang dinyatakan, kami telah memiliki beberapa kesuksesan besar dengan situs menjalankan be5 F5 dengan sesi sticky dan sesi In-Proc.
Anda juga mungkin ingin melihat salah satu sistem cache terdistribusi dalam memori seperti Memcached atau Velocity untuk alternatif sesi yang disimpan dalam SQL atau layanan kehabisan memori proc. Anda mendekati kecepatan memori in-proc dengan kemampuan menjalankannya di beberapa server.
