大型Web架构思想系列专题之-未雨绸缪

      首先要感谢诸多朋友对鄙人的一些拙见表示关注,不少朋友反应上一篇的分享有点意犹未尽,我的理解可能是大家觉得我写的不够快。呵呵...由于系统整理相关资料需要一段时间,另外要尽量保持原创的风格。所以周期会稍微长一点点,但我尽量会一周写1-2篇相关专题。

      上篇看到不少反馈,主要是在“瓶颈”这个问题上有些疑问。的确大型站点很容易造成瓶颈问题,但是这些问题都需要在需求分析阶段或者之前就要弄明白这些问题,至少要知道将来可能会存在哪些缺陷。不知道用-未雨绸缪这个词合不合适。如果想建一座摩天大厦,我想在暴风雨来临之前就应该把大楼都建踏实了,至少建造大楼的方案都已经研究过了。同样一个大型Web站点也需要考虑这些,如果还没有开始,那我们不妨就开始做一些数据分析研究,四个方面:数据库、网络架构、网络带宽、读写。

1、数据库
      假设我们前提是:数据库服务器操作系统采用Linux,数据库采用Oracle 11g,CPU采用至强3G x 2或x4,内存8G或16G或以上。如果从内存角度来衡量系统的最大并发连接和处理数量。抑或oracle数据库安装在一台拥有16G内存的服务器上,按照Oracle推荐的,分配给Oracle实例的内存为物理内存的80%。那么对于OLTP应用来,pga_aggregate_target(20%的空间用来进行PGA的存储)的值大约就是2621MB[(16*1024MB×80%)×20%]。这些内存将被分配与PGA区域,并且这个是和并发连接有直接关系的,每个并发的连接都需要一定量的PGA内存以执行SQL语句,假设每个用户session平均需要1M(按照通常的经验值)的空间来计算,那么从并发连接数上来讲,共可以支持近2600左右个并发连接数。另外从TPC-C基准角度方面估算数据库所能支持的并发用户数。根据TPC-C官方网站对Oracle Database 11g Standard Edition One测试结果http://www.tpc.org/tpcc/results/tpcc_result_detail.ASP?id=107091301,在硬件配置为1 CPU、4 Cores的情况下的tpmC值约为10万左右,假设被评估系统采购的数据库服务器为4 CPU,在不考虑任何其他资源消耗的情况下,那么tpmC值能够达到40万。而业界认可的一般性应用系统与TPC-C基准程序的复杂性比例为10-20:1,此处我们采用较低的10:1,另外假设系统数据库交换每60秒处理5笔业务,根据以上基础上推算出该系统所应达到的并发数为:40万tpmC/(10*60/5)=3333.3,从以上分析可以看出如果要达到Web并发5K已经成功了一小半。

2、网络架构
      常用网络架构大都在硬件防火墙存在TCP并发连接瓶颈。通常平台使用Web界面访问,访问方式采用TCP短连接方式传输数据,我们使用clearsight对与该平台业务类似的淘宝以及阿里巴巴页面的TCP连接数进行了测试,结果没个页面平均短连接数保持在30个左右。目前主流的高端企业防火墙(电信级防火墙除外)在理想情况下(防火墙不受到外界任何攻击,防火墙不开启任何附加的保护策略,只使用默认的防火墙策略)每秒TCP连接数可达30000并发,如果TCP连接在1秒内建立完成,则一个分布式处理中心大约可以承受30000/30=1000个TCP并发。这一点不是非常满意,这样一来在分布式处理中心还要做些文章。

3、网络带宽
      对于网络带宽,假设系统有1000个并发用户数,网络是100Mbps,则有效带宽为12.5MBytes,每页面的平均大小按照100KB计算,那么不管服务器本身速度多快,最好的响应时间为:2000User*200KB/(12.5MBytes*1024) = 31.25秒,即:如果网络是100Mbps的话,最好的页面访问执行时间也就是31.25秒。这样无论服务器的响应有多快,总是要在网络上传输这么大的数据量。因此,网络将是一个很大的瓶颈。如果网络是125MBytes即约1Gbps,则响应时间是3.125秒,所以并发飙升,带宽费用将是一笔巨大的开支。

4、读写
      假设最大的读写在图片服务器,且配置如下:1、CPU:至强3G x 2,或同级别的其他CPU;2、内存:2G或以上;3、硬盘:300G x 2做RAID 0或146G x 4做RAID 1+0。就普通的服务器而言,其使用的SCSI硬盘的理论最大传输速度是320M/S,实际可能只有一半。按照系统需求中一般的页面的响应时间应在5秒内(局域网内为3秒内,互联网上一般应该在5秒内)的要求计算图片总流量为800M(按照实际值计算)。如果按照每个页面上的图片的平均大小为100K来计算,普通配置图片服务器可以承受8000用户的流量。

      有了这些数据我们在做系统架构的时候就知道如果规避种种问题,当然在架构阶段尽可能的为升级留有余地。我喜欢在建楼之前画尽可能多的图纸,做尽可能多的实验。不管怎样我们都热爱这份Web大楼的建造,有的三两层,有的几十层甚至上百层。高度说明不了问题,关键在于你的心是否容的下这所建筑!

it知识库大型Web架构思想系列专题之-未雨绸缪,转载需保留来源!

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。