登录/注册
下载豆瓣客户端
豆瓣
6.0
全新发布
×
豆瓣
扫码直接下载
iPhone
·
Android
豆瓣
读书
电影
音乐
同城
小组
阅读
FM
时间
豆品
豆瓣读书
搜索:
购书单
电子图书
2023年度榜单
2023年度报告
《大规模Web服务开发技术》的原文摘录
按热度排序
按页码排序
1、GB级别的数据处理 2、内存的重要性 (
查看原文
)
破军
2011-10-30 15:14:06
—— 引自第117页
3、以分布式为主的运维 (
查看原文
)
破军
2011-10-30 15:14:06
—— 引自第117页
4、选择恰当的算法和数据结构 (
查看原文
)
破军
2011-10-30 15:14:06
—— 引自第117页
压缩就是分析符号的出现频率,用短编码标记频繁出现的符号,用长编码标记其余符号 (
查看原文
)
简体中文
2011-12-22 10:15:36
—— 引自第127页
通过基于Trie的正则表达式实现Common Prefix Search(公共前缀搜索) (
查看原文
)
简体中文
2011-12-22 10:19:35
—— 引自第112页
“%iowait”是 I/O 等待率。平均负载过高并且该数值也过高的话,可以认为高负载的原因就是 I/O 。 (
查看原文
)
henix
2012-01-28 20:39:25
—— 引自第47页
操作系统启动之后,要先把经常使用的数据库文件 cat 一遍。这样就能全部放进内存中。 以后大家在工作中构建系统的时候,就要进行性能测试和负载测试。那时请记住,一定要把第一次测试结果放弃掉。刚开始时缓存尚未优化 (
查看原文
)
henix
2012-01-28 20:43:11
—— 引自第80页
如果缓存不过来的话:就需要扩展到多台服务器上。CPU负载分散只需简单的增加数据库即可;IO负载分散则需要考虑局部性 (
查看原文
)
libisthanks
2012-05-05 14:22:08
—— 引自第69页
感觉上而言 (
查看原文
)
[已注销]
2013-01-28 14:41:00
—— 引自第147页
<del>....</del> (
查看原文
)
[已注销]
2013-01-28 14:42:41
—— 引自第193页
成长为大规模服务之后,一个人负责开发和运维当然是很困难的,所以要由多名技术人员分担。人一多,有些问题就不得不考虑了。例如,应当如何标准化开发?各个开发者随意进行的系统开发过程中,是不是该考虑一下应用程序实现方案?是否要统一编程语言、统一库函数和框架、统一代码规范使之标准化,并利用版本管理系统认真管理源代码呢?只有正确地实施这些,才能发挥多人的效率。胡乱进行的话,就算增加了人手,生产力也不会提高。 这种标准化绝不是仅仅选个工具就行的,而必须有人负责全局的推进。诸如每个开发者是否遵守标准化规约、是否存在由于开发者之间水平差异导致的低效率、新人应该如何培训等,都表明了团队管理的重要性。 (
查看原文
)
tonight
2013-02-03 16:16:51
—— 引自第11页
首当其冲的就是“无法在内存中计算”。为什么说无法在内存中计算是难点呢?因为内存中放不下的话,通常就得一直读磁盘,在磁盘中找啊找啊还是找不到。数据量过大时,其输入数据量也相应增大,计算量当然也会增大,但比这更为严重的问题就是“需要读磁盘”。 (
查看原文
)
tonight
2013-02-03 16:41:08
—— 引自第28页
处理大规模数据的三个重点------写程序的技巧 1、“能在内存中完成多少?”。为什么必须在内存中完成?如前所述,磁盘寻道次数极大地影响着可扩展性和性能。因此,应在最大限度减少磁盘寻道次数的意义上灵活运用内存。此外,还应充分利用局部性的分布式。 2、“使用能应对数据量增加的算法”。单纯使用线性搜索的话,1000万条数据就要计算1000万次,而使用对数据级的算法,只需几十次就可以完成。例如:线性搜索--->二叉树搜索; O(n)--->O(log n) 3、有时可以利用数据压缩和搜索等技术。通过压缩等方法缩小数据,以减少寻道次数,使磁盘读取次数降到最低,而且更容易缓存到内存中。太大的数据无法放入内存,就算保存到磁盘上,读取也要花费时间,所以压缩十分重要。 (
查看原文
)
tonight
2013-02-03 17:08:07
—— 引自第44页
以Partitioning为前提进行设计 避免JOIN,利用where...in... (
查看原文
)
tonight
2013-02-03 17:16:27
—— 引自第102页
稳定性措施 一、维持适当的余量(buffer) 1、内存容量、CPU负载--->使用到极限的7成 二、去除不稳定因素 1、规定SQL负载上限--->必要时将负载过高的SQL移到其他主机上 2、减少内存泄漏 3、异常行为的自律控制 自动Dos判断(mod_dossdetector) 自动重启(应用程序服务器和宿主操作系统) 自动终止耗时查询(KILL掉耗时过长的SQL) (
查看原文
)
tonight
2013-02-03 18:46:43
—— 引自第269页
寻找瓶颈的基本流程: 1.查看平均负载; 2.确认CUP,I/O有无瓶颈。 1.查看平均负载 top,uptime等命令 2.查找CPU和I/O的瓶颈 sar; top; ps; strace; oprofile; vmstat (
查看原文
)
流水秋鸿
2013-10-25 14:56:32
—— 引自第33页
学习负载均衡的重点是理解操作系统的运行原理: 包括: 操作系统缓存; 多线程、多进程; 虚拟内存机制; 文件系统; 根据操作系统的擅长和不擅长之处进行整体优化。 (
查看原文
)
流水秋鸿
2013-10-26 16:00:57
—— 引自第81页
创建Dictionary 1将单词当做term处理 1.1 字典+ Aho-Corsick算法切分单词 1.2 使用语素分析(Mecab 等等) 2 将n-gram 当做term处理 (
查看原文
)
流水秋鸿
2013-11-07 08:30:50
—— 引自第206页
SSD的访问性能: 1.良好的随机访问性能; 2.内存>SSD>HDD RAID-0/10> HDD RAID-1 尽管不如内存快,但也十分迅速 3.Hatena的生产环境用的是 Intel SSD X-25E/m (
查看原文
)
流水秋鸿
2013-11-25 08:46:04
—— 引自第287页
网络分界点: 1.超过1Gpbs(从路由器性能来看应该是30 万 pps)->PC路由器的极限 2.超过500台主机->一个子网的极限 由交换机的ARP表极限限制 3.全球化->一个数据中心的极限 网络架构的层次化(三层架构) 1.最小的为访问层(Access Area,一二百台) 2.上面是分发层(Distribution Area,1000台左右) 3.最上方为核心层(Core Area)或OSPF层(几万台左右) 超越10Gbps的世界 1.获取AS编号 2.连接IX进行流量交换 3.用BGP控制路由 (
查看原文
)
流水秋鸿
2013-11-25 08:58:32
—— 引自第297页
>
我来写笔记
>
大规模Web服务开发技术
作者:
伊藤直也, 田中慎司
isbn:
7121138840
书名:
大规模Web服务开发技术
页数:
336
译者:
李剑
定价:
59.00元
出版社:
电子工业出版社
出版年:
2011-7