浏览器同域名请求的最大并发数限制

当我们在浏览网页的时候，对浏览速度有一个重要的影响因素，就是浏览器的并发数量。并发数量简单通俗的讲就是，当浏览器网页的时候同时工作的进行数量。

如果同时只有 2 个并发连接数数量，那网页打开的时候只能依赖于这 2 条线程，前面如果有打开慢的内容，就会直接影响到后面的内容打开。但是如果同时有更多的并发连接数，这样就会大大的提高网页加载速度。但是浏览器的并发连接数也并非越大越好。

HTTP 客户端一般对同一个服务器的并发连接个数都是有限制的。实际上，浏览器确实使用并行连接，但它们将并行连接的总数限制为少量（通常为四个）。服务器可以自由地关闭来自特定客户端的过多连接。

主流浏览器最大并发连接数

一些主流浏览器对 HTTP 1.1 和 HTTP 1.0 的最大并发连接数目，可以参考如下表格：

Firefox 浏览器的最大并发连接数

在 Firefox 中的地址栏输入“about：config 中”，然后搜索并修改如下两个配置项目即可：

• network.http.max-persistent-connections-per-server:6连接同一个服务器允许的最大持久连接数，默认为 6，可以不用更改。
• network.http.max-persistent-connections-per-proxy:8每个代理服务器允许的最大持久连接数,公司用户使用代理服务器，但是外面的客户一般不使用代理，火狐推荐的每台代理服务器设置为：<= 10。

Firefox3.6

和 IE8 的几乎完全一样：

• 最大并发 HTTP 连接数为 6 个（可在 about:config 中修改）。
• javascript 文件不会阻塞其他资源的加载，多个 javascript 文件可以一起加载。
• 会分析 HTML 结构，优先下载 script 和 link 标签定义的外部资源。

Firefox4 beta12

不知是因为设计理念上的不同，还是因为 beta 版未照顾到这一块，Firefox4 反而退化了，和 Firefox3.6 的区别主要体现在对资源类型的处理上，Firefox4 不再严格地优先下载 script 和 link 标签定义的外部资源，而是按照 HTML 结构中出现的顺序来进行加载。

IE 浏览器的最大并发连接数

用“注册表编辑器”命令打开注册表编辑器，找到：

[HKEY_CURRRENT_USER \ Software \ Microsoft \ Windows \ CurrentVersion \ Internet Settings]，可以看到MaxConnectionsPerServer和MaxConnectionsPer1_0Server这两个键（分别是针对 HTTP 1.1 和 HTTP 1.0 的设置）

对于 IE 9

[HKEY_CURRRENT_USER \ Software \ Policies \ Microsoft \ Internet Exploer \ Main \ FeatureControl，可以看到FEATURE_MAXCONNECTIONSPER1_0SERVER和FEATURE_MAXCONNECTIONSPERSERVER这两个键（分别是针对 HTTP 1.1 和 HTTP 1.0 的设置）

IE8

和 IE6 完全不同的瀑布图，其特点有：

• 最大并发 HTTP 连接数为 6 个。
• javascript 文件已经不会阻塞其他资源的加载，甚至多个 javascript 文件可以一起加载，并且会保证执行的顺序。
• 会分析 HTML 结构，优先下载 script 和 link 标签定义的外部资源。

chrome 浏览器的最大并发连接数

Chrome8

Chrome 自带的工具不能很清楚地表示各请求的开始时间，所以使用了 Fiddler 的瀑布图，从图上可以看出，Chrome 也是比较特立独行的一位，其特点有：

• 最大并发 HTTP 连接数为 6。
• head 部分的资源会单独下载，且阻塞 body 中的其他资源的加载。
• 会优先加载 script 和 link 标签定义的资源。

opera 浏览器的最大并发连接数

Opera11

先报怨一下，Dragonfly 不怎么好用来着……Opera 的资源加载也比较有特色，而且很难看出规律，只能大致总结一下：

• Opera 的最大并发 HTTP 连接数默认为 16，可在 opera:config - Performance - Max Connections Server 查看和修改。
• javascript 文件的加载会阻塞其他 script 和 link 标签定义的外部资源的加载，如图中的 2.js。但不会阻塞图片等其他资源的加载，如图中的 3.js。
• 会一定程度上对资源的优先级进行优化，但由于 javascript 文件要阻止后续部分资源的加载，又为了充分利用最大 HTTP 连接数，因此不能严格先加载所有的 script 和 link 标签定义的资源，导致瀑布图上各类型资源有相互穿插，难寻规律。

HTTP 连接请求与线程

HTTP 连接是复杂，有状态的对象，所以它必须被妥善管理。一个 HTTP 连接请求在同一时间只能被一个线程访问。

HttpClient 使用一个叫做的 Http 连接管理器的特殊实体类来管理的 Http 连接。Http 连接管理器在新建的 HTTP 连接时，作为工厂类；管理持久的 http 连接的生命周期；同步持久连接（确保线程安全，即一个 HTTP 连接同一时间只能被一个线程访问）。

如果一个的 Http 连接被释放或者被它的消费者明确表示要关闭，那么底层的连接就会和它的代理进行分离，并且该连接会被交还给连接管理器。这是，即使服务消费者仍然持有代理的引用，它也不能再执行 I / O 操作，或者更改的 Http 连接的状态。

连接池管理器

连接池管理器是个复杂的类，它管理着连接池，可以同时为很多线程提供 HTTP 连接请求。当请求一个新的连接时，如果连接池有有可用的持久连接，连接管理器就会使用其中的一个，而不是再创建一个新的连接。

当使用了请求连接池管理器后，HttpClient 的就可以同时执行多个线程的请求了。

连接池管理器会根据它的配置来分配请求连接。如果连接池中的所有连接都被占用了，那么后续的请求就会被阻塞，直到有连接被释放回连接池中。

线程池的原理

线程池的原理很简单，类似于操作系统中的缓冲区的概念，它的流程如下：

线程池在还没有任务到来之前，创建一定数量的线程，放入空闲队列中。这些线程都是处于睡眠状态，即均为启动，不消耗 CPU，而只是占用较小的内存空间。当客户端有一个新请求时，就会唤醒线程池中的某一个睡眠线程，让它来处理客户端的这个请求，当处理完这个请求后，线程又处于睡眠状态。

线程池能节约大量的的系统资源，使得更多的 CPU 时间和内存用来处理实际的商业应用，而不是频繁的线程创建与销毁

每个线程需要大约 1MB 内存，线程开的越多，消耗的内存也就越大。

在什么情况下使用线程池：

1. 单个任务处理的时间比较短
2. 将需处理的任务的数量大

数据库连接池

数据库连接池的解决方案是在应用程序启动时建立足够的数据库连接，并讲这些连接组成一个连接池（简单说：在一个“池”里放了好多半成品的数据库联接对象），由应用程序动态地对池中的连接进行申请，使用和释放。对于多于连接池中连接数的并发请求，应该在请求队列中排队等待。并且应用程序可以根据池中连接的使用率，动态增加或减少池中的连接数。
连接池技术尽可能多地重用了消耗内存地资源，大大节省了内存，提高了服务器地服务效率，能够支持更多的客户服务。通过使用连接池，将大大提高程序运行效率，同时，我们可以通过其自身的管理机制来监视数据库连接的数量，使用情况等。

1）最小连接数是连接池一直保持的数据库连接，所以如果应用程序对数据库连接的使用量不大，将会有大量的数据库连接资源被浪费;
2）最大连接数是连接池能申请的最大连接数，如果数据库连接请求超过此数，后面的数据库连接请求将被加入到等待队列中，这会影响之后的数据库操作。

数据库连接是一种关键的有限的昂贵的资源，这一点在多用户的网页应用程序中体现得尤为突出。一个数据库连接对象均对应一个物理数据库连接，每次操作都打开一个物理连接，使用完都关闭连接，这样造成系统的性能低下。

WebSphere Application Server 性能

http://websphere.sys-con.com/node/46514/print

构建服务器应用程序的一个过于简单的模型是：每当一个请求到达就创建一个新的服务对象，然后在新的服务对象中为服务请求，但当有大量请求并发访问时，服务器不断的创建和销毁对象的开销很大。

在面向对象的编程中，创建和销毁对象是很浪费资源的，因为创建一个对象要获取内存资源或者其它更多资源。在 Java 的中更是如此，虚拟机试图跟踪每一个对象，以便能够在对象销毁后进行垃圾回收。所以，提高程序效率的一个手段就是尽可能减少创建和销毁对象的次数。利用已有的对象来服务就是“池化资源”技术产生的原因。

HTTP 侦听器
HTTP 侦听器负责在 HTTP 服务器级别创建线程。这里发生的大多数处理是静态页面服务，或 HTTP post / GET 传递命令到后端。这是必须考虑的第一级线程配置。

Web 容器
Web 容器负责在应用程序服务器级别创建线程池。此级别的大多数处理包括 servlet，JSP，EJB，动态页面创建和后端传递处理。Web 容器是必须配置的第二级线程池配置。

ORB 容器 ORB 容器负责在对象级创建线程池。这里发生的大部分处理包括处理基于非 Web 的客户端。ORB 容器是必须配置的线程池配置的第三级。

数据源
数据源级负责创建从数据库或“传统”系统访问的连接线程。这些线程是必须解决的第四级配置

WAS 线程池数与 IHS server

假定一个浏览器的并发连接请求数为 10，通常同一时间内会有多个用户并发访问网站。又考虑到，一个 Http 连接请求在同一时间只能被一个线程访问。所以，IHS 服务器的 httpd.conf 里的 maxclients（允许建立的总线程数）要能够处理峰值时刻的浏览器连接请求才行。同时，考虑不是所有的连接请求都会到 was server，有的连接只是为了在 web 服务器上取静态资源，所以，was 上的线程池数目（Thread pools ：50 ）会远小于 IHS server 上的 maxclients 值譬如 400）。