使用服務器負載均衡的用戶，按照簡單分類，可以為以下3大類：
第一類，性能要求。
流量猛增，單個服務器自然招架不住。這裡面的客戶包括各個上規模的網站，不管是做內容，做社區，做婚介，做直銷，也不管你是賣衣服，賣包包還是賣茶葉，用戶數增長帶來的流量增長，使用負載均衡是早晚的事。而且針對廣大的網站客戶，通常簡單的4層流量分擔已經不能夠滿足他們的需求。內存緩存，硬件壓縮，連接復用等等可以降低服務器負載的ADC功能越來越成為網站客戶的必備手段。另外一點是網站客戶的應用復雜，經常會有多個域名對應同一個IP以及同一服務器響應多個不同域名的情況，根據host （域名）做switch, 甚至7層的流量分發腳本要求也是非常常見的需求。
迫於性能壓力裡面的另外一大類是各個運營商。各個運營商的網上營業廳，內部的DNS系統，Radius用戶認證系統，幾乎是必須配置服務器負載均衡。但是運營商使用負載均衡的地方很廣，幾個關鍵系統是由於性能壓力，其他大多數應用可能更多的是出於其他方面的考慮。
第二類，擴展要求。
這個類別有時很難和性能要求嚴格區分。最常見的是由於軟件平台或者軟件開發帶來的瓶頸而不得不考慮負載均衡。例如一個很早就使用負載均衡的企業用戶，並不是因為服務器的硬件或者帶寬的要求不滿足，而是基於軟件開發的重要的內部ERP系統的軟件性能限制，單台服務器根本無法滿足內部需求，從而不得已使用負載均衡進行擴展。
這裡典型的用戶是大型企業的內部系統，很多企業由於內部需求，必須根據自身特點制作量身定制的眾多內部應用，這些應用通常交給內部或者外包開發，著重點在於系統的功能完整性，通常對性能的考慮比較弱。在大規模使用時常常容易暴露出潛在的性能缺陷，必須通過簡易的擴展功能加以解決。運營商的部分應用其實也屬於這個范疇。
這類應用有個明顯的特點，就是仍有眾多應用使用C/S架構，使用自己的特有客戶端做TCP通訊，負載均衡部署時通常需要考慮改變客戶的網路結構，因為或者服務器需要記錄客戶源地址，或者服務器對NAT類同一地址發起的多個請求處理存在問題。
第三類，可靠性要求。
這個類別，相對來說對性能的要求比較低。例如政務網站，流量通常並不高，但是要求保持相對高可靠的在線時間。 四個9（即99.99%的可靠性）換算下來每個月故障時間<4分鐘，一年不能超過一個小時。手工或者冷備幾乎不可能達到這個標准。負載均衡，永不當機。針對這類需求，負載均衡設備已經成為一種必備的保障 SLA（服務水平協議）的手段。需要注意的是，在這類部署中，包括負載均衡本身也需要提供雙機HA熱備，和用戶連接信息備份的機制，在單台負載均衡本身由於軟硬件故障時刻，仍舊可以保證整個系統的可靠運行。
以上是簡單的使用服務器負載均衡客戶的總結，剛好也針對服務器負載均衡可以提供的三個功能， 也就是 Performance Scalability Availability,高性能，擴展性和可靠性。其實很多情況下三者互相相關，真正只因為其中一個原因才部署負載均衡的客戶並不多見。
