• 1. 架构设计 之 性能评估叶军 2010.10.20从民工到建筑师,考古学家讲不完的话下次接着搞第二季
  • 2. 没有血的 ,就不会有刻骨铭心的记忆 , 好的 是解决性能的法宝之一,即 又给力的 问题,我从 说起,高性能的系统一般都会牺牲一些可用性或是扩展性一般来说, 是性能约束的最终电子是光速,一秒可以绕地球几圈? 速度因节点转换设备带来性能延迟较大应用服务的 与事务处理能力受到程序效率, ,程序依赖的外部设备, 如 , , ,等影响,每秒种处理的客户端请求不同, 需估算好设计容量,以免出现惊喜;性能的评估总是离开不前端的并发数, 一定数量级下,很小的一个性能开销都会被成百上千倍的放大,10ms会变成10s, 而正常网页用户的体验是 ,有时我们也使用 消息或线程来提升响应速度 实现对系统整体的性能影响也非常大, 多一个浏览器的 的性能开销很明显的Outline #Tag Clouds#CAP磁盘瓶颈性能并发性网络3秒RMDBSK-VInverted Index前端案例请求数线程架构与设计省电异步
  • 3. CAPCAP:一致性,可用性,分区容错性 Consistency(一致性), 数据一致更新,所有数据变动都是同步的 Availability(可用性), 好的响应性能 Partition tolerance(分区容错性) 可靠性 定理:任何分布式系统只可同时满足二点,没法三者兼顾。 忠告:架构师不要将精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍。 水平或垂直拆分数据,最终一致性,软状态,高性能
  • 4. PICK TWO
  • 5. 性能问题分解
  • 6. 磁盘IO Time = Seek Time + 60 sec/Rotational Speed/2 + IO Chunk Size/Transfer Rate 于是我们可以这样计算出IOPS IOPS = 1/IO Time = 1/(Seek Time + 60 sec/Rotational Speed/2 + IO Chunk Size/Transfer Rate) 对于给定不同的IO大小我们可以得出下面的一系列的数据 4K (1/7.1 ms = 140 IOPS) 5ms + (60sec/15000RPM/2) + 4K/40MB = 5 + 2 + 0.1 = 7.1 8k (1/7.2 ms = 139 IOPS) 5ms + (60sec/15000RPM/2) + 8K/40MB = 5 + 2 + 0.2 = 7.2 16K (1/7.4 ms = 135 IOPS) 5ms + (60sec/15000RPM/2) + 16K/40MB = 5 + 2 + 0.4 = 7.4 32K (1/7.8 ms = 128 IOPS) 5ms + (60sec/15000RPM/2) + 32K/40MB = 5 + 2 + 0.8 = 7.8 64K (1/8.6 ms = 116 IOPS) 5ms + (60sec/15000RPM/2) + 64K/40MB = 5 + 2 + 1.6 = 8.6 从上面的数据可以看出,当单次IO越小的时候,单次IO所耗费的时间也越少,相应的IOPS也就越大。 随机与顺序读写的性能各有特点
  • 7. 为什么是40MB/s流行的ATA/66(即Ultra DMA/66或UDMA/66)以及ATA/100(即Ultra DMA/100或UDMA/100)标准分别支持66MBps和100MBps的最大传输速率 最新的SerialATA标准更让传输速率达到了150Mbps以上。 SCSI2 : 300MB/s 我们的局域 网络,网卡,单反的SD卡呢?
  • 8. 吞吐量Transfer Rate = IOPS * IO Chunk Size 还是那上面的第一组IOPS的数据我们可以得出相应的传输速度如下 4K: 140 * 4K  =  560K / 40M = 1.36% 8K: 139 * 8K  = 1112K / 40M = 2.71% 16K: 135 * 16K = 2160K / 40M = 5.27% 32K: 116 * 32K = 3712K / 40M = 9.06% 连续大IO看吞吐量
  • 9. 几个硬盘的例子KINGSTON SD6 6MB/S,1080P拍摄需要多少?SSD:西部数据笔记本硬盘:
  • 10. 网络7层网络协议:APSTNDP 并发连接数:设备维持多个会话的能力 每个连接占用内存数量 长连接与短连接(TCP/UDP):建链接与拆链接的能力 TCP:TIMEOUT与重发机制,每个连接的RTT加倍机制 SYNC FLOOD攻周,就是服务器没拿到第三次握手
  • 11. TCP报文最多并发65535个SOCKET,因为16位
  • 12. OSLOAD: load(t) = load(t − 1) e^(− 5/60m )+ n(t) (1 − e^(− 5/60m )) 其中: • m = 1, 5, 15 表示经过的时间 • load(t) 表示现在的负载 • load(t − 1) 表示上一次时间的负载 • n(t) 表示当前活动进程(active processes)的数目。 单核1.0正常,双核2.0(cat /proc/cpuinfo)
  • 13. 其它OS相关CPU: 几核 MEM: SWAP使用是否充分 JVM:多大合理有效?堆分析工具 句柄:打开文件数据 “too many files open” Default 1024 Ulimit –n lsof -n |awk ‘{print $2}’|sort|uniq -c |sort -nr|more     查看当前进程打开的句柄
  • 14. 并发/事务QPS  并发用户数量-与服务器进行交互的在线用户数量  请求响应时间-从客户端发出请求到得到响应的整个事时间(一般包括 网络响应时间+server的响应时间)  事务请求响应时间-完成这个事务所用的时间  吞吐率-单位时间在网络上传输的数据量   TPS-每秒系统处理事务个数  点击率-每秒发送的HTTP请求的数量  资源利用率-对不同资源的使用程度(内存,硬盘,CPU等)
  • 15. TPS图
  • 16. 静态与动态CDN的TPS APACHE的TPS MEMCACHE的TPS DB的TPS K-V的TPS JBOSS的TPS F5->应用集群->cache->持久化设备 硬件比软件快,内存比磁盘快
  • 17. 数据源数据源的性能关注连接数和服务并发性 HTTP比RMI差? CORBA?ICE? MARSHALLING?RMDBsFILE SYSTEMK-VMem cacheSearch Inverted indexWEB APPLICATION/DAMON APP.Remote services
  • 18. 客户端http连接数 COOKIE大小 客户端缓存 图片个数 400? 每个主机并发数
  • 19. 14 rules
  • 20. CASE STUDY秒批机器评估,前端短时瞬发型 淘江湖的FEEDS,前端长期压力型 UDB与旺旺登陆异常,后端短时瞬发压力型 开心农场好友列表与头像 K-V选型
  • 21. 秒批50并发与100并发 PV100万实际 情况 预算最悲观情况 : 平均50WPV/60分/60秒=140TPS 算10倍 1400TPS 10台机器 实际是2倍 2-4台就可
  • 22. 我的评估条件: 1:目前一天PV50; 2:有500W的DM发给买家; 预算: 若:正常情况下1小时内产生50W PV(即10%的DM用户来参加秒批),每分钟8500个PV,每秒125个HTTP请求,活动期间算是10倍平常压力,需要1250个TPS。 现在我们的单机算10个USER并发下最高峰值20TPS每人,则单机峰值200PV每秒;支撑1250个TPS需要7台秒批WEB机。 后续的下订单过程不会像秒批页面这样大的PV,属于二跳页面,分流算成25%,则订单机需要4台WEB应用服务器(假设订单服务器性能是秒批机的一半),加上1000个下单的程序限制,估计4台可以支持。 没考虑到磁盘DB的性能
  • 23. 淘江湖FEEDS10个用户并发查看动态FEEDS首页 760 TPS 每人50个好友,每人每天10个FEEDS 每条FEEDS 1kB 按容量活跃100万用户算 需要多少台机器提供FEEDS存储与RW? 6个月内 如何CACHE?
  • 24. UDB与农场查看API服务器的堆栈信息,发现有6、7个Web工作线程blocked在UDBServiceImpl.getPortaritUrl。 该方法是专门提供给阳光牧场用于显示头像的,并且在用户第一次进入游戏时,阳光牧场循环为每个好友调用getProfileByLongId获取头像。 头像图片来自淘宝IMAGE SERVER 500W人在线 100万在9点左右登陆农场 每人50个好友 100/30分/60秒*50TPS调用 2.8万TPS ICE接口性能2000TPS 内部VIP 500TPS 以上为攻击
  • 25. 查看了一下API服务器中tuscany的代码,发现默认的Web工作线程数是10个,竟然还是fixed的?!这就是问题所在! 框架、容器皆有可能引起性能问题 LOG日志级别使用不合理,也可能引起性能问题 KILL -3 进程号 DUMP线程看BLOCK Jboss.log
  • 26. K-V选型-飞天环境配置 1. 硬件环境: 配置6块硬盘的机器(1 disk系统盘,5 disk为pangu数据盘) 内存48G 2.飞天KVEngine配置: 6 server( 每个Server用5块硬盘作为数据盘) Maxcopy=3,MinCopy=3 开启BlockCache(8G/16G/24G,详见下面的读测试用例)
  • 27. 用例用例简述:不同客户端并发线程下每次写入单条kv(key: 20字节以内,value:7K) ,统计性能。 抓取国际站访问5天的访问日志(accesslog),约8千万记录,从accesslog中取到unique product id,共计3100万 以unique product id为key,自己产生的value(7k),全部写入到kvengine 在有3100万数据的基础上,客户端10线程下写入1000万(key顺序生成),统计测试结果 在有4100万数据的基础上,客户端20线程下写入1000万(key顺序生成),统计测试结果 在有5100万数据的基础上,客户端50线程下写入1000万(key顺序生成),统计测试结果 在有6100万数据的基础上,客户端50线程下写入2000万(key顺序生成),不统计结果,得到数据8000万数据,占500G存储 在8000万数据的基础上,为了验证数据量大小是否会造成性能下降,加测25线程的用例,性能并没有下降,这种高IO的系统,如果key足够离散,那么当线程数和disk数目一致时应当到达性能的最佳值。
  • 28. 测试结果Key生成规则数据量操作次数并发线程数TPS响应时间(ms)AvgMinMax80%95%99%顺序生成3100万1000万1048002.080.68465. 692.554.677.544100万1000万2063493.150.73254.734.276.288.555100万1000万50490610.190.74624.6912.4317.4627.70AccessLog’s unique id8000万3180万256793 3.680.711101.584.97.059.58
  • 29. CASSANDRAKey生成规则数据量操作次数并发线程数TPS响应时间(ms)AvgMinMax80%95%99%顺序生成3100万1000万1020544.651.450686.853.9811.4127.344100万1000万2030786.111.509835.574.89918.4137.695100万1000万50327812.111.5031063.4314.3431.8584.74
  • 30. 常识一切都是浮云,意识形态为先 APACHE JBOSS LIGHT MEMCACHE HTTP MYSQL ORACEL PE?性能工程 师?
  • 31. Ref.http://www.slideshare.net/techdude/high-performance-web-sites http://www.slideshare.net/stoyan/high-performance-web-pages-20-new-best-practices http://www.yejun.cn/ http://www.dbanotes.net/arch/twitter_performance.html http://www.artima.com/scalazine/articles/twitter_on_scala.html
  • 32. A&Q谢谢大家赏光