|
网站加速：不是太少，而是太多
--------------------------------------------------------------------------------
作者:ViktorYu 来自:CSDN 时间:2003-12-27
标题：新手笔记-网站加速：不是太少，而是太多
关键词：网站开发、网站加速方案、合理选型
8月30号： 回忆进行网站加速步骤，真是百感交集！
很长时间没有写笔记了，网站的工作的确是非常琐碎。不过真的要做好实在是很难，下面这个笔记断断续续写了两个月，很多想法又都发生了变化，所以写的很乱，请大家对付看吧：）
网站的技术工作其实涉及的面非常广。从网站信息发布的运行平台的选择到采编入库的设计与开发，都需要进行很多的调研与方案定制。综合的进行不是简单的几篇笔记就可以完成的。这次先对加速的方案进行简单的说明。目前所处的网站采用零零总总的加速方式有很多，下面是对这些加速方式的简单说明。
解决网站的压力问题，是所有商业化的网站都要考虑的事情，从对访问量的预期，以及不同时段压力的不同，都要进行综合的考虑。硬件是最重要考虑的方面。软件同样也非常重要。定义的框架是否合适，物理上的数据库是否将读写进行分离，这些都是在网站的设计阶段要考虑的部分。但遗憾的是，最初网站的设计者并没有将这样都考虑进行，而是将问题留到的上线之后再进行调整，这就导致了上线之后的很大压力。在我们的新版网站刚上线的时候，访问高峰期数据库服务器的CPU负载一直在80%以上，网站服务器的CPU负载也保持在平均70%。加速、加速、再加速就成为领导嘴中的问号与感叹号。
有很多成功的经验可以从网上找到，当然也不能放过改版之前网站的成功经验。于是我们找到了下面几种加速方法（虽然这个时候再出想有什么加速方法已经非常晚了，但也还是要进行下去。）
下面是几种用上的加速方法
1. ASP.net本身的页面缓存技术与数据缓存技术 各种的网站开发语言都会有自己缓存技术，可以在开发过程中进行运用。页面缓存是将页面通过在ASPX的页面上用<%outputcache….%>写上缓存的时间，缓存的方案。数据缓存则可以将几乎所有ASP.net支持的变量按照你所想要的方式缓存起来，以提供给程序调用时使用。
2. 针对复杂的查询建立索引
除去一开始进行的设计时已经建立好的索引，你可能还需要在网站对数据库访问很大时，用SQL的事务跟踪器去找出查询语句的瓶颈，并为之想出相应的方法，比如用存储过程，为还没有建立索引的表建好索引，多建几张临时表，等等。由于我数据库方面不是很熟，这里就不多说了。
3. 将DB的读写进行分离
这是前辈们传下来的宝贵经验，同时对SQL数据库进行读写操作是非常慢的一种数据库访问方式，比较好的方式是根据读写的压力不用，分别建立两类结构完全相同的数据库服务器，将负责写的那类服务器的数据定时复制给负责读的服务器。
4. 将DB与Web服务器分离
DB与Web服务器在一台机器上会使访问速度变慢。所以要使得网站加速，这方面也需要进行考虑。
5. 将常用的数据，以及更新比较少的数据形成静态文件
网站的开发，有一些数据变化量是非常小的，比如详细文章页面，采编人员将其输入进我们的系统之后，几乎不进变化。这种情况下，可以采用将常用的数据定期的生成静态的数据文件的方法。来对网站进行提速。程序可以通过访问静态文件的方式，来达到提高网站整体速度的目的。
这里要对这个方式进行简单的说明，数据库情况好的时候，对数据库的读写是比对文件的读写要快的，但是如果大量的对数据库进行读写，或是每一次都会有比较复杂的逻辑对数据库进行读操作时，并且在实时性要求不太高的情况下，不如将这些复杂的操作每次的生成静态的数据文件，这样可以使得程序每次只需要对静态文件进行读操作，可以达到减轻数据库压力的效果。
还有一个好处是，万一数据库发生无法读取的数据故障，那么网站的实际上是可以运营在这些静态的数据文件之上的，在系统运行并不稳定的运营初期，这样的数据文件是非常有意义。这种加速方式可以对应到上面的Asp.net的数据缓存。由于所有的数据都被存储成标准的XML格式数据文件，所以这种数据缓存方式不仅仅可以在Asp.net的应用程序使用，也在可以提供给其它的一些应用使用，
6. 将被访问的动态页面通过加速程序定时生成静态页面，以提供给用户一个静态的页面快照。
终级加速方案？可以将动态页面定时读出，另存为静态页面。与Asp.net的页面缓存相似，唯一区别是页面加速可控度高，而且如果Asp.net无法执行，静态页面也可以很方便的在其它的HTTP
server上使用。
以上所说的是在Asp.net+SQL的环境下可以采用的网站加速的方式。可以老实的告诉大家，第5种与第6种方式都是在系统运行不稳定的情况下，或是对IIS6没有信心的情况下的产物。我个人并不推荐大家采用。
说完了目前网站所采用的方式之后，想与大家分享一下运用这些加速方式之后的体会，以及得到的一些经验与教训。希望大家在以后的网站开发过程中不要重复同样的错误。
l 加速---不是太少，而是太多
可以从上面所说的得出一个结论，如果一个网站在设计与运行的过程中，即有数据库级的加速，又有业务逻辑层的加速，还有最终页面级的加速，那么存在问题就会是，是不是所有的加速形式都必须要存在？是不是有你已经做了一些没有意义的费工作？实际上，当我重新回头去看堆积在网站中的所有加速方法时，不禁产生一堆疑问：为什么在我已经定义好了页面缓存之后还要有一堆循环生成的数据文件？为什么数据库的索引都建好之后还要有数据级的缓存？什么情况下有了页面缓存还需要有页面加速？……，当一大堆的为什么出现在你面前时，你才能够了解，去给一个网站加速的方式不是太少，而是太多，你所要做的是选择出那些最少，最合适的方案来处理你所要面对的问题，而不是慌慌张张的将你要知道的所有的加速方案都堆砌在网站上，这样得到的结果可能就会是网站的更新效率低下，维护费用增加，不确定性也在增加，等等。所以，记住，加速的方法，不是太少，而是太多，要合理进行选择。
l 不要因为一次错误而进行否决某种方案
如果你试了一下数据加速的方法，发现你的网站的访问速度没有得到很好的提高，那么你会怎么样？放弃后找一条新的路子，还是对仔细研究你的这次试验的结果究竟说明了什么？看看我上面的说的，当你有太多的选择时，你可能会对每一项都并不看重，那么你错了，我的项目组在选择加速方式的时候走过一些回头路，这些回头路都是由于我们提出一个好的方案A，试一下，没有太好的效果之后马上放弃，转到另一次的实验，通过一段时间的运行，突然又发现方案A不好使的原因是由于其它的原因，而不是方案A本身的原因，再回头使用方案A，又花费很多的时间与精力。所以在可以选择方案很多的情况下，也一定要慎重的考虑，而不要因为一次错误而进行否决某种方案。
总而言之，网站加速一定是要在开始的设计阶段计划好，而设计之后的调整就是属于很痛苦的，这个就与面向方面编程（AOP）所说的问题有一些共同的地方。AOP的问题回头再与大家讨论吧。
|
会员价 
代理价 