文档位置已迁移至如下链接：https://support.huaweicloud.com/tngg-kunpenghpcs/kunpenghpcsolution_05_0001.html

请参考如下图，不多说了，不熟悉的问度娘：后面会增加部分复杂工具的使用分享！敬请期待喔

（请严格按照回复示例进行回复，如回复格式不对，将不予奖励，谢谢）回复示例：华为云账户名：XXXX课程完成截图：（必须 包含课程名称、华为云账户名和完成进度条）请按照以上要求，在本课程下回帖。

性能调优是研发流程中的重要一环，它能够直接决定用户最终的体验，只有稳定良好的性能才能避免用户的流失。而像电商、社交等这些业务场景复杂的应用，想要做好性能调优也就越难！ 作为开发和测试人员，只要掌握了性能调优，也就掌握了打造完美用户体验的“金钥匙”！那么—— 玩转应有性能调优需要具备哪些基础知识？如何通过CPTS快速发起高并发压测？如何针对复杂业务场景进行应用性能调优？ 本课程以电商场景为案例，通过学习让你从基础入门到实战提升一站式掌握，系统学习应用性能调优，实现即学即用！参与打卡任务，还有机会获得《微服务架构与实践》书籍、荣耀手环等超值奖品；更有微认证8折专享优惠，get华为云官方认证，轻松为你的职业资质加分！ 活动参与方式：Step1：将下图海报转发至微信群（50人以上的群）或 朋友圈（公开可见状态），保留两小时以上，并截图。转发海报请附带以下文案：已报名，限时限量免费，坐等开课~Step2：扫下方二维码添加智能应用平台小助手微信（hwpaas01），将截图发送给小助手。Step3：小助手人工审核后，会为报名成功的朋友拉进“7天玩转电商应用性能调优”学习群并发放课程领取链接呦~ 活动过程如遇大量用户参与，会导致暂时无法添加助手微信号，大家可以稍等一段时间后再试。活动中有任何疑问，请添加智能应用平台小助手（微信：hwpaas01）咨询另外，对本次活动有任何想法和建议，欢迎在评论区回帖哦~ 

华为IPVS性能调优实践，附完整测试数据！！

不同的业务场景下，往往需要针对具体业务场景对系统进行性能调优，以获得最佳性能。CloudTable提供了丰富的可配置参数接口，可以方便用户根据自身的业务特征来进行性能优化。以下针对随机读密集型、顺序读密集型、写密集型三种典型的业务场景，给出优化思路和方法。1.随机读密集型思路：对于随机读密集型的工作负载，可以主要从如下2点思考进行优化：（1）高效利用缓存（2）更好地索引配置参数介绍建议hfile.block.cache.size块缓存是读缓存（LRU）。该属性定义块缓存可以使用的堆的最大百分比对于随机读密集型负载，增加缓存使用的堆的百分比hbase.regionserver.global.memstore.lowerLimithbase.regionserver.global.memstore.upperLimit这两个参数可以限定MemStore可以使用的堆的最大百分比对于随机读密集型负载，想通过增加块缓存占用堆的百分比（hfile.block.cache.size）来提升读性能时，需要同步使用这2个参数来减少MemStore占用的百分比HFile数据块大小HFile数据块大小可以在创建表的时候，通过BLOCKSIZE属性来指定。默认情况下，HFile Block size是64KB，通常来说，该值较为合理。但在随机读密集型负载下，可以尝试将该值减小，通过减少IO交互来提升随机读性能。布隆过滤器布隆过滤器可以通过在创建表的时候，通过BLOOMFILTER属性来指定。打开布隆过滤器可以减少为查找指定行的Key Value对象而读取的HFile数量。当值支持多种类型的布隆过滤器激进缓存可以在创建表的时候，通过IN_MEMORy属性来指定。该参数可以在列族层次设置，以便该列族比其他列族更加激进的进行缓存。该设置可以尽可能多的缓存数据，以此来提升读性能。合理的选择开启激进缓存的列族是性能调优的关键。关闭其他表和列族的缓存可以在列族层次设置，在读的时候不在BlockCache中进行缓存。通过创表中的BLOCKCACHE属性设置如果有一些列族被用于随机读而其他的列族没有被用到，没有被用到的列族可能会污染缓存。关闭它们的缓存会提升你的缓存命中率2.顺序读密集型思路：对于顺序读密集型的工作负责，读缓存不会带来太多好处，甚至有可能使用缓存比不使用缓存需要更频繁的访问硬盘。针对顺序度密集型的负载，可以考虑通过增加每次访问硬盘时的预读数据量来提高性能。配置参数介绍建议HFile数据块大小HFile数据块大小可以在创建表的时候，通过BLOCKSIZE属性来指定。数据块越大，每次访问硬盘可以获取的数据就越多，在顺序读场景下，可以有效提升性能hbase.client.scanner.caching该参数定义了扫描器上调用next方法时取回的行的数量。该数值越高，扫描操作时客户端需要向RegionServer发起的RPC调用越少，性能也就越高。代价是，该数字越高，客户端使用的内存越多。通过Scan.setCacheBlocks()API关闭数据块的缓存该参数定义被扫描的数据块是否应该放进块缓存扫描通常带来顺序读，在顺序读场景下，缓存不仅起不到正面作用，反而会因为连续的换入换出影响性能。因此对于大规模扫描操作，通过将该参数置为false来将数据块的cache关闭是一个好选择。关闭表缓存可以在设置列族时指定同上3.写密集型思路：因为在flush、Compaction、split过程中，会带来大量的读写IO，影响性能。所以，在写密集型业务下，可以通过避免频繁的flush，compaction，split来提升性能。配置参数介绍建议hbase.hregion.max.filesize该参数定义了region对应的存储文件的最大大小。如果列族的存储文件超过这个大小，那么该region被拆分。region越大意味着在写入时拆分越少。在写密集场景下，可以尝试调高该参数来提升性能。为表提前做的预分区在创建表时，可以指定为表做提前预分区通过提前做预分区，来避免写入过程中region分裂来影响性能。hbase.hregion.memstore.flush.size该参数定义了memstore的大小，当memstore超过这个值时，则会被flush到硬盘中。一个周期性运行的线程会检查memstore的大小通过调大该参数，可以减少生成的hfile数量，进而减少compaction次数。hbase.hstore.blockingWaitTime当到达Hfile的数量限制时（由hbase.hstore.blockingStoreFiles参数指定），阻塞hregion更新数据的时间。调小该参数值，可以减小阻塞时间hbase.hstore.blockingStoreFiles阻塞写入的最大Hfile数量值调大该参数值，可以降低或避免因hfile数量过多导致的阻塞（在写密集业务下，hfile数量会增长较快）hbase.hstore.compaction.min可以运行compaction的符合条件的最少hfile数量调大该值，可以减少hfile被compaction的总次数，进而减少Compaction操作处理的总数据量。hbase.hstore.compaction.max一次minor compaction所能选择的最大hfile数量调大该值，可以减少hfile被compaction的总次数，进而减少Compaction操作处理的总数据量。hbase.hstore.compaction.max.size超过该值得hfile将不会被选中做compaction大文件做compaction的性价比很低，通过适当调小该值，可以让较大的文件，避免被选中做compaction，减少IO占用。

本帖最后由 风吹宝宝PP凉 于 2017-11-28 21:09 编辑【Web前端性能概述】 对于B/S系统，访问一个网页，完成一件事务，最花费时间的过程并不是后端引用程序的处理以及数据库的消耗时间，而是前端花费的时间(包括请求、网络传输、页面加载、渲染等)。根据Web优化的黄金法则：80%的最终用户响应时间花费在前端程序上，而其中大部分时间则花在各种页面元素，如图像、样式表、脚本、Flash等的下载上。 根据Web前端经典的“2-5-8原则”，用户访问一个页面：1. 当用户能够在2秒以内得到响应时，会感觉系统响应很快；2. 当用户在2-5秒之间得到响应时，会感觉系统响应速度还可以；3. 当用户在5-8秒以内得到响应时，会感觉系统响应速度很慢，勉强接受或接受不能；4. 当用户在超过8秒后仍无法得到响应时，会认为系统失去响应而选择离开或再次发送请求。Web前端性能是一个B/S系统用户体验的重要参考指标之一，要进行Web性能测试则需要打开页面加载的黑盒，从用户输入URL开始到页面加载完毕这个过程中都经历了哪些步骤，我们需要重点关注哪些性能问题。 【Web前端性能问题分析】 分析Web前端性能之前，首先要打开页面加载的黑盒：(此处欠图)如上图所示，Web前端页面加载时间大体可以分成三个部分：1. Time to First Impression: 从用户在浏览器键入url开始到页面开始有反应为止。这其中包含了：I．DNS解析时间：浏览器进行郁闷解析所需要的时间II．TCP时间：客户端与服务器建立TCP连接的时间III．SSL认证时间：客户端与服务器之间进行SSL握手的时间IV．重定向时间(可选)：服务器页面重定向的时间2. Time to onLoad Event：从页面开始显示内容到浏览器开始出发onload方法这一时间段。浏览器只有在初始的文本和所有引用的对象都加载完成后才会触发onload方法；换句话说，这时页面所需的HTML，CSS，JS框架，图片资源等已经加载完毕。3. Time to Fully Loaded：从onload方法触发开始至完整的页面加载完毕这一时间段，这意味着onload函数以及相关的动态资源全部加载完成。 综上所述，Web前端性能测试需要重点关注的是Time to onLoad Event和Time to Fully Loaded。尤其是当页面加载：大图片，大JS或CSS文件，大型前端框架：AngularJS，TinyUI，ReactJS，RequireJS，前台JS工具库：JQuery，Dojo，BackBone，Echars，前台样式库：Bootstrap，以及异步加载的JS，CSS，HTML5等内容。 除了Web前端页面加载的性能，HTTP服务器所能承载的压力大小也直接影响着响应消息的返回时间，同样也影响Web前端页面的整体性能。所以，Web前端性能测试除了关注页面本身的加载时间外，还要通过模拟用户操作的端到端的方式对HTTP服务器进行压测，观察在大并发Web前端页面的整体性能。【Web前端性能测试工具】 目前业界常用的Web前端性能监控、调优工具很多，有代表性的包括：DynaTrace Ajax **，Yslow，Speed Tracer，FireBug，PageTest， Performance-Analyser，Chrome-Developer-Tool。这里选用：Yslow，Performance-Analyser和Chrome-Developer-Tool三个工具综合进行Web前端性能测试。而针对HTTP服务器的端到端压测，使用LoadRunner工具。 Yslow：Yslow是雅虎公司研发的针对静态页面的性能优化工具，它可以显示地将页面加载过程中各个种类文件的大小占比进行统计分析。 Performance-Analyser：Performance-Analyser是基于Chrome浏览器的扩展插件，它可以统计各阶段页面元素加载的耗时情况，并进行统计分析。