支撑点StackOverflow经营的网站硬件配置配备共享

2021-02-22 10:53 admin

问与答小区互联网 StackExchange 由 100 好几个网站组成,在其中包含了 Alexa 排名第 54 的 StackOverflow。StackExchang 有 400 万客户,每个月 5.6 亿 PV,但只用 25 台服务器,而且 CPU 负荷其实不高。

它沒有应用云计算技术,由于云计算技术将会会拖慢速率,更难提升和更难清除系统软件常见故障。

StackOverflow 依然应用微软的构架,它十分具体,微软的基本设备能合理工作中,又充足便宜,沒有让人相信的理由必须做出更改。但这其实不表明它不应用 Linux,它将 Linux 用在成心义的地区。

它的 Windows 服务器运作的实际操作系统软件版本号是 Windows 2012 R2,Linux 服务器运作 Centos 6.4。

网站数据信息库 MS SQL 尺寸 2TB,统统存储在 SSD 上,它有 11 台运作 IIS 的 Web 服务器,2 台运作 HAProxy 的负载平衡服务器,2 台运作 Redis 的缓存文件服务器。

StackOverflow 是1个 IT 技术性问与答网站,客户能够在网站上递交和回应难题。当下的 StackOverflow 已有着 400 万个客户,4000 万个回应,月 PV5.6 亿,全球排行第 54。但是值得关心的是,支撑点她们网站的所有服务器仅有 25 台,而且都维持着十分低的資源应用率,这是1场高合理性、负载平衡、缓存文件、数据信息库、检索及高效率编码上的交锋。近日,High Scalability 创办人 Todd Hoff 依据 Marco Cecconi 的演讲视頻“ The architecture of StackOverflow”和 Nick Craver 的博文“ What it takes to run Stack Overflow”总结了 StackOverflow 的取得成功缘故。

预料当中,也是预料以外,Stack Overflow 依然重度应用着微软的商品。她们觉得既然微软的基本设备能够考虑要求,又充足划算,那末沒有甚么理由去做压根上的更改。而在必须的地区,她们一样应用了 Linux。究其压根,1切全是以便特性。

另外一个值得关心的地区是,Stack Overflow 依然应用着纵向拓展对策,沒有应用云。她们应用了 384GB 的运行内存和 2TB 的 SSD 来支撑点 SQL Servers,假如应用 AWS 的话,花销显而易见。沒有应用云的另外一个缘故是 Stack Overflow 觉得云会1定水平上的减少特性,另外也会给提升和清查系统软件难题提升难度。另外,她们的构架也其实不必须横向拓展。峰值期内是横向拓展的杀手级运用情景,但是她们拥有丰富多彩的系统软件调剂工作经验去解决。该企业依然坚持不懈着 Jeff Atwood 的名言——硬件配置始终比程序流程员划算。

Marco Ceccon 曾提到,在谈及系统软件时,有1件事儿务必最先弄搞清楚——必须处理难题的种类。最先,从简易层面下手,StackExchange 到底是用来做甚么的——最先是1些主题,随后紧紧围绕这些主题创建小区,最终就产生了这个让人钦佩的问与答网站。

其次则是经营规模有关。StackExchange 在飞速提高,必须解决很多的数据信息传送,那末这些全是怎样进行的,非常是只应用了 25 台服务器,下面1起追根揭底:

情况

StackExchange 有着 110 个站点,以每月 3 到 4 个的速率提高。
400 万客户
800 万难题
4000 万回答
全球排名 54 位
每一年提高 100%
月 PV 5.6 千万
大多数数工作中时间间峰值为 2600 到 3000 恳求每秒,做为1个程序编写有关网站,1般状况下工作中日的恳求都会高于周末
25 台服务器
SSD 中存储了 2TB 的 SQL 数据信息
每一个 web server 都配备了 2 个 320G 的 SSD,应用 RAID 1
每一个 ElasticSearch 主机都配置了 300GB 的机械电脑硬盘,另外也应用了 SSD
Stack Overflow 的读写能力比为 40:60
DB Server 的均值 CPU 运用率是 10%
11 个 web server,应用 IIS
2 个负载平衡器,1 个活跃,应用 HAProxy
4 个活跃的数据信息库连接点,应用 MS SQL
3 台完成了 tag engine 的运用程序流程服务器,全部检索都根据 tag
3 台服务器根据 ElasticSearch 做检索
2 台应用了 Redis 的服务器支撑点遍布式缓存文件和信息
2 台 Networks(Nexus 5596 + Fabric Extenders)
2 Cisco 5525-X ASAs
2 Cisco 3945 Routers
关键服务 Stack Exchange API 的 2 个写保护 SQL Servers
VM 用于布署、域操纵器、监管、运维管理数据信息库等场所


服务平台

ElasticSearch
Redis
HAProxy
MS SQL
Opserver
TeamCity
Jil——Fast .NET JSON Serializer,创建在 Sigil 之上
Dapper——微型的 ORM
UI

UI 有着1个信息内容收件箱,用于新徽章得到、客户推送信息内容、重特大恶性事件产生时的信息内容扣除,应用 WebSockets 完成,并根据 Redis 支撑点。
检索箱根据 ElasticSearch 完成,应用了1个 REST 插口。
由于客户提出难题的频率很高,因而很难显示信息全新难题,每秒都会有新的难题造成,从而这里必须开发设计1个关心客户个人行为方式的优化算法,只给客户显示信息感兴趣爱好的难题。它应用了根据 Tag 的繁杂查寻,这也是开发设计单独 Tag Engine 的缘故。
服务器端模版用于转化成网页页面。


服务器

25 台服务器并沒有载满,CPU 应用率其实不高,单测算 SO(Stack Overflow)只必须 5 台服务器。
数据信息库服务器空间运用率在 10% 上下,除下实行备份数据时。
为何会这么低?由于数据信息库服务器足足有着 384GB 运行内存,另外 web server 的 CPU 运用率也仅有 10%⑴5%。
纵向拓展都还没遇到短板。一般状况下,这般总流量应用横向拓展大概必须 100 到 300 台服务器。
简易的系统软件。根据 .Net,只用了 9 个新项目,别的系统软件将会必须 100 个。之因此应用这么少系统软件是以便追求完美极限的编译程序速率,这点必须从系统软件刚开始时就开展整体规划,每台服务器的编译程序時间大概是 10 秒。
11 万行编码,比照总流量来讲十分少。
应用这类极简的方法关键根据几个缘故。最先,不必须太多检测,由于 Meta.stackoverflow 原本便是1个难题和 bug 探讨小区。其次,Meta.stackoverflow 還是1个手机软件的检测网站,假如客户发现难题的话,常常会提出并给予处理计划方案。
纽约数据信息管理中心应用的是 Windows 2012,早已向 2012 R2 升級(Oregon 早已进行了升級),Linux 系统软件应用的是 Centos 6.4。


SSD

默认设置应用的是 Intel 330(Web 层等)
Intel 520 用于正中间层写入,例如 Elastic Search
数据信息层应用 Intel 710 和 S3700
系统软件另外应用了 RAID 1 和 RAID 10(任何4+ 以上的硬盘都应用 RAID 10)。不惧怕常见故障产生,即便生产制造自然环境中应用了上千块 2.5 英寸 SSD,还没碰到过1块不成功的场景。每一个实体模型都应用了 1 个以上的备件,好几个硬盘产生常见故障的场景不在考虑到当中。
ElasticSearch 在 SSD 上主要表现的出现异常优异,由于 SO writes/re-indexes 的实际操作十分经常。
SSD 更改了检索的应用方法。由于锁的难题,Luncene.net 其实不能支撑点 SO 的高并发负载,因而她们转为了 ElasticSearch。在全 SSD 自然环境下,其实不必须紧紧围绕 Binary Reader 创建锁。


高能用性

异地备份数据——主数据信息管理中心坐落于纽约,备份数据数据信息管理中心在 Oregon。
Redis 有两个从连接点,SQL 有 2 个备份数据,Tag Engine 有 3 个连接点,elastic 有 3 个连接点,冗余1切,并在两个数据信息管理中心另外存在。
Nginx 是用于 SSL,停止 SSL 时变换应用 HAProxy。
其实不是主从关系全部,1些临时性的数据信息只会放到缓存文件中
全部 HTTP 总流量推送只占流量的 77%,还存在 Oregon 数据信息管理中心的备份数据及1些别的的 VPN 总流量。这些总流量关键由 SQL 和 Redis 备份数据造成。

数据信息库

MS SQL Server
Stack Exchange 为每一个网站都设定了数据信息库,因而 Stack Overflow 有1个、Server Fault 有1个,以此类推。
在纽约的主数据信息管理中心,每一个群集一般都应用 1 主和 1 写保护备份数据的配备,另外还会在 Oregon 数据信息管理中心也设定1个备份数据。假如是运作的是 Oregon 群集,那末两个在纽约数据信息管理中心的备份数据都会是写保护和同歩的。
为别的內容提前准备的数据信息库。这里还存在1个“互联网范畴”的数据信息库,用于存储登录凭据和汇聚数据信息(绝大多数是 stackexchange.com 客户文档或 API)。
Careers Stack Overflow、stackexchange.com 和 Area 51 等都有着自身单独的数据信息库方式。
方式的转变必须另外出示给全部站点的数据信息库,它们必须向下适配,举个事例,假如必须重取名1个列,那末将十分不便,这里必须开展好几个实际操作:提升1个新列,加上功效在两个列上的编码,给新列写数据信息,更改编码让新列合理,移除旧列。
其实不必须分块,全部事儿根据数据库索引来处理,并且数据信息体积也没那末大。假如有 filtered indexes 要求,那末为何不更高效率的开展?普遍方式只在 DeletionDate = Null 上做数据库索引,别的则根据为枚举类型特定种类。每项 votes 都设定了 1 个表,例如1张表给 post votes,1 张表给 comment votes。绝大多数的网页页面都可以以即时3D渲染,只为密名客户缓存文件,因而,不存在缓存文件升级,仅有重查寻。
Scores 是是非非标准化的,因而必须常常查寻。它只包括 IDs 和 dates,post votes 报表当下大概有 56454478 行,应用数据库索引,绝大多数的查寻都可以以在数毫秒内进行。
Tag Engine 是彻底单独的,这就代表着关键作用其实不依靠任何外界运用程序流程。它是1个极大的运行内存构造数字能量数组构造,专为 SO 测试用例提升,并为重负载组成开展预测算。Tag Engine 是个简易的 windows 服务,冗余的运作在好几个主机上。CPU 应用率基础上维持在2⑸%,3 个主机专业用于冗余,不承担责任何负载。假如全部主机另外产生常见故障,互联网服务器将把 Tag Engine 载入到运行内存中不断运作。
有关 Dapper 无编译程序器校检查寻与传统式 ORM 的比照。应用编译程序器有许多益处,但在运作时依然会存在 fundamental disconnect 难题。另外更关键的是,因为转化成 nasty SQL,一般状况还必须去找寻初始编码,而 Query Hint 和 parameterization 操纵等工作能力的欠缺更让查寻提升变得繁杂。
编号

步骤
绝大多数程序流程员全是远程控制工作中,自身挑选编号地址
编译程序十分快
随后运作小量的检测
1旦编译程序取得成功,编码即迁移至开发设计交货提前准备服务器
根据作用电源开关掩藏新作用
在同样硬件配置上做为别的站点检测运作
随后迁移至 Meta.stackoverflow 检测,每日有上千个程序流程员在应用,1个很好的检测自然环境
假如根据则上线,在更众多的小区开展检测
很多应用静态数据类和方式,以便更简易及更好的特性
编号全过程十分简易,由于繁杂的一部分挨打包到库里,这些库被开源系统和维护保养。.Net 新项目数量很低,由于应用了小区共享资源的一部分编码。
开发设计者另外应用 2 到 3 个显示信息器,好几个显示屏能够明显提升生产制造高效率。
缓存文件

缓存文件1切
5 个级别的缓存文件
1 级是互联网级缓存文件,缓存文件在访问器、CDN 和代理商服务器中。
2 级由 .Net 架构 HttpRuntime.Cache 进行,在每台服务器的运行内存中。
3 级 Redis,遍布式运行内存键值储存,在好几个支撑点同1个站点的服务器上共享资源缓存文件项。
4 级 SQL Server Cache,全部数据信息库,全部数据信息都被放到运行内存中。
5 级 SSD。一般只在 SQL Server 预热后才起效。
举个事例,每一个协助网页页面都开展了缓存文件,浏览1个网页页面的编码十分简易:
应用了静态数据的方式和类。从 OOP 角度看来的确很糟,可是十分快并有益于简约编号。
缓存文件由 Redis 和 Dapper 支撑点,1个微型 ORM
以便处理废弃物搜集难题,模版中 1 个类只应用 1 个副本,被创建和储存在缓存文件中。监测1切,包含 GC 操。据统计分析显示信息,间接性层提升 GC 工作压力做到了某个水平时会明显的减少特性。
CDN Hit 。鉴于查寻标识符串根据文档內容开展哈希,只在有新创建时才会被再度取下。每日 3000 万到 5000 万 Hit,带宽敞约为 300GB 到 600GB。
CDN 并不是用来解决 CPU 或I/O负载,而是协助客户更快的得到回答
布署

每日 5 次布署,不去创建过大的运用。关键由于
能够立即的监控特性
尽量最少化创建,能够工作中才是关键
商品创建后再根据强劲的脚本制作复制到各个网页页面层,每一个服务器的流程是:
根据 POST 通告 HAProxy 下架某台服务器
延迟时间 IIS 完毕现有恳求(大概 5 秒)
终止网站(根据同1个 PSSession 完毕全部下游)
Robocopy 文档
打开网站
根据另外一个 POST 做 HAProxy Re-enable
基本上全部布署全是根据 puppet 或 DSC,升級一般只是大力度调剂 RAID 阵列并根据 PXE boot 安裝,这样做十分迅速。
合作

精英团队
SRE (System Reliability Engineering):5 人
Core Dev(Q&A site)6⑺ 人
Core Dev Mobile:6 人
Careers 精英团队专业负责 SO Careers 商品开发设计:7 人
Devops 和开发设计者融合的十分密不可分
精英团队间转变很大
绝大多数职工远程控制工作中
办公室关键用于市场销售,Denver 和 London 以外
1切公平,一丝偏重纽约工作中者,由于应对面有助于工作中沟通交流,可是线上工作中危害也其实不大
比照能够在同1个办公室办公,她们更偏重喜爱商品及有才气的工程项目师,她们能够很好的考量利与弊
很多人由于家中而挑选远程控制工作中,纽约是非常好,可是日常生活其实不宽松
办公室开设在曼哈顿,那是本人才的诞生地。数据信息管理中心不可以太偏,由于常常会涉及到升級
打造1个强劲精英团队,钟爱极客。初期的微软就集聚了很多极客,因而她们吸引了全部全球
Stack Overflow 小区也是个招骋的地址,她们在那找寻喜爱编号、助人为乐及喜爱沟通交流的优秀人才。


定编费用预算

费用预算是新项目的基本。钱只花在为最新项目创建基本设备上,这般低运用率的 web server 還是 3 年前数据信息管理中心创建时购入。
检测

迅速迭代更新和抛弃
很多检测全是公布团队进行的。开发设计有着1个一样的 SQL 服务器,而且运作在同样的 Web 层,因而特性检测其实不会不尽人意。
十分少的检测。Stack Overflow 并沒有开展太多的模块检测,由于她们应用了很多的静态数据编码,也有1个十分活跃的小区。
基本设备更改。鉴于全部物品都有双份,因此每一个旧配备都有备份数据,并应用了1个迅速常见故障修复体制。例如,keepalived 能够在负载平衡器中迅速返回。
比照按时维护保养,她们更想要依靠冗余系统软件。SQL 备份数据用1个专业的服务器开展检测,只以便能够重储存。方案做每两个月1次的全数据信息管理中心常见故障修复,或应用彻底写保护的第2数据信息管理中心。
每次新作用公布都做模块检测、集成化检测盒 UI 检测,这就代表着能够预知键入的商品作用检测后就会消息推送到孵化网站,即 meta.stackexchange(原 meta.stackoverflow)。
监控/系统日志

当下正在考虑到应用 http://logstash.net/做系统日志管理方法,现阶段应用了1个专业的服务将 syslog UDP 传送到 SQL 数据信息库中。网页页面中为计时加上 header,这样便可以根据 HAProxy 来捕捉而且结合到 syslog 传送中。
Opserver 和 Realog 用于显示信息精确测量結果。Realog 是1个系统日志展现系统软件,由 Kyle Brandt 和 Matt Jibson 应用 Go 创建。
系统日志根据 HAProxy 负载平衡器依靠 syslog 进行,而并不是 IIS,由于其作用比 IIS 更丰富多彩。
有关云

還是老调重弹,硬件配置始终比开发设计者和合理率的编码划算。根据木桶效用,速率毫无疑问受到限制于某个薄弱点,现有的云服务基础上都存在容量和特性限定。
假如从刚开始就应用云来基本建设 SO 说不确定也会做到如今的水准。但没什么疑惑的是,假如做到一样的特性,应用云的成本费将远远高于自建数据信息管理中心。
特性高于一切

StackOverflow 是个重度的特性控,首页载入的時间始终操纵在 50 毫秒内,当下的回应時间是 28 毫秒。
程序流程员热衷于于减少网页页面载入時间和提升客户体验。
每一个单独的互联网递交都予以计时和纪录,这类计量能够搞清楚提高特性必须改动的地区。
这般低資源运用率的关键缘故便是高效率的编码。web server 的 CPU 均值运用率在5% 到 15% 之间,运行内存应用为 15.5 GB,互联网传送在 20 Mb/s到 40 Mb/s。SQL 服务器的 CPU 应用率在5% 到 10% 之间,运行内存应用是 365GB,互联网传送为 100 Mb/s到 200 Mb/s。这能够带来 3 个益处:给升級留下很大的室内空间;在比较严重不正确产生时能够维持服务能用;在必须时能够迅速回档。我更想要把Stack Overflow看做是可以运作于大经营规模数据信息下,但自身其实不算大经营规模的(running with scale but not at scale)。意思是大家的网站十分合理率,但最少现阶段为止,大家的经营规模还不足“大”。让大家根据1些数据来详细介绍Stack Overflow当今是1个如何的经营规模吧。下列是1些关键的数据,来自于没多久前在1一天到晚(24小时)内的统计分析,精确说是2013年11月12日。这是1个典型的工作中日,而且只统计分析了大家主题活动的数据信息管理中心,也便是大家自身的服务器。那些对CDN连接点的恳求和总流量被清除出外,由于它们其实不立即浏览大家的互联网。

负载平衡器接纳了148,084,833次HTTP恳求
在其中36,095,312次是载入网页页面
833,992,982,627 bytes (776 GB) 的HTTP总流量用于推送
一共接受了286,574,644,032 bytes (267 GB) 数据信息
一共推送了1,125,992,557,312 bytes (1,048 GB) 数据信息
334,572,103次SQL查寻(仅包括来自于HTTP恳求的)
412,865,051次Redis恳求
3,603,418次标识模块恳求
耗时558,224,585 ms (155 hours) 在SQL查寻上
耗时99,346,916 ms (27 hours) 在Redis恳求上
耗时132,384,059 ms (36 hours) 在标识模块恳求上
耗时2,728,177,045 ms (757 hours) 在ASP.Net程序流程解决上
(我感觉应当发布1篇文章内容详细介绍大家怎样迅速收集这些数据信息,和为何值得消耗活力去获得它们)

留意以上数据包含了全部Stack Exchange互联网,但那其实不是大家所有的。除此以外,这些数据也仅仅来自于大家以便检验特性而纪录的HTTP恳求。“哇,1天有这么好几个小时,你们如何保证的?”大家把这叫做魔法,自然一些人喜爱说成“很多个有多核解决器的服务器”,但大家仍然坚持不懈这是魔法。下列是那个数据信息管理中心里运作Stack Exchange互联网的机器设备:

4个MS SQL 服务器
11个IIS服务器
2个Redis服务器
3个标识模块服务(任何对于标识的恳求都会浏览它们,例如/questions/tagged/c++)
3个ElasticSearch服务器
2个负载平衡器(HAProxy)
2个互换机(Nexus 5596和Fabric Extenders)
2个Cisco 5525-X ASA (可看做是防火墙)
2个Cisco 3945 Router
有图有实情:

大家不仅运作网站,周围架子上也有1些运作着虚似机的服务器和别的机器设备,它们其实不立即服务于网站,而是开展布署、网站域名操纵、监管、实际操作数据信息库等别的工作中。上面目录中的两个数据信息库服务器以前1直全是用作备份数据,直至近期才做为写保护的负载(关键用于Stack Exchange API),因而大家能够不必须太多考虑到便再次扩张经营规模了。Web服务器有两个各自用于开发设计和储存元数据信息,运作负载十分低。

 让大家再来总结1下:

关键机器设备

假如去除那些过剩的机器设备,下列是Stack Exchange运作必须的(维持现阶段的特性水平):

2个MS SQL服务器(Stack Overflow在1台,别的的在另外一台,具体上只需1台设备运作还能有充裕)
2个Web服务器(也许3个吧,但是我有自信心2个足矣)
1个Redis服务器
1个标识模块服务器
1个ElasticSearch服务器
1个负载平衡器
1个互换机
1个ASA
1个路由器器
(大家真该找个机遇尝试这个配备,关掉一部分机器设备,看看极限在哪儿)

如今也有1些虚似机运作在后台管理,实行1些輔助作用,例如网站域名操纵这些。但那全是些非常低负载的每日任务,大家就不做探讨了,这里把重心放在Stack Overflow自身,看看它是如何全速载入出网页页面的。假如你期待更精准全面,能够提升1个VMware虚似机进来,用于实行全部的輔助工作中。这样来看其实不必须许多设备,可是这些设备的规格型号一般在云上无法完成,除非你有充足多的钱。下列是这些“提高型”服务器扼要的配备详细介绍:

数据信息库服务器有384GB运行内存和1.8TB的SSD电脑硬盘
Redis服务器有96GB运行内存
ElasticSearch服务器有196GB运行内存
标识模块服务器拥有大家能买得起的最快的解决器
互换机每一个端口号有10Gb的带宽
Web服务器并不是很非常,有32GB运行内存、2个4核解决器和300GB的SSD电脑硬盘
一些服务器有2个10Gb带宽的插口(例如数据信息库),别的有4个1Gb带宽的
20Gb的带宽太过剩了?你还真特么说对了,主题活动的数据信息库服务器均值只运用了20Gb安全通道中的100⑵00Mb。但是,像备份数据、复建这些实际操作,依据当今运行内存和SSD电脑硬盘的状况,可使带宽彻底饱和状态,因此说这样设计方案還是成心义的。

 

储存机器设备

大家现阶段有大概2TB的数据信息库储存(第1个群集有18块SSD电脑硬盘—— 一共1.63TB,应用1.06TB;第2个群集由4块SSD电脑硬盘构成—— 一共1.45TB,应用889GB),这是大家在云服务器上必须的(嗯哼,又要调侃价钱了吧),请记牢这所有全是SSD电脑硬盘。归功于储存器优良的主要表现,大家数据信息库的均值写入時间是0毫秒,乃至超过大家能衡量的精度了。算上运行内存中的数据信息和两级缓存文件,Stack Overflow中具体的数据信息库读写能力占比是40:60。你没看错,60%是写实际操作(点此掌握读写能力比)。另外,每一个Web服务器都有两块320GB SSD电脑硬盘构成的RAID1。ElasticSearch在每一个区块大概必须300GB的容量,因为大家会十分经常的写入或复建数据库索引,SSD电脑硬盘在这里是更好的挑选。

值得留意的是大家有着1个SAN(储存地区互联网)联接到关键互联网,那便是 Equal Logic PS6110X,它有24个可热互换的10K SAS硬盘和2个10Gb的操纵器。这个机器设备仅仅被VM服务器用作共享资源存储室内空间以确保虚似机高宽比的能用性,但其实不具体支撑点网站的运作。换句话说,假如SAN挂掉了,在1段時间内网站乃至没法发觉(仅有虚似机中的网站域名操纵器能认知到)。

 

整合到1起

这全部的机器设备在1起是以便甚么?特性。大家必须很高的特性,这是1个对大家来讲很关键的特点。全部站点的主页全是难题网页页面,大家內部把它亲切地称作Question/Show(路由器的姓名)。在11月12日,这个网页页面均值3D渲染時间是28毫秒,而大家的规定是最多50ms。以便应用户得到更好的体验,大家尽1切将会减少网页页面载入的時间,哪怕仅有1毫秒。在和特性相关的难题上,大家全部的开发设计人员全是“锱铢必较”的,这也是有助于大家的网站维持迅速回应。下列是1些Stack Overflow上热门网页页面的均值3D渲染時间,数据信息還是来自于前面统计分析的那24小时:

Question/Show: 28 ms (2970万次点一下)
User Profiles: 39 ms (170万次点一下)
Question List: 78 ms (110万次点一下)
Home page: 65 ms (100万次点一下) (这对大家来讲早已很慢了,Kevin Montrose正在下手修补这个难题)
凭着对每次恳求的時间线的纪录,大家可以精确观查到网页页面载入的全过程。大家必须这样的数据信息,不然难道说靠脑补来做决策吗?了解据在手,大家便可以这样监管特性:

假如你对某个特殊网页页面的数据信息感兴趣爱好,我也很乐意公布出来。但这里我关键关心3D渲染時间,由于它表明大家的服务器必须多久来转化成1个网页页面。互联网传送速率是1个彻底不一样的话题了(虽然迫不得已认可它也是有很大的关联),但是未来我会讲到的。

 

提高室内空间

十分值得1提的是大家这些服务器运作时的应用率都十分低。例如Web服务器的CPU均值应用率为5⑴5%,运行内存只应用了15.5GB,互联网总流量仅有20⑷0Mb/s;而数据信息库服务器CPU均值应用率为5⑴0%,应用了365GB运行内存,和100⑵00Mb/s的互联网。这使大家能保证几件关键的事儿:在网站经营规模增大时不至于必须立刻升級机器设备;当出現难题时(不正确的查寻、编码和进攻这些,不管是甚么样的难题),大家能维持网站自始至终不挂;在必要的情况下减少功耗。这里有个大家Web层的监管新项目:

运用率这般之低的关键缘故是高效率的编码。虽然本文的主题其实不是这个,可是高效率的编码对发掘服务器的特性也是有着决策性的功效。做1件非必要的事儿所损害的,竟然比苟且偷安还要多——把这引伸到编码中便是说,你必须把它们改善得更高效率了。这些损害或耗费能够是电力能源、硬件配置(你必须更多更快的服务器)、开发设计人员了解编码更艰难(平心而论,这个有双面性,高效率的编码其实不1定那末简易),和迟缓的网页页面3D渲染——将会致使客户更少地访问网站别的网页页面乃至不再浏览你的网站了。低高效率编码带来的损害将会比你想像的大许多。