logo资料库

非常全面的高性能高并发服务器架构解决方案.doc

第1页 / 共375页
第2页 / 共375页
第3页 / 共375页
第4页 / 共375页
第5页 / 共375页
第6页 / 共375页
第7页 / 共375页
第8页 / 共375页
资料共375页,剩余部分请下载后查看
初创网站与开源软件
谈谈大型高负载网站服务器的优化心得!
浏览量比较大的网站应该从哪几个方面入手?
用负载均衡技术建设高负载站点
大型网站的架构设计问题
 大型、高负载网站架构和应用初探时间:30-45分钟
mixi技术架构
mixi.jp:使用开源软件搭建的可扩展SNS网站
总概关键点:
1,Mysql 切分,采用Innodb运行
2,动态Cache 服务器 --
美国Facebok.com,中国Yeejee.com,日本mixi.jp均采用开源分布式缓存服务器M
3,图片缓存和加
memcached+squid+apache deflate解决网站大访问量问题
FeedBurner:基于MySQL和JAVA的可扩展Web应用
YouTube 的架构扩展
Web 服务器
视频
数据库
 Myspace架构历程
站点处理能力
计算能力
存储硬件
应用服务器
架构
其他信息
后记
从LiveJournal后台发展看大规模网站性能优化方法
一、LiveJournal发展历程
二、LiveJournal架构现状概况
三、从LiveJournal发展中学习
1、一台服务器
2、两台服务器
3、四台服务器
4、五台服务器
5、更多服务器
6、现在我们在哪里:
7、现在我们在哪里
8、现在我们在哪里
9、缓存
10、Web访问负载均衡
11、MogileFS
论坛
分类信息
归档数据库
搜索数据库
Authdb
七种缓存使用武器 为网站应用和访问加速发布时间:
可缓存的CMS系统设计
思考高并发高负载网站的系统架构
"我在SOHU这几年做的一些门户级别的程序系统(C/C++开发)"
服务器的大用户量的承载方案
High Performance Web Sites by Nate Koechley
One dozen rules for faster pages
Why talk about performance?
Case Studies
Conclusion
Rules for High Performance Web Sites
对于应用高并发,DB千万级数量该如何设计系统哪?
高性能服务器设计
优势与应用:再谈CDN镜像加速技术
除了程序设计优化,zend+ eacc(memcached)外,有什么办法能提高服务器的负载能力呢?
Snake.Zero (2007-7-03 17:37:31)
cdexs (2007-7-03 18:42:16)
虾球桑 (2007-7-04 03:06:24)
cdexs (2007-7-04 10:04:32)
Snake.Zero (2007-7-04 10:35:38)
cdexs (2007-7-04 11:26:38)
pigpluspower (2007-7-04 14:55:49)
cdexs (2007-7-04 14:58:59)
Snake.Zero (2007-7-04 16:24:38)
太阳雨 (2007-7-04 17:28:05)
cdexs (2007-7-04 20:08:07)
Snake.Zero (2007-7-04 21:25:52)
ok7758521ok (2007-7-07 12:29:54)
如何规划您的大型JAVA多并发服务器程序
如何架构一个“Just so so”的网站?
负
海量数据处理分析
如何优化大数据量模糊查询(架构,数据库设置,SQL..)
SQL Server 2005对海量数据处理
分表处理设计思想和实现
Linux系统高负载 MySQL数据库彻底优化(1)
大型数据库的设计与编程技巧本人最近开发一个访问统计系统,日志非常的大,都保存在数据库里面。我
方案探讨,关于工程中数据库的问题.
james2308大哥,你那数据库分表的功能实现了吗
大型Java Web系统服务器选型问题探讨
高并发高流量网站架构
1.1 互联网的发展
1.2 互联网网站建设的新趋势
1.3 新浪播客的简介
2.1 镜像网站技术
2.2 CDN内容分发网络
2.3 应用层分布式设计
2.4 网络层架构小结
3.1 第四层交换简介
3.2 硬件实现
3.3 软件实现
资料收集:高并发 高性能 高扩展性 Web 2.0 站点架构设计及优化策略
鸡肋式的多站点支持
内容数据的集中式存储
过于依赖缓存
CCS的雪上加霜
如何解决?
YouTube Architecture
Information Sources
Platform
What's Inside?
The Stats
Recipe for handling rapid growth
Web Servers
Video Serving
Serving Video Key Points
Serving Thumbnails
Databases
Lessons Learned
1.
Why That List Sucks
1.He's swinging for the top of the trees
2.Good problems, bad solutions
3.That's just...yeah
My list
4.Benchmark, benchmark, benchmark!
5.Profile, profile, profile!
6.Tighten Up Your Schema
7.Partition Your Tables
8.Don't Overuse Artificial Primary Keys
9.Learn Your Indices
10.SQL is Not C
11.Understand your engines
12.MySQL specific shortcuts
13.And one for the road...
Library
Friendster Architecture
Information Sources
Platform
What's Inside?
Lessons Learned
Feedblendr Architecture - Using EC2 to Scale
The Platform
The Stats
The Architecture
Lesson Learned
Related Articles
Comments
PlentyOfFish Architecture
Information Sources
The Platform
The Stats
What's Inside
Lessons Learned
Wikimedia architecture
Information Sources
Platform
The Stats
The Architecture
Lessons Learned
Scaling Early Stage Startups
Information Sources
The Platform
The Architecture
Lessons Learned
Database parallelism choices greatly impact scalab
Introduction to Distributed System Design
Table of Contents
Audience and Pre-Requisites
The Basics
So How Is It Done?
Remote Procedure Calls
Some Distributed Design Principles
Exercises
References
Flickr Architecture
Information Sources
Platform
The Stats
The Architecture
Lessons Learned
Comments
Amazon Architecture
Information Sources
Platform
The Stats
The Architecture
Lessons Learned
Comments
Scaling Twitter: Making Twitter 10000 Percent Fast
Information Sources
The Platform
The Stats
The Architecture
Lessons Learned
Related Articles
Comments
Google Architecture
Information Sources
Platform
What's Inside?
The Stats
The Stack
Reliable Storage Mechanism with GFS (Google File S
Do Something With the Data Using MapReduce
Storing Structured Data in BigTable
Hardware
Misc
Future Directions for Google
Lessons Learned
Digg Architecture
Information Sources
Platform
The Stats
What's Inside
Lessons Learned
An Unorthodox Approach to Database Design : The Co
Information Sources
What is sharding?
How is sharding different than traditional archite
Some
Comments
LiveJournal Architecture
Information Sources
Platform
What's Inside?
Lessons Learned
GoogleTalk Architecture
Information Sources
Platform
What's Inside?
The Stats
Lessons Learned
由于自己正在做一个高性能大用户量的论坛程序,对高性能高并发服务器架构比较感兴趣, 于是在网上收集了不少这方面的资料和大家分享。希望能和大家交流 msn: defender_ios@hotmail.com ———————————————————————————————————————  初创网站与开源软件................................................................................................................ 6  谈谈大型高负载网站服务器的优化心得!.............................................................................. 8  Lighttpd+Squid+Apache 搭建高效率 Web 服务器 ..............................................................9  浏览量比较大的网站应该从哪几个方面入手? ..................................................................17  用负载均衡技术建设高负载站点 ..........................................................................................20  大型网站的架构设计问题......................................................................................................25 开源平台的高并发集群思考 .............................................................................................26   大型、高负载网站架构和应用初探 时间:30-45 分钟..................................................... 27  说说大型高并发高负载网站的系统架构..............................................................................28  mixi 技术架构 ..........................................................................................................................51 mixi.jp:使用开源软件搭建的可扩展 SNS 网站 ..................................................... 51 总概关键点: .................................................................................................................. 51 1,Mysql 切分,采用 Innodb 运行 ..........................................................................52 2,动态 Cache 服务器 --...........................................................................................52 美国 Facebok.com,中国 Yeejee.com,日本 mixi.jp 均采用开源分布式缓存服务 器 Memcache................................................................................................................52 3,图片缓存和加 ............................................................................................................52  memcached+squid+apache deflate 解决网站大访问量问题 ................................................. 52  FeedBurner:基于 MySQL 和 JAVA 的可扩展 Web 应用 ......................................................53  YouTube 的架构扩展..............................................................................................................55  了解一下 Technorati 的后台数据库架构........................................................................57  Myspace 架构历程 ...................................................................................................................58  eBay 的数据量...................................................................................................................... 64  eBay 的应用服务器规模 ...................................................................................................... 67  eBay 的数据库分布扩展架构..............................................................................................68  从 LiveJournal 后台发展看大规模网站性能优化方法 ........................................................ 70 一、LiveJournal 发展历程..........................................................................................70 二、LiveJournal 架构现状概况 ..................................................................................70 三、从 LiveJournal 发展中学习 .................................................................................71 1、一台服务器 ............................................................................................................... 71 2、两台服务器 ............................................................................................................... 72 3、四台服务器 ............................................................................................................... 73 4、五台服务器 ............................................................................................................... 73 5、更多服务器 ............................................................................................................... 74 6、现在我们在哪里: ................................................................................................... 75 7、现在我们在哪里 ....................................................................................................... 78 8、现在我们在哪里 ....................................................................................................... 79 9、缓存 ............................................................................................................................80 10、Web 访问负载均衡 ...............................................................................................80 11、MogileFS...............................................................................................................81
 Craigslist 的数据库架构 ..................................................................................................... 81  Second Life 的数据拾零 .....................................................................................................82 eBay 架构的思想金矿........................................................................................................84  一天十亿次的访问-eBay 架构(一)........................................................................... 85   七种缓存使用武器 为网站应用和访问加速发布时间:...................................................... 93  可缓存的 CMS 系统设计 ........................................................................................................94  开发大型高负载类网站应用的几个要点[nightsailer] ........................................................105  Memcached 和 Lucene 笔记 ..................................................................................................110  使用开源软件,设计高性能可扩展网站 ............................................................................111  面向高负载的架构 Lighttpd+PHP(FastCGI)+Memcached+Squid................................ 113  思考高并发高负载网站的系统架构....................................................................................114  "我在 SOHU 这几年做的一些门户级别的程序系统(C/C++开发)"..................................115 中国顶级门户网站架构分析 1.........................................................................................117  中国顶级门户网站架构分析 2.......................................................................................119   服务器的大用户量的承载方案............................................................................................121  YouTube Scalability Talk....................................................................................................... 122  High Performance Web Sites by Nate Koechley................................................................... 124 One dozen rules for faster pages ......................................................................124 Why talk about performance?............................................................................ 124 Case Studies .............................................................................................................. 125 Conclusion...................................................................................................................125  Rules for High Performance Web Sites..................................................................................125  对于应用高并发,DB 千万级数量该如何设计系统哪? .................................................125  高性能服务器设计 ................................................................................................................ 131  优势与应用:再谈 CDN 镜像加速技术 ............................................................................. 132  除了程序设计优化,zend+ eacc(memcached)外,有什么办法能提高服务器的负载能力呢? 136  如何规划您的大型 JAVA 多并发服务器程序 ................................................................... 139  如何架构一个“Just so so”的网站? .....................................................................................148  最便宜的高负载网站架构....................................................................................................152  负载均衡技术全攻略............................................................................................................ 154  海量数据处理分析 ................................................................................................................ 165  一个很有意义的 SQL 的优化过程(一个电子化支局中的大数据量的统计 SQL) .....167  如何优化大数据量模糊查询(架构,数据库设置,SQL..)..........................................169  求助:海量数据处理方法.......................................................................................................170 # re: 求助:海量数据处理方法 回复 更多评论....................................................... 170  海量数据库查询方略............................................................................................................ 170  SQL Server 2005 对海量数据处理.......................................................................................171  分表处理设计思想和实现....................................................................................................175  Linux 系统高负载 MySQL 数据库彻底优化(1)................................................................ 179  大型数据库的设计与编程技巧 本人最近开发一个访问统计系统,日志非常的大,都保 存在数据库里面。 我现在按照常规的设计方法对表进行设计,已经出现了查询非常缓慢地 情形。 大家对于这种情况如何来设计数据库呢?把一个表分成多个表么?那么查询和插入 数据库又有什么技巧呢? 谢谢,村里面的兄弟们!............................................................183
 方案探讨,关于工程中数据库的问题. [已结贴]................................................................ 185  web 软件设计时考虑你的性能解决方案 ............................................................................ 190  大型 Java Web 系统服务器选型问题探讨 .......................................................................... 194  高并发高流量网站架构........................................................................................................211 1.1 互联网的发展 ................................................................................................................. 211 1.2 互联网网站建设的新趋势.............................................................................................212 1.3 新浪播客的简介............................................................................................................. 212 2.1 镜像网站技术 ................................................................................................................. 213 2.2 CDN 内容分发网络 .........................................................................................................214 2.3 应用层分布式设计 .........................................................................................................215 2.4 网络层架构小结............................................................................................................. 215 3.1 第四层交换简介............................................................................................................. 215 3.2 硬件实现 ......................................................................................................................... 216 3.3 软件实现 ......................................................................................................................... 216  网站架构的高性能和可扩展性............................................................................................235  资料收集:高并发 高性能 高扩展性 Web 2.0 站点架构设计及优化策略.................. 245  CommunityServer 性能问题浅析 .......................................................................................251 鸡肋式的多站点支持....................................................................................................251 内容数据的集中式存储................................................................................................252 过于依赖缓存................................................................................................................252 CCS 的雪上加霜 .......................................................................................................... 252 如何解决? ....................................................................................................................252  Digg PHP's Scalability and Performance...............................................................................252  YouTube Architecture .............................................................................................................255 Information Sources............................................................................................................... 255 Platform.................................................................................................................................. 256 What's Inside?.........................................................................................................................256 The Stats ......................................................................................................................... 256 Recipe for handling rapid growth...................................................................................256 Web Servers....................................................................................................................257 Video Serving................................................................................................................. 257 Serving Video Key Points .............................................................................................. 258 Serving Thumbnails........................................................................................................259 Databases........................................................................................................................260 Data Center Strategy ...................................................................................................... 261 Lessons Learned..................................................................................................................... 261 Jesse · Comments (78) · April 10th........................................................................ 262 Library.................................................................................................................................. 268 Friendster Architecture........................................................................................................275 Information Sources ............................................................................................................ 275 Platform................................................................................................................................. 275 What's Inside?......................................................................................................................275 Lessons Learned................................................................................................................. 276  Feedblendr Architecture - Using EC2 to Scale...................................................................... 277 1.
The Platform ...........................................................................................................................277 The Stats ................................................................................................................................. 277 The Architecture..................................................................................................................... 278 Lesson Learned.......................................................................................................................279 Related Articles.......................................................................................................................280 Comments...............................................................................................................................280 Re: Feedblendr Architecture - Using EC2 to Scale....................................................... 280 Re: Feedblendr Architecture - Using EC2 to Scale....................................................... 281 Re: Feedblendr Architecture - Using EC2 to Scale....................................................... 282  PlentyOfFish Architecture......................................................................................................283 Information Sources............................................................................................................... 284 The Platform ...........................................................................................................................284 The Stats ................................................................................................................................. 284 What's Inside.......................................................................................................................... 285 Lessons Learned..................................................................................................................... 288  Wikimedia architecture...........................................................................................................289 Information Sources............................................................................................................... 290 Platform.................................................................................................................................. 290 The Stats ................................................................................................................................. 291 The Architecture..................................................................................................................... 291 Lessons Learned..................................................................................................................... 293  Scaling Early Stage Startups .................................................................................................. 294 Information Sources............................................................................................................... 295 The Platform ...........................................................................................................................295 The Architecture..................................................................................................................... 295 Lessons Learned..................................................................................................................... 296  Database parallelism choices greatly impact scalability.......................................297  Introduction to Distributed System Design...................................................................... 299 Table of Contents .........................................................................................................299 Audience and Pre-Requisites....................................................................................299 The Basics.................................................................................................................... 299 So How Is It Done?......................................................................................................303 Remote Procedure Calls ............................................................................................ 307 Some Distributed Design Principles.........................................................................309 Exercises.......................................................................................................................310 References....................................................................................................................311  Flickr Architecture..................................................................................................................311 Information Sources............................................................................................................... 311 Platform.................................................................................................................................. 312 The Stats ................................................................................................................................. 312 The Architecture..................................................................................................................... 313 Lessons Learned..................................................................................................................... 318 Comments...............................................................................................................................320 How to store images?..................................................................................................... 320
RE: How to store images?..............................................................................................320  Amazon Architecture..............................................................................................................321 Information Sources............................................................................................................... 321 Platform.................................................................................................................................. 322 The Stats ................................................................................................................................. 322 The Architecture..................................................................................................................... 322 Lessons Learned..................................................................................................................... 326 Comments...............................................................................................................................331 Jeff.. Bazos?....................................................................................................................331 Werner Vogels, the CTO of............................................................................................ 331 Re: Amazon Architecture............................................................................................... 332 Re: Amazon Architecture............................................................................................... 332 Re: Amazon Architecture............................................................................................... 332 It's WSDL ....................................................................................................................... 332 Re: It's WSDL.................................................................................................................333 Re: Amazon Architecture............................................................................................... 333  Scaling Twitter: Making Twitter 10000 Percent Faster......................................................... 333 Information Sources............................................................................................................... 334 The Platform ...........................................................................................................................334 The Stats ................................................................................................................................. 335 The Architecture..................................................................................................................... 335 Lessons Learned..................................................................................................................... 338 Related Articles.......................................................................................................................339 Comments...............................................................................................................................340 Re: Scaling Twitter: Making Twitter 10000 Percent Faster ...........................................340 Re: Scaling Twitter: Making Twitter 10000 Percent Faster ...........................................340 Re: Scaling Twitter: Making Twitter 10000 Percent Faster ...........................................340 Re: Scaling Twitter: Making Twitter 10000 Percent Faster ...........................................341 Re: Scaling Twitter: Making Twitter 10000 Percent Faster ...........................................341 Re: Scaling Twitter: Making Twitter 10000 Percent Faster ...........................................341 They could have been 20% better?................................................................................ 342 Re: Scaling Twitter: Making Twitter 10000 Percent Faster ...........................................342 Re: Scaling Twitter: Making Twitter 10000 Percent Faster ...........................................343  Google Architecture................................................................................................................343 Information Sources............................................................................................................... 344 Platform.................................................................................................................................. 344 What's Inside?.........................................................................................................................344 The Stats ......................................................................................................................... 344 The Stack ........................................................................................................................ 345 Reliable Storage Mechanism with GFS (Google File System) ..................................... 345 Do Something With the Data Using MapReduce.......................................................... 346 Storing Structured Data in BigTable.............................................................................. 348 Hardware........................................................................................................................ 349 Misc................................................................................................................................ 349
Future Directions for Google ......................................................................................... 350 Lessons Learned..................................................................................................................... 350 不管怎么样,先要找出瓶颈在哪个部分:是 CPU 负荷太高(经常 100%),还是内存不够用 (大量使用虚拟内存),还是磁盘 I/O 性能跟不上(硬盘指示灯狂闪)?这几个都是可以通 过升级硬件来解决或者改善的(使用更高等级的 CPU,更快速和更大容量的内存,配置硬 件磁盘阵列并使用更多数量的高速 SCSI 硬盘),但这需要较大的投入。 软件方面,如果使用了更大容量的内存和改善的 I/O 性能,已经能够大幅提高数据库的运行 效率,还可以配置查询缓存和进一步优化数据库结构和查询语句,就能让数据库的性能再进 一大步。 如果在服务器硬件投入上有困难,那就尽量生成静态页面。 作 者: BBSADM 标 题: 目前的 web 系统架构 时 间: Fri Apr 点 击: 100 6 20:15:56 2007 ------ nginx --------- | Squid | fastcgi (逐步迁移) | | proxy | 静态文件 Njuwebbsd (逐步迁移到 fastcgi 上) 最大好处是静态文件加速。 以后准备把帖子内容也静态化,实现最低负荷 而且用 nginx 做前台便于负载均衡,测试机可以拿来做静态文件的负载均衡  初创网站与开源软件 前面有一篇文章中提到过开源软件,不过主要是在系统运维的角度去讲的,主要分析一些系 统级的开源软件(例如 bind,memcached),这里我们讨论的是用于搭建初创网站应用的开源 软件(例如 phpbb,phparticle),运行在 Linux,MySQL,Apache,PHP,Java 等下面。 创业期的网站往往采用比较简单的系统架构,或者是直接使用比较成熟的开源软件。使用开 源软件的好处是搭建速度快,基本不需要开发,买个空间域名,下个软件一搭建,用个半天 就搞定了,一个崭新的网站就开张了,在前期可以极大程度的节约时间成本和开发成本。
当然使用开源软件搭建应用也存在一些局限性,这是我们要重点研究的,而研究的目的就是 如何在开源软件选型时以及接下来的维护过程中尽量避免。 一方面是开源软件一般只有在比较成熟的领域才有,如果是一些创新型的项目很难找到合适 的开源软件,这个时候没什么好的解决办法,如果非要用开源的话一般会找一个最相似的改 一下。实际上目前开源的项目也比较多了,在 sf.net 上可以找到各种各样的开源项目。选型 的时候尽量应该选取一个程序架构比较简单的,不一定越简单越好,但一定要简单,一目了 然,别用什么太高级的特性,互联网应用项目不需要太复杂的框架。原因有两个,一个是框 架复杂无非是为了实现更好的可扩展性和更清晰的层次,而我们正在做的互联网应用范围一 般会比开源软件设计时所考虑的范围小的多,所以有的应用会显得设计过度,另外追求完美 的层次划分导致的太复杂的继承派生关系也会影响到整个系统维护的工作量。建议应用只需 要包含三个层就可以了,数据(实体)层,业务逻辑层,表现层。太复杂的设计容易降低开发 效率,提高维护成本,在出现性能问题或者突发事件的时候也不容易找到原因。 另外一个问题是开源软件的后期维护和继续开发可能会存在问题,这一点不是绝对的,取决 于开源软件的架构是否清晰合理,扩展性好,如果是较小的改动可能一般不会存在什么问题, 例如添加一项用户属性或者文章属性,但有些需求可能就不是很容易实现了。例如网站发展 到一定阶段后可能会考虑扩展产品线,原来只提供一个论坛加上 cms,现在要再加上商城, 那用户系统就会有问题,如何解决这个问题已经不仅仅是改一下论坛或者 cms 就可以解决 了,这个时候我们需要上升到更高的层次来考虑问题,是否需要建立针对整个网站的用户认 证系统,实现单点登录,用户可以在产品间无缝切换而且保持登录状态。由于网站初始的用 户数据可能大部分都存放在论坛里,这个时候我们需要把用户数据独立出来就会碰到麻烦, 如何既能把用户数据独立出来又不影响论坛原有系统的继续运行会是件很头痛的事情。经过 一段时间的运行,除非是特别好的设计以及比较好的维护,一般都会在论坛里存在各种各样 乱七八糟的对用户信息的调用,而且是直接针对数据库的,这样如果要将用户数据移走的话 要修改代码的工作量将不容忽视,而另外一个解决办法是复制一份用户数据出来,以新的用 户数据库为主,论坛里的用户数据通过同步或异步的机制实现同步。最好的解决办法就是在 选型时选一个数据层封装的比较好的,sql 代码不要到处飞的软件,然后在维护的时候保持 系统原有的优良风格,把所有涉及到数据库的操作都放到数据层或者实体层里,这样无论对 数据进行什么扩展,代码修改起来都比较方便,基本不会对上层的代码产生影响。
网站访问速度问题对初创网站来说一般考虑的比较少,买个空间或者托管服务器,搭建好应 用后基本上就开始运转了,只有到真正面临极大的速度访问瓶颈后才会真正对这个问题产生 重视。实际上在从网站的开始阶段开始,速度问题就会一直存在,并且会随着网站的发展也 不断演进。一个网站最基本的要求,就是有比较快的访问速度,没有速度,再好的内容或服 务也出不来。所以,访问速度在网站初创的时候就需要考虑,无论是采用开源软件还是自己 开发都需要注意,数据层尽量能够正确,高效的使用 SQL。SQL 包含的语法比较复杂,实现 同样一个效果如果考虑到应用层的的不同实现方法,可能有好几种方法,但里面只有一种是 最高效的,而通常情况下,高效的 SQL 一般是那个最简单的 SQL。在初期这个问题可能不 是特别明显,当访问量大起来以后,这个可能成为最主要的性能瓶颈,各种杂乱无章的 SQL 会让人看的疯掉。当然前期没注意的话后期也有解决办法,只不过可能不会解决的特别彻底, 但还是要吧非常有效的提升性能。看 MySQL 的 SlowQuery Log 是一个最为简便的方法,把 执行时间超过 1 秒的查询记录下来,然后分析,把该加的索引加上,该简单的 SQL 简化。 另外也可以通过 Showprocesslist 查看当前数据库服务器的死锁进程,从而锁定导致问题的 SQL 语句。另外在数据库配置文件上可以做一些优化,也可以很好的提升性能,这些文章在 网站也比较多,这里就不展开。 这些工作都做了以后,下面数据库如果再出现性能问题就需要考虑多台服务器了,一台服务 器已经解决不了问题了,我以前的文章中也提到过,这里也不再展开。 其它解决速度问题的办法就不仅仅是在应用里面就可以实现的了,需要从更高的高度去设计 系统,考虑到服务器,网络的架构,以及各种系统级应用软件的配合,这里也不再展开。 良好设计并实现的应用+中间件+良好的分布式设计的数据库+良好的系统配置+良好的服 务器/网络结构,就可以支撑起一个较大规模的网站了,加上前面的几篇文章,一个小网站 发展到大网站的过程基本上就齐了。这个过程会是一个充满艰辛和乐趣的过程,也是一个可 以逐渐过渡的过程,主动出击,提前考虑,减少救火可以让这个过程轻松一些。  谈谈大型高负载网站服务器的优化心得! 因为工作的关系,我做过几个大型网站(书库、证券)的相关优化工作,一般是 在世界排行 1000-4000 以内的~~ 这些网站使用的程序各不一样,配置也不尽相同,但是它们有一个共同的特点,
分享到:
收藏