本文专门介绍了将近2年前举行的会议。 为什么写这样的长期事件？ 首先，我认为没有多少人知道这次会议。 其次，即使两年后，我对她的个人印象仍然如此强烈，以至于我忍不住分享它们。 第三，我确实很想写，但是目前尚不清楚如何做，因为我以前从未写过评论，这是我第三次尝试撰写本次会议。 而且，当然，我要感谢当时我所工作的Distillery公司以及我的主管Sergei Meshcheryakov出席这次会议的机会。
CMG国际
影响力会议每年由美国专家协会在提高IT系统性能方面举行。 自1980年以来，每年举行一次CMG会议。
该会议致力于性能工程和容量规划。 组织者，演讲者和会议参与者是IT或容量规划领域的高素质专家，其中许多人开始研究大型机，然后进入分布式系统，目前继续在行业的领先公司工作。 其中许多人的资格是惊人的。 与会的公司或其代表与监视或测试Dynatrace，NewRelic，Soasta，Jmeter，BMC，Moviri，BezNext等的性能有关。
在会议上，来自世界15个以上国家（主要是美国，加拿大和欧洲国家）的120份报告提交了。 从2016年11月7日至11日进行了5天。 运作方式如下：全体会议的报告从早上8.00开始，并继续在8个房间进行部门报告，直到晚上19.00，下午在午餐时间短暂休息。 会议的每个工作日都以一般自助餐结束，在此期间可以与所有发言人亲自交流并讨论所提交的报告。 很难选择要参加的报告，因为在平行会议中，感兴趣的报告同时在不同的房间中。
在本文中，我将简要介绍我最喜欢的报告。
1974年，美国改善IT系统性能的专家协会计算机管理小组设立了年度Abraham Michelson奖，以表彰他在评估系统性能方面的专业贡献。 传统上，该奖项是在CMG影响力会议上颁发的。
会议开幕并颁发了迈克尔逊奖AA
会议以独立顾问，软件与系统性能工程基础：过程，性能建模，需求，测试，可伸缩性和实践的作者安德烈·邦迪AA迈克尔逊奖开幕。
第一届全体会议以安德烈·邦迪的报告开始。 该报告的主要思想是调整永远不会导致性能提高。 根据该报告的作者，通过消除系统中的体系结构错误，可以最大程度地提高生产率。 我想你们中的许多人都是从亲身经历中了解这一点的。 在我的职业生涯中，我得出了相同的结论。 例如，如果团队在迁移过程中消除了先前版本系统的体系结构错误，那么从一个看似生产力更高的系统迁移到一个更为适度的开源系统可以提高性能。
实现可扩展性和性能>并发用户数达到1M
格林卡（Linds Lukas Sliwka）
对我来说，下一个有趣的演示是这些报告。 Grindr导演卢卡斯·霜（Lucas Cream）。 Grindr是一个在线约会应用程序。 卢卡什（Lukash）同时谈到了公司的转型，发展文化（他们转向了Scrum）以及系统的技术转型。 Grindr拥有250万用户，其中100万活跃用户。 转换之前的主要用户位于美国和加拿大，因为他们离开美国后，用户数量有所减少。
服务器和数据仓库也主要位于美国。 此外，该应用程序已经转移到主机上可能功能最强大的服务器上，该公司面临着优化和扩展的严峻问题。 从根本上解决了优化和扩展的问题-团队将整个项目从Ruby on Rails完全重写到了Scala，花了六个月的时间。 选择Scala的原因有两个：首先，可以编写性能良好的干净代码；其次， 其次，Java开发人员更容易被雇用，不像Node.js开发人员那样昂贵，他们全都在Facebook上工作。
Grindr有趣的经验证明，要成功进行开发，有时您需要一个新的体系结构。 接下来，对每个国家/地区的响应持续时间进行了分析，结果表明，响应时间越长，该国家/地区的用户越少。 开发团队优化了响应时间，使用CDN大大缩短了响应时间，并将数据仓库分配到了在欧洲，亚洲和拉丁美洲设有中心的云服务器上。 解决了性能问题之后，该应用程序的用户数量在全球范围内增加了。 该示例证明了响应时间短与用户数量之间存在直接关系。
该报告的第二部分专门针对团队管理。 Grindr在Scrum上工作。 团队的分离由产品完成，也就是说，每个团队完全负责用户的某些服务或产品以及用户获得的业务价值。 该公司是一家以指标为导向的公司，每个团队都有自己必须达到的指标和KPI。 完全没有中层管理。 公司结构扁平，团队决定需要做什么以及如何实现其目标。
卢卡什的报告在YouTube上 。
卢卡斯的采访在这里 。
有空吗？
第一银行Igor Trubin
有趣的是，作者在开始他的报告时就获得了第一资本银行决定成为一家信息公开公司的信息。 众所周知，银行通常不谈论技术和流程。 在他们的工作中使用，认为此信息是机密的。 但是，在现代世界中，为了争夺通常在Google和Facebook上工作的领先专家及其才能，银行需要更加开放。
该报告致力于评估系统可用性及其性能裕度的组合。 由于没有人需要无法使用的带宽。
伊戈尔（Igor）描述了一种特定形式，该形式可以用来衡量容量及其可用性。 他具有以下指标：跌落之间的平均时间，平均恢复时间，一年的停机时间等。 Igor提供了一个公式，您可以使用该公式来计算整个基础结构对用户的可用性。 您可以更详细地查看
他的报告 。
数字体验能力规划
艾米·斯派曼（Amy Spellmann）和理查德·吉马克（Richard Gimark）
物联网业务指标，IT指标和设施指标的规划讨论。
关于以下事实的报告：许多基础设施现在正在接近其带宽极限，以及物联网将在任何地方都可以工作时会发生什么。 对我来说，报告中最有趣的是它的规模。 也就是说，有专业人员为站点，组织进行规划，这是整个行业。 我们多久才会出现一次如此大规模的愿景？
基于BigData分析的企业绩效保证
鲍里斯·齐比特斯克（Boris Zibitsker）
鲍里斯（Boris）谈及大数据以及使用大数据的方法。 他确定了处理数据的以下阶段。 预测分析，因为企业必须基于当前数据做出决策。 时间就是金钱，多年来，什么都没有改变，除了现在时间变得更加昂贵。 如果相关的信息是昂贵的。
使用大数据集群可以使您及时进行必要的分析。 然后鲍里斯（Boris）描述了这些步骤。 两种主要方法是对流中的数据进行实时分析或从DataLake中收集数据。
该报告描述了在故障情况下使用大数据处理和机器学习算法进行RCA的方法，以及基于此类报告对系统的进一步行为进行预测的方法。
重要的一点是通过将实际行为与预期行为进行比较来验证结果的可靠性。
十大性能缺陷使在线组织损失了数百万美元
Craig Hyde，Rigor和Rigor
Craig介绍了影响网站性能的十大最昂贵的错误。 克雷格（Craig）引用的数据显示，平均而言，一家公司在等待用户1秒钟的时间里损失了1.02亿美元。 有趣吧？ 该公司对大约500个网站进行了分析，并汇总了导致性能下降的十大主要问题。 Craig关于使用缓存，CDN，使用压缩设置正确的图像分辨率的建议。 但是最主要的是测试发生了什么，事实证明，许多人认为他们使用了缓存，但是由于设置不正确，大约70％的内容可能没有被缓存。 Craig建议设置并保持性能基准，设置可达到的性能目标，测试并优化瓶颈。 测试工具网页测试，谷歌分析，pagespeed，严谨的免费报告。 对我来说，最有趣的是扩展站点上的图片，而尺寸使我无法对此进行评估，因此降低分辨率不会导致质量下降。
我找不到Craig的幻灯片，但这是该公司一名员工关于同一主题的
报告 。
冒险的生意
杰夫·布森（Jeff Buzen）
关于杰夫的几句话-他是哈佛大学的老师，三本书的作者，第一本书于71年出版，最后一本书于2015年出版-《重新思考随机性：随机建模的新基础》，
维基文章 ，
与Jeff访谈 。
报告建模和预测性能。 Jeff描述了在工作中对系统建模时出现的风险-建模风险，系统负载参数的风险，预测风险，应用程序风险，使用风险。 Jeff详细介绍了在对系统建模时可能出现的所有风险，并尝试预测需要多少资源以及需要哪种系统可用性。 选项，因为没有必要编写SLA-90％的请求在0.5秒内执行。 风险较小-队列长度少于时间的33x90％。 他的书就是关于那本书的。 尽管公式可能是正确的，但我们从古典数学中使用的预测并不总是能给出正确的适用结果。 预测在很大程度上取决于模型的假设。 更可取的是使用基于替代分析（AoA，替代分析）的预测。
我坐着想着-这与我的经验有多远-哦，我们的生产率还是2倍，这是什么呢？ 你是怎么发现的？ 嗯，这是一个高峰，系统中已经在堆积队列，让我们采用更大的服务器。 说什么 好吧，线是什么？ 好吧，在我们开始使用它们之前，系统完全崩溃了。 这是一种从系统模型（其他星球）开始的性能计划方法。
如何从BigData中获得价值？
Renato Bonomini，Stefano Doni，Moviri
接下来是
Moviri的研讨会。 Moviri是一家由米兰理工大学的教授创立的公司，在米兰和波士顿设有办事处，专门从事性能和吞吐量分析。 关于不仅收集大量数据而且从中受益是多么重要。 堆栈纱线，HDFS，猪，蜂巢，Spark，Zookeeper，Cassandra，Cloudera，Kubernetes。 该报告显示，随着容器中运行的系统性能的变化，工作变得更加方便。
Moviri邀请我去我的办公室，因为大约一个月后我去了意大利。 很高兴认识Stefano Doni，结识了Luca Forni，参观了办公室并讨论了与绩效分析有关的一切，从绩效分析开始，以顾问与客户团队沟通时遇到的问题为结尾。
Moviri博客 。
性能还是容量？ 针对不同任务的不同方法
亚历山大·吉尔古（Alexander Gilgur），Facebook
该报告对那些参与性能和带宽规划预测的人很有用。 亚历山大给出了每种情况下应使用的示例和方法。 一般而言，尽管能力和绩效的概念很接近，但应使用不同的方法进行预测，重点是工作的最终目标。 我们为什么要这样做？ 我们想了解我们需要多少设备以及我们要提供什么带宽，或者我们要预测系统性能。
在这里您可以阅读
Alexander的
文章 。
幻灯片 。
当您不知道从哪里开始时如何开始。
贾斯汀·马丁（Cerner）
关于为什么通常需要进行性能监视。 但事实是！ 许多人生活在没有监督的情况下，似乎一切都很好。 确实，许多人不需要它。 直到他们在中心发布有关其精彩站点的文章，然后人们才去找他们看看那里的内容。 或直到其他事情不会导致许多用户。
贾斯汀在报告中非常简单地讲述了可以开始做些什么。
90天的容量管理步骤
- 确定系统的高峰时间
- 检查项目的性能极限（系统已经停止处理请求并且性能开始下降的那一刻）
- 减少生产力损失
- 平衡需求-也许您可以将一些负载从高峰时段转移到繁忙时间。
Linkedin贾斯汀 。 幻灯片可以在关于会议的文章中看到，我将在最后发表。
大云基础架构中的动态负载平衡和连续服务交付
尤里·阿杜洛夫（Yuri Ardulov），RingCentral
Yuri描述了RingCentral从具有原始代码的整体到微服务的过渡。 整体代码的问题在于：难以更改配置，无法进行连续交付，难以实现所需的可用性指标，无法进行A \ B测试，仅对某些用户应用新功能的能力。 重新设计了系统，并在新设计中使用了容器和微服务，从而可以在线调整系统大小，无需更改配置即可更改服务版本。 在微服务体系结构中，分配了应用程序路由层，平衡层，服务层（不存储状态）。 进行Ops更改后，团队可以即时进行连续交付，系统的可用性从4个9增加到99.998。 扩充系统和部署新服务器所需的时间减少到4小时。
使用Lifecycle Virtualization避免成本，延迟和发行失败
CSC数字品牌服务Todd DeCapua
Tod的报告重点关注如何减少发行问题，关键思想是在测试程序时，考虑程序的整个生命周期非常重要。
4个关键组成部分：
- 用户-用户虚拟化模拟了实际系统用户的行为。
- 服务-必须对服务进行虚拟化，以便您可以从头到尾检查整个过程的运行情况。
- 网络-模拟网络运行状况。
- 数据-通过销售进行数据虚拟化，以模拟接近实际情况的应用程序调用。
根据我的经验，部署过程中的大部分错误是由于几乎没有人同时满足这4个条件，并且产品总是有没人希望看到的东西，这破坏了发行版。 根据用户数据和行为在销售中使用不同的用例非常重要。
这是Tod演示文稿中的一个示例：
Tod-
有关性能优化 ，性能测试及其解释的
书的作者。
这本书讲述了组织中的绩效测试文化多么重要，如果现在没有人这样做，如何将其引入。 给出了一些实践中的示例，描述了团队面临的任务，解决方案，团队选择的方法以及在实际系统中的后果。 , , .
Implementing Metrics-Driven DevOps: Why and How!
(Andreas Grabner), Dynatrace
DevOps , time2market. . – , , , , , .
– , - , . .
, – – , , , , 1 . , , . ?
? Agile Facebook – , .
, Scrum Agile! enterprise 3 ,
, , DevOps, . , . , , . performance advocate .
.
Performance Testing in New Contexts
(Eric Proegler), Soasta
2000, , . , TV , . , 20 , 50 . BlazeMeter (Jmeter), Selenium, Gatling, Grinder. , . (Tableau) , , . , . .
slideshare.
.
, « ». . , , , , .
. , , , . . .
Debbie Sheetz. BMC . . .
MathWorks, .
, , , , . , , .
.
CMG impact , .