开发者社区> 泡泡浅眠> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

小网站架构优化:从100并发抗到4000并发

简介:
+关注继续查看
前言:
复制代码
很久前,在512M内存+Access的VPS里,写过了一个经典的秋色园技术原理解析系列。
后来的某一天,换上了1G内存+MSSQL2000,秋色园又跑过了一个多年头。
之后,秋色园和 CYQ.Data,也在一直默默的优化和改进,只是没写什么文章分享分享。
秋色园的架构,基本上从简单到复杂最后又回归简单,不断做着减法,去掉了好多以前用于减轻负载的算法,包括AOP+SQLite分压和文本分压等机制,还有一些缓存式算法。
好多时候,硬件不给力,这时候就会被逼着把整个系统架构复杂化。
一当硬件给力时,系统轻装上阵,架构可以更简单。
因为本质就是请求+返回(硬件能加速的,软件就不用搞太多算法了)。
复制代码
 

下面在分享一下我记忆中还记得的秋色园关于负载测试的起缘:

 

1:某天,我发现秋色园CPU经常会跑满100%:
经过一年的岁月,不知觉的最终被我发现是搜索引擎引发的(虽然写过IIS日志分析工具,但是我自己都很少用,几乎没怎么用,一用没想到找到问题了)。

我发现秋色园的关键字(Tag),由于是直接链接到搜索,而搜索这块是全表的like搜索,没做缓存的优化,所以搜索引擎心情好时就把它弄挂菜了。
 

2:某天,某人用几百个并发,把秋色园又搞到CPU百分百了:

复制代码
我很疑惑,秋色园几乎都是半静态+缓存,除了队列缓存式更新访问计数,和除了后台,不可能顶这点并发就挂了。

通过查看IIS日志,我从日志里发现,是由于URL引发的:
由于秋色园是根据URL缓存的,对方的并发通过在URL后面补充一些随机参数,导致每次请求的URL都不一样,结果系统每次会重新读取并生成Html,导致CPU飘起来。
解决方法就是重整所有的URL链接和对应的缓存机制了。
复制代码
 

3:某天,我也玩起了负载工具,自己时不时的把秋色园弄到CPU百分百.

 

下面分享下,在负载推力下,对秋色园后续折腾的几个优化方案:

 

经过不断的负载测试,秋色园顺路把一些常见的优化手段也用上了:

 

1:分离静态资源域名:static.cyqdata.com
复制代码
架构处理过程:

1:把模板加载和图片处理的,都给处理到另一个域名。
2:新开一个网站,绑定static.cyqdata.com域名,位置仍指向原来的位置。
3:由于是静态站点,可以关掉和.net无关的所有东西。
这样变化后,图片的负载就是天与地的变化:
如果没有分离出来,仍经过.net解析后再返回图片,测试1-2千个并发CPU就近满了。
经过分离,关掉和.net相关的资源后,跑了5000以上并发,CPU和内存也没怎么动静。
主要自己三台机最多只上到这5K左右的并发数,不能往上再测试,但是差距已经很明显了。
复制代码
 

2:Http 304:这是客户端缓存的应用:

除了服务器缓存,客户端缓存也是另一个重点,除了一些静态数据处理缓存,动态数据也适时用上304。
 

如:秋色园上有一些动态的文件“下载次数”:

一般的程序,文件下载都是和文章内容分开的,单独提供下载。

如上,我需要在文章内容里提供下载,又要考虑下载次数机制,用上了图片机制,通过动态一个请求返回了图片资源。
由于下次数次实时性不强,而且变化少,通过来点手段,也可以304缓存。
 

3:关掉不常用的Modules:

如果你重写过URL,或看过秋色园技术原理解析关于URL重写这块文章,下面代码应该会熟悉:

通过调试,看下图:秋色园的Modules只剩下3个,那时因为其它的没用的都关掉了。
本来Session模块也是要关掉,突然发现OAuth2里用到了,就保留了。
看下图还会发现一段注释的for语句,是打印出默认系统带的十几个Moudules。
关掉也很简单,web.config配置:
复制代码
    <httpModules>
      <add name="UrlRewrite" type="Web.UrlRewrite.UrlRewrite,Web.UrlRewrite" />
      <remove name="OutputCache" />
      <!--<remove name="Session"/>-->
      <remove name="WindowsAuthentication" />
      <remove name="FormsAuthentication" />
      <remove name="PassportAuthentication" />
      <remove name="RoleManager" />
      <remove name="UrlAuthorization" />
      <remove name="FileAuthorization" />
      <remove name="AnonymousIdentification" />
      <remove name="Profile" />
      <remove name="ErrorHandlerModule" />
      <remove name="ServiceModel" />
      <!--<remove name="UrlRewrite"/>-->
      <!--<remove name="DefaultAuthentication"/>-->
    </httpModules>
复制代码
 

4:尽早关闭数据库链接:

以前喜欢这样写代码:
复制代码
using (MAction action = new MAction(U_QBlogFileEnum.Blog_File))
            {
                action.SetSelectColumns(Files.ID, Files.Hits, Files.FilePath);
                if (action.Fill(id))
                {
                   Document.Load(action.Data);
                   。。获取数据库数据处理一些业务逻辑显示到界面。 
                }
            }
复制代码
这种坏习惯,导致数据库链接会根据业务的时间延长了关闭链接,导致并发性能下降,平时看不出来。
改进:
复制代码
MDataRow row;
using (MAction action = new MAction(U_QBlogFileEnum.Blog_File))
            {
                action.SetSelectColumns(Files.ID, Files.Hits, Files.FilePath);
                if (action.Fill(id))
                {
                   row=action.Data;
                }
            }
if(row!=null)
{
Document.Load(action.Data);
。。获取数据库数据处理一些业务逻辑显示到界面。
}
复制代码
把逻辑放到外面,提前关闭链接后再去处理事情,并发时性能会提升不少。

 

5:Web园的抗并发能力:
复制代码
基于不断的优化改进,秋色园从100个并发挂菜-》基本优化-》到1000个并发挂菜-》经过架构调整优化-》抗到2000个并发左右。

最后,还有一个招,就是IIS的Web园,通过允许的设置了2个进程,发现能抗到4000并发,虽然CPU接近100%,但仍能正常访问,可见Web园的确是个奇招。
开启Web园,意味着多进程负载,当然Session默认的模式就不能用了。
复制代码
如上所说,同样的硬件配置:从100个并发,到4000个并发,改动并不多,路也并不长,但是常人又知多少。
以上的服务器环境,都是美国VPS 10M带宽CPU双核,配置如下:
 

6:如何对网站进行负载测试:

分布式网站负载压力测试工具:点击下载
 

后话:

硬件能顶半边天:一台好的服务器,程序写的烂一点,不做任何优化,也能跑的潇潇洒洒。

软件能顶半边天:好的优化机制和架构,穷的服务器也能跑个安安稳稳。
现实时,只有超过了那半边天,你才会去想另一半的重要性。
版权声明:本文原创发表于博客园,作者为路过秋天,原文链接:
http://www.cnblogs.com/cyq1162/archive/2013/05/13/3074980.html

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
并发基础
1: 并发的简短历史
1219 0
并发不是并行,它更好!
“并发”指的是程序的结构,“并行”指的是程序运行时的状态
2098 0
高并发场景下如何优化服务器的性能?
最近,有小伙伴在群里提问:Linux系统怎么设置tcp_nodelay参数?也有小伙伴说问我。那今天,我们就来根据这个问题来聊聊在高并发场景下如何优化服务器的性能这个话题。
0 0
《性能优化》并发与并行
性能优化系列第一篇主要给大家科普了一些性能相关的数字,为大家建立性能的初步概念。第二篇给大家介绍了支撑淘宝双十一这种达到百万QPS项目所需的相关核心技术。 本文带来的是性能优化中的第一利器:并发与并行。
0 0
C++高并发场景下读多写少的优化方案
C++高并发场景下读多写少的优化方案 述 一谈到高并发的优化方案,往往能想到模块水平拆分、数据库读写分离、分库分表,加缓存、加mq等,这些都是从系统架构上解决。单模块作为系统的组成单元,其性能好坏也能很大的影响整体性能,本文从单模块下读多写少的场景出发,探讨其解决方案,以其更好的实现高并发。 不同的业务场景,读和写的频率各有侧重,有两种常见的业务场景: 读多写少:典型场景如广告检索端、白名单更新维护、loadbalancer 读少写多:典型场景如qps统计 本文针对读多写少(也称一写多读)场景下遇到的问题进行分析,并探讨一种合适的解决方案。
0 0
高并发处理方案
时常看到高并发的问题,但高并发其实是最不需要考虑的东西。为何,他虚无缥缈,很少有网站真的需要这些东西,而且其中很多技术,其实你已经在用了。有这个意识就够了,不需要时刻盯着这个问题。只有很少的网站真的能达到高并发。
1286 0
前端优化之高并发处理
大部分的高并发处理基本都是在后端处理,但是在部分特殊情况下,后端无法阻止用户行为,需要前端做配合。例如在抢购、秒杀等场景。
0 0
+关注
文章
问答
文章排行榜
最热
最新
相关电子书
更多
分布式高并发缓存6.0
立即下载
Web服务架构变化及性能优化
立即下载
Cassandra 性能压测及调优实战
立即下载