高性能是什么?其本质是什么东东?

高性能涉及的东西有很多,该怎么才能记住呢?

我觉得这是一个很有代表性的问题,相信很多人都有类似的困惑,所以决定写篇文章来好好聊聊这个问题。

确实是这样,当初在准备高性能相关的面试问题时,也是同样的感受,有好多东西啊,该想个什么办法把它们都串起来呢?

计算机运行的本质,或者说程序执行的本质,就是CPU不断取出内存中的指令,然后执行它。

在这个过程中,CPU需要与内存打交道,因为程序指令在这里面;还需要与硬盘、网卡等一些外部设备打交道,存储数据、传输数据。

CPU、内存、外部设备,这三个是计算机最主要的三个东西,所以我们在思考高性能的问题时,围绕这三个东西,就可以把很多技术串起来。

1、让CPU执行指令更快一点
程序是CPU在执行,最容易想到的当然就是让CPU跑的更快一些。这方面主要是涉及硬件技术,跟软件关系不大。

比如提高CPU主频、指令流水线技术、乱序执行、分支预测等等。

2、使用缓存
程序运行经常需要读取和加载数据,当程序经常需要从一个慢速设备读取数据时,性能势必会受到影响。所以,可以先把数据缓存到一个能快速获取的地方,加快数据加载速度,然后选择适当的时机来更新缓存中的数据。

缓存技术在计算机中无处不在,CPU中有存放数据和指令的一二三级缓存,还有存放内存地址翻译的TLB缓存。

操作系统中的文件系统管理硬盘数据也使用了页缓存Page Cache。

后端服务为了快速获取数据,使用Redis/Memcache作为内存数据缓存,避免每次都从数据库中查询。

浏览器中为了加快渲染速度,也有前端资源的缓存,避免每次都找网站服务器请求。

网站服务器为了提高响应速度,也有CDN缓存。

3、减少CPU被打断次数
CPU在运行过程中不是一直埋头执行程序,它时不时的会被打断,这就是中断。

最典型的就是网络数据包处理,如果在很大网络流量下,网卡每来一个数据包都通过中断告诉CPU,那CPU一天别干活了,烦都要烦死了。

所以Linux内核中的NAPI技术通过轮询网卡,减少中断次数就能显著提高性能。

另外DMA技术通过把数据传输的工作外包出去,解放CPU,也是这一思想的应用。

4、减少内存拷贝
很多时候,程序需要频繁拷贝数据,但拷贝数据的过程时比较耗时的,如果能减少拷贝的次数,无疑会提高程序性能。

比如内存映射、零拷贝技术就属于这一类技术。

另外高性能抓包技术DPDK,让应用程序直接读取网卡,减少数据拷贝也是这种思想的体现。

5、并行与并发
这个思想很直接,一个人干活忙不过来,那就多找几个人一起干。并行与并发的思想同样在计算机领域无处不在。

如CPU的多核技术,超线程技术、单指令多数据技术SIMD等。

多线程技术、NUMA技术、多节点负载均衡技术等。

后端服务开发中的I/O多路复用技术(select/poll/epoll)。

6、减少锁的竞争
前面提到多线程技术,而提到多线程就离不开锁。很多时候,线程在锁的竞争上浪费了太多时间,上下文的切换这些都需要有开销。

所以减少锁的竞争也是提高性能的一种方式,这方面的技术有原子操作、无锁编程等。

7、资源池化技术
很多程序运行启动时就预先分配好资源,而不是在需要的时候才去分配,这也是一种提高性能的方法。最常见的有线程池、内存池。

8、减少I/O次数
程序运行的时候经常要从硬盘上读取数据,而这类操作是非常耗时的,如果能减少I/O的次数,合并I/O次数,对性能的提升将是巨大的。

体现这类思想的技术有B+树、SQL批量执行等。

9、良好的数据结构与算法
程序的灵魂是数据结构与算法,前面说了那么多,即便都做到了,但如果你的数据结构和算法设计的一塌糊涂那也是白搭。

良好的数据结构与算法能够从根本上解决高性能的问题。

这方面思想的体现有哈希表、B+树、跳表等。

总结
上面这几个点不是孤立存在的,很多时候都是互相交织在一起的综合应用。比如零拷贝技术,既是减少内存拷贝的思想,也是减少打扰CPU的思想。在I/O多路复用epoll中,既是并发思想体现,也有减少内存拷贝思想的体现。

最后来总结一下,下次回答提高性能可以从四个增加、四个减少、一个良好来展开:

增加CPU速度、增加缓存、增加并行度、增加资源池

减少内存拷贝、减少I/O次数、减少CPU被打断次数、减少锁竞争

良好的数据结构与算法

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
整理的高性能高并发服务器架构文章,内容预览:  初创网站与开源软件 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  七种缓存使用武器 为网站应用和访问加速发布时间: 92  可缓存的CMS系统设计 93  开发大型高负载类网站应用的几个要点 105  Memcached和Lucene笔记 110  使用开源软件,设计高性能可扩展网站 110  面向高负载的架构Lighttpd+PHP(FastCGI)+Memcached+Squid 113  思考高并发高负载网站的系统架构 113  "我在SOHU这几年做的一些门户级别的程序系统(C/C++开发)" 115  中国顶级门户网站架构分析1 116  中国顶级门户网站架构分析 2 118  服务器的大用户量的承载方案 120  YouTube Scalability Talk 121  High Performance Web Sites by Nate Koechley 123 One dozen rules for faster pages 123 Why talk about performance? 123 Case Studies 124 Conclusion 124  Rules for High Performance Web Sites 124  对于应用高并发,DB千万级数量该如何设计系统哪? 125  高性能服务器设计 130  优势与应用:再谈CDN镜像加速技术 131  除了程序设计优化,zend+ eacc(memcached)外,有什么办法能提高服务器的负载能力呢? 135  如何规划您的大型JAVA多并发服务器程序 139  如何架构一个“Just so so”的网站? 148  最便宜的高负载网站架构 152  负载均衡技术全攻略 154  海量数据处理分析 164  一个很有意义的SQL的优化过程(一个电子化支局中的大数据量的统计SQL) 166  如何优化大数据量模糊查询(架构,数据库设置,SQL..) 168  求助:海量数据处理方法 169 # re: 求助:海量数据处理方法 回复 更多评论 169  海量数据库查询方略 169  SQL Server 2005对海量数据处理 170  分表处理设计思想和实现 174  Linux系统高负载 MySQL数据库彻底优化(1) 179  大型数据库的设计与编程技巧 本人最近开发一个访问统计系统,日志非常的大,都保存在数据库里面。 我现在按照常规的设计方法对表进行设计,已经出现了查询非常缓慢地情形。 大家对于这种情况如何来设计数据库呢?把一个表分成多个表么?那么查询和插入数据库又有什么技巧呢? 谢谢,村里面的兄弟们! 183  方案探讨,关于工程中数据库的问题. 184  web软件设计时考虑你的性能解决方案 190  大型Java Web系统服务器选型问题探讨 193  高并发高流量网站架构 210 1.1 互联网的发展 210 1.2 互联网网站建设的新趋势 210 1.3 新浪播客的简介 211 2.1 镜像网站技术 211 2.2 CDN内容分发网络 213 2.3 应用层分布式设计 214 2.4 网络层架构小结 214 3.1 第四层交换简介 214 3.2 硬件实现 215 3.3 软件实现 215  网站架构的高性能和可扩展性 233  资料收集:高并发 高性能 高扩展性 Web 2.0 站点架构设计及优化策略 243  CommunityServer性能问题浅析 250 鸡肋式的多站点支持 250 内容数据的集中式存储 250 过于依赖缓存 250 CCS的雪上加霜 250 如何解决? 251  Digg PHP's Scalability and Performance 251  YouTube Architecture 253 Information Sources 254 Platform 254 What's Inside? 254 The Stats 254 Recipe for handling rapid growth 255 Web Servers 255 Video Serving 256 Serving Video Key Points 257 Serving Thumbnails 257 Databases 258 Data Center Strategy 259 Lessons Learned 260 1. Jesse • Comments (78) • April 10th 261 Library 266 Friendster Architecture 273 Information Sources 274 Platform 274 What's Inside? 274 Lessons Learned 274  Feedblendr Architecture - Using EC2 to Scale 275 The Platform 276 The Stats 276 The Architecture 276 Lesson Learned 277 Related Articles 278 Comments 279 Re: Feedblendr Architecture - Using EC2 to Scale 279 Re: Feedblendr Architecture - Using EC2 to Scale 279 Re: Feedblendr Architecture - Using EC2 to Scale 280  PlentyOfFish Architecture 281 Information Sources 282 The Platform 282 The Stats 282 What's Inside 283 Lessons Learned 286  Wikimedia architecture 288 Information Sources 288 Platform 288 The Stats 289 The Architecture 289 Lessons Learned 291  Scaling Early Stage Startups 292 Information Sources 293 The Platform 293 The Architecture 293 Lessons Learned 294  Database parallelism choices greatly impact scalability 295  Introduction to Distributed System Design 297 Table of Contents 297 Audience and Pre-Requisites 298 The Basics 298 So How Is It Done? 301 Remote Procedure Calls 305 Some Distributed Design Principles 307 Exercises 308 References 309  Flickr Architecture 309 Information Sources 309 Platform 310 The Stats 310 The Architecture 311 Lessons Learned 316 Comments 318 How to store images? 318 RE: How to store images? 318  Amazon Architecture 319 Information Sources 319 Platform 320 The Stats 320 The Architecture 320 Lessons Learned 324 Comments 329 Jeff.. Bazos? 329 Werner Vogels, the CTO of 329 Re: Amazon Architecture 330 Re: Amazon Architecture 330 Re: Amazon Architecture 330 It's WSDL 330 Re: It's WSDL 331 Re: Amazon Architecture 331  Scaling Twitter: Making Twitter 10000 Percent Faster 331 Information Sources 332 The Platform 332 The Stats 333 The Architecture 333 L

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值