-------------------------------------------------------------------------------------------------
1， HTTP客戶端一般對同一個服務器的並發連接個數都是有限制的。
In practice, browsers do use parallel connections, but they limit the total number of parallel connections to a small number (often four). Servers are free to close excessive connections from a particular client.
2， 一些主流瀏覽器對 HTTP 1.1 和 HTTP 1.0 的最大並發連接數目，可以參考如下表格：
| Browser |
HTTP/1.1 |
HTTP/1.0 |
| IE 11 |
6 |
6 |
| IE 10 |
6 |
6 |
| IE 9 |
10 |
10 |
| IE 8 |
6 |
6 |
| IE 6,7 |
2 |
4 |
| Firefox |
6 |
6 |
| Safari 3,4 |
4 |
4 |
| Chrome 4+ |
6 |
6 |
| Opera 9.63,10.00alpha |
4 |
4 |
| Opera 10.51+ |
8 |
? |
| iPhone 2 |
4 |
? |
| iPhone 3 |
6 |
? |
| iPhone 4 |
4 |
? |
| iPhone 5 |
6 |
? |
| Android2-4 |
4 |
? |
3， Firefox瀏覽器的最大並發連接數
在Firefox的地址欄輸入“about:config”，然后搜索並修改如下兩個配置項目即可：
network.http.max-persistent-connections-per-server
network.http.max-persistent-connections-per-proxy
network. http. max-connections:設置Http同時連接的最大數量
network.http.max-persistent-connections-per-server是連接同一個服務器允許的最大持久連接數，默認為6，可以不用更改。
network.http.max-persistent-connections-per-proxy每個代理服務器允許的最大持久連接數
公司用戶使用代理服務器，但是外面的客戶一般不使用代理,Firefox的Wiki推薦的network.http.max-persistent-connections-per-server設置為：<=10。
4，IE瀏覽器的最大並發連接數
用“regedit”命令打開注冊表編輯器，找到：
[HKEY_CURRRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]，可以看到MaxConnectionsPerServer和MaxConnectionsPer1_0Server
這兩個鍵（分別是針對HTTP 1.1 和 HTTP 1.0的設置）
For IE 9
[HKEY_CURRRENT_USER\Software\Policies\Microsoft\Internet Exploer\Main\FeatureControl，可以看到FEATURE_MAXCONNECTIONSPER1_0SERVER和FEATURE_MAXCONNECTIONSPERSERVER
這兩個鍵（分別是針對HTTP 1.1 和 HTTP 1.0的設置）
****************************************************************************
5， 假定一個瀏覽器的並發連接請求數為10，通常同一時間內會有多個用戶並發訪問網站。又考慮到，一個Http連接請求在同一時間只能被一個線程訪問。
所以，IHS server的 httpd.conf里的maxclients（允許建立的總線程數）要能夠處理峰值時刻的瀏覽器連接請求才行。
同時，考慮不是所有的連接請求都會到was server，有的連接只是為了在web server上取靜態資源，所以，was 上的線程池數目（Thread pools：50）會遠小於IHS server上的maxclients值（譬如400）。
*******************************************************************************
6，HTTP 連接請求與線程
Http連接是復雜，有狀態的對象，所以它必須被妥善管理。一個Http連接請求在同一時間只能被一個線程訪問。
HttpClient使用一個叫做Http連接管理器的特殊實體類來管理Http連接。Http連接管理器在新建http連接時，作為工廠類;管理持久http連接的生命周期;同步持久連接（確保線程安全，即一個http連接同一時間只能被一個線程訪問）。
如果一個Http連接被釋放或者被它的消費者明確表示要關閉，那么底層的連接就會和它的代理進行分離，並且該連接會被交還給連接管理器。這是，即使服務消費者仍然持有代理的引用，它也不能再執行I/O操作，或者更改Http連接的狀態。
7，連接池管理器
連接池管理器是個復雜的類，它管理着連接池，可以同時為很多線程提供http連接請求。當請求一個新的連接時，如果連接池有有可用的持久連接，連接管理器就會使用其中的一個，而不是再創建一個新的連接。
當使用了請求連接池管理器后，HttpClient就可以同時執行多個線程的請求了。
連接池管理器會根據它的配置來分配請求連接。如果連接池中的所有連接都被占用了，那么后續的請求就會被阻塞，直到有連接被釋放回連接池中。
8，線程池的原理:
線程池的原理很簡單，類似於操作系統中的緩沖區的概念，它的流程如下：
線程池在還沒有任務到來之前，創建一定數量的線程，放入空閑隊列中。這些線程都是處於睡眠狀態，即均為啟動，不消耗CPU，而只是占用較小的內存空間。當客戶端有一個新請求時，就會喚醒線程池中的某一個睡眠線程，讓它來處理客戶端的這個請求，當處理完這個請求后，線程又處於睡眠狀態。
線程池能節約大量的的系統資源，使得更多的CPU時間和內存用來處理實際的商業應用，而不是頻繁的線程創建與銷毀
每個線程需要大約1MB內存，線程開的越多，消耗的內存也就越大。
在什么情況下使用線程池：
1.單個任務處理的時間比較短
2.將需處理的任務的數量大
9，數據庫連接池:
數據庫連接池的解決方案是在應用程序啟動時建立足夠的數據庫連接，並講這些連接組成一個連接池(簡單說：在一個“池”里放了好多半成品的數據庫聯接對象)，由應用程序動態地對池中的連接進行申請、使用和釋放。對於多於連接池中連接數的並發請求，應該在請求隊列中排隊等待。並且應用程序可以根據池中連接的使用率，動態增加或減少池中的連接數。
連接池技術盡可能多地重用了消耗內存地資源，大大節省了內存，提高了服務器地服務效率，能夠支持更多的客戶服務。通過使用連接池，將大大提高程序運行效率，同時，我們可以通過其自身的管理機制來監視數據庫連接的數量、使用情況等。
1) 最小連接數是連接池一直保持的數據庫連接，所以如果應用程序對數據庫連接的使用量不大，將會有大量的數據庫連接資源被浪費；
2) 最大連接數是連接池能申請的最大連接數，如果數據庫連接請求超過此數，后面的數據庫連接請求將被加入到等待隊列中，這會影響之后的數據庫操作。
數據庫連接是一種關鍵的有限的昂貴的資源，這一點在多用戶的網頁應用程序中體現得尤為突出。一個數據庫連接對象均對應一個物理數據庫連接，每次操作都打開一個物理連接，使用完都關閉連接，這樣造成系統的 性能低下。
10，WebSphere Application Server Performance
http://websphere.sys-con.com/node/46514/print
構建服務器應用程序的一個過於簡單的模型是：每當一個請求到達就創建一個新的服務對象，然后在新的服務對象中為請求服務。但當有大量請求並發訪問時，服務器不斷的創建和銷毀對象的開銷很大。
在面向對象的編程中，創建和銷毀對象是很浪費資源的，因為創建一個對象要獲取內存資源或者其它更多資源。在Java中更是如此，虛擬機試圖跟蹤每一個對象，以便能夠在對象銷毀后進行垃圾回收。所以，提高程序效率的一個手段就是盡可能減少創建和銷毀對象的次數。利用已有的對象來服務就是“池化資源”技術產生的原因。
Figure 1 displays an application request flow that requires back-end processing and illustrates the relationship among the thread pools as the user request is processed.
HTTP Listener
The HTTP Listener is responsible for thread creation at the HTTP server level. Most of the processing that occurs here is static page serving, or HTTP post/GET pass commands to the back end. This is the first level of thread configuration that must be considered.
Web Container
The Web container is responsible for thread pool creation at the application server level. Most of the processing at this level includes servlet, JSP, EJB, dynamic page creation, and back-end pass-through processing. The Web container is the second level of thread pool configuration that must be configured.
ORB Container The ORB container is responsible for thread pool creation at the object level. Most of the processing that occurs here includes the processing of non-Web?based clients. The ORB container is the third level of the thread pool configuration that must be configured.
Data Source
The data source level is responsible for creating the connection threads that are accessed from the database or "legacy" systems. These threads are the fourth level of configuration that must be addressed