IE和Firefox对同一域名进行请求的并发连接数限制
http://www.iefans.net/qingqiu-bingfa-lianjieshu-xianzhi/
-------------------------------------------------------------------------------------------------
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