客户端缓存是否已建立对于此处的结果有着至关重要的影响,因为对于一个DORADO的网页而言,除了能够在主页面中看到的HTML之外,还依赖于一些外部的资源文件,例如:CSS样式表、JavaScript库文件、图像文件等。这些外部文件的容量有可能大大超过主页面本身。不过幸好,这些资源文件都是支持客户端缓存的。它们只在用户第一次访问这个站点时,才会真正的被从服务端下载到客户端。在之后的使用过程中,如果这些资源文件被使用到,浏览器会在发起请求时在头信息中包含该资源的客户端缓存的描述(包括是否存在这样一个缓存和该缓存的文件时间戳)。服务器在接收到这个请求后会将客户端缓存的时间戳与服务端的相应资源进行比对,如果发现客户端的缓存已经是最新的版本了,那么服务器只会向客户端返回一个状态码(StatusCode=304),告诉客户端可以直接使用本地的缓存。
需要提醒的该缓存是与具体的页面无关,即如果有两个页面同时引入了同一个资源文件时,他们在客户端是共用同一套缓存的。而且缓存是否失效只跟资源文件的时间戳有关,网络重新连接和应用服务器的重启都不会引起客户端的缓存失效。因此,对于DORADO的应用而言,只有当用户第一次访问这个应用中的任何一个DORADO页面时才会引起CSS样式表、JavaScript库文件等资源的下载。
以DORADO为例,一个普通的DORADO页面中包含下列一些资源(由DORADO5.0 070108.1209分析后得出):
URI |
大小 |
GZIP压缩 |
说明 |
skin.css |
17.00K |
2.50K |
DORADO皮肤的CSS文件 |
preferences.js |
1.50K |
0.35K |
DORADO皮肤的配置文件 |
const.js |
3.10K |
1.10K |
DORADO自身使用的国际化资源 |
utils.js |
15.50K |
4.40K |
DORADO的核心JS库文件 |
base.js |
59.80K |
14.80K |
DORADO的核心JS库文件 |
control.js |
315.00K |
72.60K |
DORADO的核心JS库文件 |
总计 |
411.90K |
95.75K |
|
除此之外,DORADO的皮肤中还包含一些图片资源,这都是一些非常小的图片,用以显示界面上的圆角和背景。以DORADO的默认皮肤为例:其中共包含有62个图片文件,共计只有22K。
DORADO没有对图片资源启用GZIP算法,因为像GIF、JPG等文件本身已经采用了高强度的压缩格式,对这些资源启用GZIP事实上不能起到什么压缩效果,有时反而会让文件变得更大。不过,在页面的打开过程中并不是所有的图片资源都会被下载下来,大部分图片只有在真正的用到时才会下载,有些甚至是极少被用到的。例如表格的列标题中的背景,只有当用户单击将鼠标移动到列标题上时,其深色调的背景图片才有可能被下载。
对于普通的界面,假设上面有按钮,表格,多页标签等元素,在页面打开时只有下列16个图片会被使用到,共计约8K。
由上面的分析可见,当用户第一次访问DORADO的应用时,客户端除了需要下载主页面本身之外,还需要下载额外的95.75K的CSS文件和JS库文件,以及8K的图片文件。即需要额外下载不到104K(95.75K + 8K)的文件,考虑到这些文件相对比较零散,浏览器需要发出较多次的请求,这会付出一些额外的通信成本。但最终总的消耗不会超过150K。
同时,上面提到的所有这些资源都是支持客户端缓存的,包括CSS、JS库、图片等。这意味着刚才提及的150K额外消耗只会在客户机第一次访问应用时才会发生。由此可见,这些资源不会对应用在网络传输环节的性能表现产生大的影响。特别是对于应用MIS类应用而言,用户群是相对固定的,我们完全可以假设在系统日常的运行过程中绝大多数用户的系统上都已经建立好了客户端缓存。以此,评估这些可缓存资源的网络流量对与分析系统的整体性能而言意义不大。
对于一套系统而言,在日常使用过程中,真正的带宽消耗来自于那些动态内容。这包括JSP或Servlet产生的输出内容以及数据的提交。因此对于DORADO应用而言,带宽消耗来自与JSP产生的输出内容、动态数据下载/查询、数据提交操作。而这三个部分中除了数据提交是上传操作,无法使用GZIP之外,JSP和动态数据下载都启用了GZIP算法。因此绝大部分单个操作的数通信量都在15K-50K之间,极端情况下可能达到100K。