今年碰到兩個案例，皆是使用「網頁認證」(Captive Portal)作為無線認證的主力。
一個使用Aruba 3000系列控制器，Client數目大概到了一百多。
另一個使用Aruba 7220，總Client可到三千，使用網頁認證的大約占三成。
一旦碰上尖峰，CPU負載會達到100%並持續一段時間。
在6版OS，使用「show cpuload current」可以看見甚麼類型的程序占用CPU的百分比。
httpd是提供網頁服務，像是管理網頁與網頁認證，因此如果無線使用者使用網頁認證，就會有個USER為nobody的程序在。
Aruba控制器在架構主要是個L3 Switch，一般來說流量都會回到控制器上，而Switch的CPU負載過重會造成整個無線網路的不穩定。雖然知道httpd是造成CPU負載過重的主因，可會遇到這問題的案例，通常網頁認證已經佔有很重的部分，所以沒辦法說停就停，以求讓網路表現變得更穩定。
要解決httpd造成CPU負載過重，以下有兩個主思路：
1. 提升CPU運算能力，更新更強大運力的控制器。
2. 降低CPU的負擔，減少網頁認證使用，減少提供網頁造成的CPU負載。
在案例一，替換成7000系列的控制器就把CPU負載穩穩壓在20%以下。
在案例二，每當特定時段會出現大量使用者連線，進行網頁認證的使用者數目可超越三百，即便是7220也會造成CPU使用率飆升至紅線80%，這時候就需要走第二個思路去減少CPU負載。
相比802.1x、MAC、PSK認證，網頁認證需要進行更長的時間、傳送更長的封包，因此如果能將採取前項的無線認證方式，會能夠減少更多的CPU負載，需要鼓勵使用者使用其他方式認證的無線，或是讓網頁認證的無線更難用一點(?)。
要如何讓網頁認證更難用一些? 控制器Captive Portal設定中:
1. 提升Redirect Pause Seconds，讓等待時間久一些。通常是塞車時(CPU負載高於門檻，預設60%)才會用到，過短會造成更快reload網頁的惡性循環。
2. 降低CPU utilization threshold，塞車時會讓CPU負載比這值高一些，建議為預設值60%，如此塞車時CPU使用率會在更高一些，不建議超越90%造成網路不穩。
3. 關閉bypass-cp-landing-page，官方文件寫說關閉能降低cpu負載，開啟與關閉在於網頁轉導的方式不同，預設值為關閉。
塞車的原因是來不及消化，前兩項只是控制塞車造成的影響，並無助於提升消化網頁認證速度而避免塞車。第三點能有效幫助網頁認證造成的CPU負載。
既然網頁在控制器上會有很重的CPU負擔，那可以把控制器的角色單純一點，將網頁外置，如此可避免尖峰時段無線控制器CPU負載過重造成不穩。
在一個中大型場景，網路的穩定度越需要更精確的分工合作，一方面方便管理，另一方面也會有效率。畢竟無線控制器最重要的是管理好無線網路設備，畢竟控制器一倒的話，全部無線都會受影響，為避免電話接不完，還是讓控制器有餘韻能專一在它的專業功能上。