⑴ 誰有好點的有關網站負載均衡方面的資料啊
win2008 網路負載平衡可以增強網路伺服器（WEB,FTP,VPN,Proxy）等應用的高可
用性及伸縮性，NLB服務會根據每台主機的負載權重動態分配應用請求，一個群集
中最多支持32台計算機，支持在不關閉群集的情況下添加或刪除主機，使用埠
規則可以對WEB服務提供負載平衡的優化。單主機規則可以將制定請求引導特定主
機，可以使用SHELL命令或腳本對NLB操作進行管理，可以根據WINDOWS日誌對NLB
⑵ 性能測試有那些免費工具
Grinder：Grinder是一個開源的JVM負載測試框架，它通過很多負載注射器來為分布式測試提供了便利。支持用於執行測試腳本的Jython腳本引擎HTTP測試可通過HTTP代理進行管理。根據項目網站的說法，Grinder的主要目標用戶是「理解他們所測代碼的人——Grinder不僅僅是帶有一組相關響應時間的『黑盒』測試。由於測試過程可以進行編碼——而不是簡單地腳本化，所以程序員能測試應用中內部的各個層次，而不僅僅是通過用戶界面測試響應時間。
Pylot：Pylot是一款開源的測試Webservice性能和擴展性的工具，它運行HTTP負載測試，這對容量計劃，確定基準點，分析以及系統調優都很有用處。Pylot產生並發負載(HTTPRequests)，檢驗伺服器響應，以及產生帶有metrics的報表。通過GUI或者shell/console來執行和監視testsuites。
Web Capacity Analysis Tool(WCAT)：這是一種輕量級負載生成實用工具，不僅能夠重現對Web伺服器(或負載平衡伺服器場)的腳本HTTP請求，同時還可以收集性能統計數據供日後分析之用。WCAT是多線程應用程序，並且支持從單個源控制多個負載測試客戶端，因此您可以模擬數千個並發用戶。該實用工具利用您的舊機器作為測試客戶端，其中每個測試客戶端又可以產生多個虛擬客戶端(最大數量取決於客戶端機器的網路適配器和其他硬體)。
fwptt：fwptt也是一個用來進行Web應用負載測試的工具。它可以記錄一般的請求，也可以記錄Ajax請求。它可以用來測試ASP.NET，JSP，PHP或是其它的Web應用。
JCrawler：JCrawler是一個開源(CPL)的Web應用壓力測試工具。通過其名字，你就可以知道這是一個用Java寫的像網頁爬蟲一樣的工具。只要你給其幾個URL，它就可以開始爬過去了，它用一種特殊的方式來產生你Web應用的負載。這個工具可以用來測試搜索引擎對你站點產生的負載。當然，其還有另一功能，你可以建立你的網站地圖和再點擊一下，將自動提交Sitemap給前5名的搜索引擎!
⑶ 如何理解Linux下的負載均衡
一、目前網站架構一般分成負載均衡層、web層和資料庫層，我其實一般還會多加一層，即文件伺服器層，因為現在隨著網站的PV越來越多，文件伺服器的壓力也越來越大；不過隨著moosefs、DRDB+Heartbeat的日趨成熟，這問題也不大了。網站最前端的負載均衡層稱之為Director,它起的是分攤請求的作用，最常見的就是輪詢。
二、F5是通過硬體的方式來實現負載均衡，它較多應用於CDN系統，用於squid反向加速集群的負載均衡，是專業的硬體負載均衡設備，尤其適用於每秒新建連接數和並發連接數要求高的場景；LVS和Nginx是通過軟體的方式來實現的，但穩定性也相當強悍，在處理高並發的情況也有相當不俗的表現。
三、Nginx對網路的依賴較小，理論上只要ping得通，網頁訪問正常，nginx就能連得通，nginx同時還能區分內外網，如果是同時擁有內外網的節點，就相當於單機擁有了備份線路；lvs就比較依賴於網路環境，目前來看伺服器在同一網段內並且lvs使用direct方式分流，效果較能得到保證。
四、目前較成熟的負載均衡高可用技術有LVS+Keepalived、Nginx+Keepalived,以前Nginx沒有成熟的雙機備份方案，但通過shell腳本監控是可以實現的，有興趣的可具體參考我在51cto上的項目實施方案；另外，如果考慮Nginx的負載均衡高可用，也可以通過DNS輪詢的方式來實現，有興趣的可以參考張宴的相關文章。
五、集群是指負載均衡後面的web集群或tomcat集群等，但現在的集群意義泛指了整個系統架構，它包括了負載均衡器以及後端的應用伺服器集群等，現在許多人都喜歡把Linux集群指為LVS,但我覺得嚴格意義上應該區分開。
六、負載均衡高可用中的高可用指的是實現負載均衡器的HA,即一台負載均衡器壞掉後另一台可以在<1s秒內切換，最常用的軟體就是Keepalived和Heatbeat,成熟的生產環境下的負載均衡器方案有Lvs+Keepalived、Nginx+Keepalived.
七、LVS的優勢非常多：①抗負載能力強；②工作穩定（因為有成熟的HA方案）；③無流量；④基本上能支持所有的應用，基於以上的優點，LVS擁有不少的粉絲；但世事無絕對，LVS對網路的依賴性太大了，在網路環境相對復雜的應用場景中，我不得不放棄它而選用Nginx.
八、Nginx對網路的依賴性小，而且它的正則強大而靈活，強悍的特點吸引了不少人，而且配置也是相當的方便和簡約，小中型項目實施中我基本是考慮它的；當然，如果資金充足，F5是不二的選擇。
九、大型網站架構中其實可以結合使用F5、LVS或Nginx,選擇它們中的二種或三種全部選擇；如果因為預算的原因不選擇F5,那麼網站最前端的指向應該是LVS,也就是DNS的指向應為lvs均衡器，lvs的優點令它非常適合做這個任務。重要的ip地址，最好交由lvs託管，比如資料庫的ip、webservice伺服器的ip等等，這些ip地址隨著時間推移，使用面會越來越大，如果更換ip則故障會接踵而至。所以將這些重要ip交給lvs託管是最為穩妥的。
十、VIP地址是Keepalived虛擬的一個IP,它是一個對外的公開IP,也是DNS指向的IP;所以在設計網站架構時，你必須向你的IDC多申請一個對外IP。
十一、在實際項目實施過程中發現，Lvs和Nginx對https的支持都非常好，尤其是LVS,相對而言處理起來更為簡便。
十二、在LVS+Keepalived及Nginx+Keepalived的故障處理中，這二者都是很方便的；如果發生了系統故障或伺服器相關故障，即可將DNS指向由它們後端的某台真實web,達到短期處理故障的效果，畢竟廣告網站和電子商務網站的PV就是金錢，這也是為什麼要將負載均衡高可用設計於此的原因；大型的廣告網站我就建議直接上CDN系統了。
十三、現在Linux集群都被大家神話了，其實這個也沒多少復雜；關鍵看你的應用場景，哪種適用就選用哪種，Nginx和LVS、F5都不是神話，哪種方便哪種適用就選用哪種。
十四、另外關於session共享的問題，這也是一個老生長談的問題了；Nginx可以用ip_hash機制來解決session的問題，而F5和LVS都有會話保持機制來解決這個問題，此外，還可以將session寫進資料庫，這也是一個解決session共享的好辦法，當然這個也會加重資料庫的負擔，這個看系統架構師的取捨了。
十五、我現在目前維護的電子商務網站並發大約是1000左右，以前的證券資訊類網站是100左右，大型網上廣告大約是3000,我感覺web層的並發越來越不是一個問題；現在由於伺服器的強悍，再加上Nginx作web的高抗並發性，web層的並發並不是什麼大問題；相反而言，文件伺服器層和資料庫層的壓力是越來越大了，單NFS不可能勝任目前的工作，現在好的方案是moosefs和DRDB+Heartbeat+NFS;而我喜歡的Mysql伺服器，成熟的應用方案還是主從，如果壓力過大，我不得不選擇oracle的RAC雙機方案。
十六、現在受張宴的影響，大家都去玩Nginx了（尤其是作web），其實在伺服器性能優異，內存足夠的情況下，Apache的抗並發能力並不弱，整個網站的瓶頸應該還是在資料庫方面；我建議可以雙方面了解Apache和Nginx,前端用Nginx作負載均衡，後端用Apache作web,效果也是相當的好。
十七、Heartbeat的腦裂問題沒有想像中那麼嚴重，在線上環境可以考慮使用；DRDB+Heartbeat算是成熟的應用了，建議掌握。我在相當多的場合用此組合來替代EMC共享存儲，畢竟30萬的價格並不是每個客戶都願意接受的。
十八、無論設計的方案是多麼的成熟，還是建議要配置Nagios監控機來實時監控我們的伺服器情況；郵件和簡訊報警都可以開啟，畢竟手機可以隨身攜帶嘛；有條件的還可以購買專門的商業掃描網站服務，它會每隔一分鍾掃描你的網站，如果發現沒有alive會向你的郵件發警告信息或直接電話聯系。
十九、至少網站的安全性問題，我建議用硬體防火牆，比較推薦的是華賽三層防火牆+天泰web防火牆，DDOS的安全防護一定要到位；Linux伺服器本身的iptables和SElinux均可關閉，當然，埠開放越少越好。
⑷ 硬體負載均衡支持oracle資料庫嗎
oracle的高可用與負載均衡
瀏覽了一下Oracle官方的網頁以及非官方的ppt，簡單了解了一下Oracle提供的高可用方案。
1. RAC
RAC, Real Application Clusters
多個Oracle伺服器組成一個共享的Cache，而這些Oracle伺服器共享一個基於網路的存儲。這個系統可以容忍單機/或是多機失敗。
不過系統內部的多個節點需要高速網路互連，基本上也就是要全部東西放在在一個機房內，或者說一個數據中心內。如果機房出故障，比如網路不通，那就壞了。所以僅僅用RAC還是滿足不了一般互聯網公司的重要業務的需要，重要業務需要多機房來容忍單個機房的事故。
2. Data Guard.
Data Guard這個方案就適合多機房的。某機房一個proction的資料庫，另外其他機房部署standby的資料庫。Standby資料庫分物理的和邏輯的。物理的standby資料庫主要用於proction失敗後做切換。而邏輯的standby資料庫則在平時可以分擔proction資料庫的讀負載。
3. MAA
MAA(Maximum Availability Architecture)其實不是獨立的第三種，而是前面兩種的結合，來提供最高的可用性。每個機房內部署RAC集群，多個機房間用Data Guard同步。
Oracle+Fusionio+Dataguard的高可用方案
傳統的Oracle的高可用方案必須基於共享存儲設備，不管是雙機主備模式，還是Oracle RAC，資料庫必須放在共享的SAN存儲上，通過HA或集群軟體實現高可用。Oracle DataGuard是很好的容災軟體，但是作為HA解決方案，功能有很多局限性，比如數據丟失，應用透明切換，只能讀無法寫(11g)等等，目前都沒有非常好的解決方案。
自從固態存儲技術出現後，單機的IO能力大幅度提升，比如採用PCIE介面的fusionio卡，單塊卡就可以提供數萬IOPS的能力，單機的IO能力已經超過了傳統的磁碟存儲。但是，一直困擾我們的是，如何解決無共享存儲環境下Oracle資料庫的高可用問題？我們團隊設計了一種架構，提供簡單可靠的高可用功能。
雖然在Oracle的立場上，總是建議客戶能夠更好地規劃自己的應用，在有其它負載平衡方法的時候，盡量不要依賴於Oracle的Load Balance方法，但是往往在給客戶配置完Oracle RAC資料庫以後，客戶都會要求要測試負載平衡（Load Balance）和TAF（Transparent Application Failover），並且將這兩個測試作為RAC是否安裝成功的標准。
這是一件很無奈的事情，像把旁枝末節看作了主要功能，甚至有些買櫝還珠的感覺，但是畢竟這是客戶，更了解Oracle Load Balance（後文用LB表示），才可以更好滿足客戶需求。
RAC的負載均衡主要是指新會話連接到RAC資料庫時，如何判定這個新的連接要連到哪個節點進行工作。在RAC中，負載均衡分為兩種，一種是基於客戶端連接的，另外一種是基於伺服器端的。客戶端的負載均衡配置相對簡單，只需要在tnsnames.ora中添加LOAD_BALANCE=ON這么一個選項即可。
實現負載均衡(Load Balance)是Oracle RAC最重要的特性之一，主要是把負載平均分配到集群中的各個節點，以提高系統的整體吞吐能力。
通常情況下有兩種方式來實現負載均衡
一個是基於客戶端連接的負載均衡
客戶端的負載均衡主要是通過為tnsnames.ora增加load_balance=yes條目來實現
如果未開啟load_balance=yes時，Oracle Net會根據地址列表按順序來選擇一個進行連接，直到連接成功為止。 如果第一個host主機連接失敗，在有多個地址的情形下，接下來選擇第二個地址連接，依此類推，直到連接成功為止。當開啟了load_balance=yes時，則Oracle Net會從多個地址中隨機地選擇一個地址進行連接，直到連接成功為止。注意，此連接方式僅根據地址列表隨機選擇，並不考慮到各個實例上當前真正連接數量的多少，也即是沒有考慮各個節點真實的連接負載情況
二是基於伺服器端監聽器(Listener)收集到的信息來將新的連接請求分配到連接數較少實例上的實現方式。
Oracle RAC伺服器端的負載均衡是根據RAC中各節點的連接負荷數情況，將新的連接請求分配到負荷最小的節點上去。當資料庫處於運行時，RAC中各節點的PMON進程每3秒會將各自節點的連接負荷數更新到service_register。而對於節點中任意監聽器故障或監聽器意外失敗時，PMON進程會每1秒鍾檢查當前節點上的監聽是否重啟，以獲得最新的負載信息來及時調整負載均衡。
跨機房問題
跨機房問題一直都是一個老大難的問題，先看傳統資料庫的跨機房方案。
Master/Slave方案
這是最常用的方案，適用於大多數需求。Master將操作日誌實時地發送到Slave，Slave當成Master的一個Hot Backup。Master宕機時，服務切換到Slave，需要修改客戶端邏輯使得Master失效時自動尋找新的Master。
這個方案有一個問題就是資料庫的Master和Slave一般不是強同步的，所以，切換到Slave後可能丟失宕機前的少量更新。如果將 Master和Slave做成強同步的，即：所有的數據必須同時寫成功Master和Slave才成功返回客戶端，這樣又帶來了另外一個問 題：Master和Slave中任何一台機器宕機都不允許寫服務，可用性太差。因此，Oracle有一種折衷的模式：正常情況下Master和Slave 是強同步的，當Master檢測到Slave故障，比如Slave宕機或者Master與Slave之間網路不通時，Master本地寫成功就返回客戶 端。採用這種折衷的同步模式後，一般情況下Master和Slave之間是強同步的，Master宕機後切換到Slave是安全的。當然，為了確保數據安 全後，宕機的Master重啟後可以和新的Master(原有的Slave)對比最後更新的操作日誌，如果發現不一致可以提醒DBA手工介入，執行數據訂 正過程。
Master和Slave之間強同步還有一個問題就是跨機房延時，對於關鍵業務，同城的機房可以部署專用光纖，在硬體層面上解決這個問題；異地的機房一般用來做備份，與主機房之間的數據同步一般是非同步的，可能有秒級延時。
機房宕機切換自動化成本太高，但是對於很多單點服務，機房內部宕機切換的自動化很有必要。Oceanbase採用Linux的一個開源方 案：Pacemaker，通過heartbeat和虛IP漂移的方式實現機房內部宕機自動切換。由於主備切換本質上是一個選主問題，理論上只有Paxos 或者類似協議可以解決，而Pacemaker沒有採用復雜的Paxos協議，它對硬體是有依賴的，比如要求主備節點之間通過直連線保證網路不會發生故障， 而這在機房內部是可以做到的。機房之間採用前面提到的Master/Slave方案，可以寫一個腳本ping主機房的Master，當確認主機房 Master宕機時(比如一分鍾不通)將服務切換到備機房並報警。
⑸ 高通big負載平衡怎麼調高通驍龍高通驍龍處理器排名
a17+a7big.little架構的32位八核的soc 這不就是MT6595么，說的這么麻煩干什麼，讓人一頭霧水，，，驍龍801跟MT6595應該說總體水平半斤八兩吧，CPU架構，一個krait400，一個是A17，理論的同頻單核性能都稍稍弱於A15，差不太多，主頻也都在2G左右，我感覺CPU基本打平，可能A17的U會比krait400占點便宜。GPU嘛肯定是801的adreno330強了，不過G6200也不算差。工藝都是28nm製程，功耗也差不太多。總體還是在同一水平吧