可伸缩面板
容易低估扩展和性能调整经验所具有的价值。 两者都是“以后”或“当我们真正受欢迎时”的问题。 早期的风险投资公司从来都不希望立即花费这笔钱，大型公司通常不能足够快地做出React以实施所需的更改。 急需一支多学科的团队，这很快成为解决政治和工程难题的难题。
但这从来没有超出我们的意识-在过去的QCon会议上，“您一直想知道的架构”会议不堪重负-正确的是-我们渴望了解有关如何“大家伙”做到了。
在InfoQ.com的虚拟面板中，我们邀请了一些最大的公司和周围项目的规模和绩效方面的杰出人物，让我们成为实现我们其他人梦dream以求的结果的秘密。
我们的参与者包括Twitter公司前建筑师，Starling消息队列Ruby宝石的首席开发人员Blaine Cook。 Blaine在“如何扩展Ruby和Rails”对话中一直是积极的声音，并且在现场拥有丰富的经验。
他加入了eBay市场架构小组的杰出建筑师Randy Shoup。 自2004年以来，他一直是eBay搜索基础架构的主要架构师，并且是必发（Betfair）首席技术专家Matt Youill。 在过去的6年中，他领导了必发技术的大部分架构。 最近，他开始与必发先进技术集团合作研究长期的高级项目，包括战略，研究和特殊项目，其中包括Flywheel技术。
为了召集参与者，我们请Rails性能工具专家FiveRuns权衡一下。他们的整个工程团队下午坐了下来仔细考虑他们的答案-几乎为我们提供了一个小组内部的小组！
问题1：许多人将性能和技术混为一谈。 您将如何应对这种误解？
兰迪 ：我同意，讨论扩展问题时，与任何特定语言或框架无关，都具有很大的价值-无论实施策略如何，模式都是相同的。 不过，首先，请确保我们区分性能和可伸缩性。 性能与用于服务单个请求的资源有关。 可伸缩性是关于必须服务更多（或更大）请求时资源消耗的增长方式。
它们是相关的，但不是同一件事:-)。 幸运的是，许多改善一种方法通常会改善另一种方法。 但是在边缘，最快的系统可能不是最大的可扩展性，反之亦然。
FiveRuns ：我们关心性能，可伸缩性和可用性。 我们将性能定义为一个或多个操作完成的速度，例如响应时间，每秒处理的事件数等； 同时具有可扩展性-这是应用程序可以很好地扩展以应对更大的使用需求（例如，用户数量，请求速率，数据量）。
问题2：当您开始遇到性能瓶颈时，如何开始调查造成这种情况的原因？
马特 ：每个问题都不尽相同，但我想通常是这样一种情况：收集观察结果（即与很多人交谈），然后缩小问题的范围-通过证明仍在执行的操作，您将能够找出问题所在。 t。
有几件重要的事情要牢记。 确保这是重要的瓶颈。 例如，在IO受限的应用程序中，避免低效的处理器使用可能无关紧要。 重要的是，从生产，而不是分期，开发或其他地方获取您的观察结果。 试图在人为的环境中重现问题并收集信息只会产生人为的见解。
Blaine ：直觉（快速，但不可靠且容易出错）和监视（需要前期工作，但做得好会使您任意解决问题）。 人们谈论测试驱动的开发，但是扩展必须是度量驱动的开发。
诸如JMeter和Tsung之类的工具可让您模拟负载，但要承受一切。 如果您花费很长时间（过程长短不一，以及谁在构建测试）来构建非常仔细的测试，则可以获得更好的数据。 不过，没有什么比真实的流量大。
兰迪 ：通常我们从发现问题的位置开始，然后从那里开始进行工作。 在应用程序堆栈的各个级别上进行的监视/遥测越多，越容易。 这也有助于建立一个由多学科组成的团队来研究问题
问题3：在处理Web应用程序问题时，您发现哪些工具最有用？
FiveRuns ：在浏览器级别，firebug是我们选择的工具，因为它可以洞察用户对单页性能的感知。 我们还喜欢ab和httperf进行一些自动的负载测试，因此我们可以从firebug中获得会话级计时和页面级计时。
马特 ：我们将现成的工具和定制工具混合使用。 现成的工具很棒，但是现成的工具意味着它们是通用的。 他们不了解对您的应用程序很重要的特定指标。 在必发Web应用程序的上下文中，这可能是例如将特定页面的请求率和类型与相关业务事件（例如足球比赛中即将或即将得分）相关联。 通用工具没有“足球比赛”选项。
布莱恩 ：神经节很棒。 虽然Nagios或Zabbix（例如）会告诉您什么时候东西坏了，但只要使用一些工具，您就可以让神经节为您提供任何东西。 对于MySQL，Innotop +缓慢的查询日志很有帮助。 使用mysql微秒日志记录补丁，查看所有耗时超过1ms但少于1s的查询正在做什么。
Randy ：我必须就日志记录达成共识-我们拥有的最有用的工具是我们的监视框架，我们的应用程序服务器使用该框架来记录我们所做的每个操作的调用/事务处理时间-总体URL执行，嵌套数据库访问，嵌套服务调用等。这使我们可以远程诊断大多数生产问题，而无需在任何地方附加调试器。 我们还保留了这些日志的可搜索历史记录，可以追溯到很多种方式，可用来比较以前和当前的性能以及一段时间内的趋势。
问题4：当您需要诊断堆栈（或核心）问题时，哪些工具可以帮助您？
Randy ：对于基础结构的C ++部分，绝对是GDB和DTrace。 核心或pstack是有价值的工具。 对于包含绝大多数eBay基础结构的Java，我们使用跟踪和各种Java调试器。 但是，调试器不应该是您的第一个工具。 它应该是你的最后一个。 生产代码需要足够的工具来远程诊断问题。
马特 ：我们有很多魔术！ 我们使用各种工具来重新创建问题并对其进行调试（包括堆栈问题）-Visual Studio，Eclipse，WinDbg，cdb，Purify，Fortify，dtrace和为我们的体系结构构建的许多自定义内容。
问题5：您认为Yahoo!之类的文章吗？ 性能十佳等有用吗？ 扩展域或应用程序问题？
布莱恩 ：是的； 都。 在某些时候，扩展已从域问题转移了（即，如果您不使用内存缓存或等效缓存（基于分布式哈希表和基于内存的缓存），则您仍处于“域”区域。如今，扩展静态内容基本上是微不足道的，仅需要资金和公司的良好社会组织。
FiveRuns ：我们认为资源类似于Yahoo! 性能文章很有用。 我们确实认为将应用程序体系结构与问题域相匹配是至关重要的-实际上，我们所有人都认为问题域定义了对软件系统质量的约束。
换句话说，我们都希望问题域能够定义对性能，规模，可用性等的期望。当然，在这些（和其他）质量之间需要权衡取舍，例如功能和上市时间，可以有效地修改问题域。
Matt ：当然，这些文章中所有有用的东西。 话虽这么说，生产高质量（绩效）的系统是相对可以实现的-我从未见过的关于如何保持质量的好建议-也就是治理部分。 看来IT系统注定要开始发亮，生锈，破碎，然后重新构建。 甚至要确保他们至少时不时地获得新鲜的油漆是非常困难的。
Q6：缩放和性能调整通常被视为消防活动； 现在就解决问题。 您将如何跟踪成熟代码库上的性能下降？
兰迪 ：在eBay上，项目经历了严格的负载和性能测试阶段。 我们使用它来检测和解决潜在的性能问题，然后再将其放入站点。
Matt ：我们要经历一个不同的过程-我认为只有在应用程序上线后才能真正检测到这些问题。 确保有效地对应用程序进行分区，然后将其部署到实时环境中的一台服务器上。 如果看起来不错，请将其部署到另一个，然后再部署，依此类推。 确保您在有效的监视和测量基础结构上进行投资，以在推出过程的早期发现性能问题。
在部署之前，请勿尝试抓住性能问题。 您将无法重新创建实时存在的条件，因此，您将无法获得现实可靠的测量结果。
布莱恩 ：是的，监视。 有仔细的监视。 我提到监视了吗？ 注意缓慢。 当您看到回归时，请回顾您的变更日志。 应该很容易发现，因为您经常进行增量部署，对吗？
FiveRuns ：我们要补充一点，正确建立基准很重要：已知的良好性能。 并尝试从最终用户那里找出编织到功能缺陷中的任何性能问题-有时似乎仅是功能性的缺陷实际上也包含性能问题。
问题7：那么要捕获哪些指标真的很重要？
兰迪 ：影响您业务的指标（例如页面权重，用户响应时间）以及限制您的指标（例如内存，CPU，网络带宽等）。 您可能会想到，eBay基础架构的某些部分受CPU限制，其他部分受内存限制，而其他部分则受I / O约束。 当然，墨菲定律保证您没有密切跟踪的一个指标将成为您的目标！
Blaine ：取决于您的应用程序。 任何涉及延迟的东西。 找到您认为可能花费最长时间的位置，对它们进行计时，如果总数与您测量的位数明显不同，请找到它们。 页面加载时间只有在您降低到约250毫秒以下时才重要。 在那之后，您的用户（通常）无法分辨出差异，而任何优化都是性能（例如api）和成本优化。
了解集群的外观； 如果您的产能过剩，请获得更多的产能和期限。 故事结局。 去买更多的机器。 停止阅读本文，然后购买更多机器。 如果只是容量问题，而您的应用程序并不完全烂（在性能方面，您已经调整了mysql等），请购买机器。 您可以使其速度更快并在以后节省金钱，但与此同时，购买机器意味着您将减轻很多压力，并为自己进行调整的呼吸空间。
马特 ：请确保这对您的业务至关重要，并确保您进行的衡量有意义。 除非您知道当时正在执行什么业务功能，否则CPU测量是没有意义的。
FiveRuns ：我们都同意，最终指标是捕获客户对响应期望的指标。 通过响应，我们实际上是指整个系统中所有其他元素的集合。 例如，gmail比其他电子邮件服务更快地发送电子邮件； 因为此“响应”（即从发送邮件到在gmail中看到邮件之间的时间）符合用户期望，所以其他技术指标无关紧要。
问题8：性能如何反映应用程序的总体“健康状况”？
Matt ：性能是很重要的一部分，但只是一部分。 虽然过时了，ISO 9126是开始制定测量系统标准的好地方。
“健康”是一个有趣的概念。 在医学中，不测量人体单个细胞的性能，而是测量大的聚集“生命体征”，例如脉搏，温度，血压和呼吸。 大型系统应该以类似的方式进行测量-单个服务器的内存使用量没有整个系统在线用户数有用。 每个大型系统都需要一些关键的生命体征。
兰迪 ：性能绝对是根本。 性能差直接反映在基础架构的成本以及用户体验的质量上。 两者都直接进入底线。 性能未达到预期的应用程序不会“完成”，其方式与缺少所需功能的应用程序完全相同。
FiveRuns ：总的来说，我们所有人似乎都同意，我们一直认为性能不佳是一个大错误，而作为一个大错误，我们也开始担心存在一个大错误的地方可能还会有其他大错误。 因此，我们认为健康状况取决于用户/所有者的体验。
但是，有一些反例。 例如，对于旨在为小规模受众提供一些新颖功能的Web应用程序，可伸缩性问题将不会计入该应用程序的“运行状况”。 另外，如果像gmail这样的工业强度应用程序具有一致的性能（或规模或可用性）问题，那么这将对应用程序的“运行状况”产生负面影响。
布莱恩（Blaine） ：有时应用程序运行缓慢，因为其中涉及复杂的事情，因此无法加快速度。 这成为一个相互作用和负载能力的问题。 有时，应用程序运行缓慢是因为您的代码不正确，并且随着负载的增加，所有内容都会减慢（特别是与触发锁的代码（例如sql锁或nfs锁或任何形式的分布式锁）相关）。
问题9：有一个概念，即实际绩效与感知绩效之间的差异。 修复哪个更重要？
FiveRuns ：感知性能是最终用户所感知的，因此这是最重要的修复方法。 但是，我们认为感知的性能更难衡量-即它取决于上下文，并且我们可能无法始终获得与感知者相同的上下文，并且我们可能无法控制构成其上下文的所有内容。
布莱恩 ：假的。 感知性能胜出。 使用后端排队减轻工作负担，向用户展示他们的期望，并弄清如何过滤到应用程序的其他方面。 使用针对廉价请求的javascript轮询，而不是提供单个昂贵请求。 在请求开始时并行执行昂贵的事情，在完成请求之前先收集它们。
马特 ：我不同意-真正重要。 与其看起来像是某种东西，不如说是事实。
兰迪 ：我都坚持：-)。 感知性能会影响用户体验，而您所说的真实性能会影响成本。 最终，这是一个最大的业务决策，这是当前最大的痛点，因此相对优先级将取决于。
问题10：几乎每周都有人发布新的Web或应用程序服务器或数据库/ ORM层。 这一切怎么办？ 这是好事吗？还是会使调校工作变得更加困难？
布莱恩 ：我用阿帕奇。 它有它的缺点，但是效果很好。 我使用MySQL。 它有它的缺点，但是效果很好。 没有任何应用程序可以解决所有问题； 其中一些使事情更容易理解和/或修复，其中一些确实更好，但其中一些使事情更难以调试和/或修复。
对于数据库，拥有DHT并不能为您提供索引。 您需要一个分布式索引，只是还不知道。 BigTable和相关的开源项目不是分布式索引。 MapReduce不是分布式索引。 找出您的分布式索引是什么样子，然后进行构建。
马特 ：很好，可能会更好。 每个类别中的大多数产品大致相似。 看到不断的创新是件好事，但是看到每个类别的产品更少，而完全不同的类别有更多的数量和多样性，将是很好的。
FiveRuns ：作为此类产品的生产商，我们对这个问题有既得利益！ 我们认为这是一件好事-它激发了创新并向我们介绍了要考虑的新想法。 但是我们致力于使用最好的工具组合-新的不一定意味着更好。
兰迪 ：选择是好的。 选择哪种方式取决于您。 追逐当下的风味并没有固执地坚持对您不起作用的东西更有成效。 我要说的是，在eBay之类的24x7全天候运营中，我们需要格外小心，以利用久经考验的真实技术。 这是我们对社区的责任。 每当我们考虑引入新内容时，我们都会进行广泛的评估，然后再考虑将其发布到网站上。
问题11：那么在这个空间中还有哪些常被误解？
马特 ：好吧，我想一件令人失望的事情是，当一个好主意被商业化或更具体地概括时，该主意的质量下降。 以数据存储为例-构建既快速又可以存储大量数据的软件非常困难。 显然，要实现商业化（即拥有大量潜在客户），可以同时做到这两个都是不错的选择，但这意味着这最终是一个折衷方案，既不算快也不算大-尽管供应商的陈述不正确！
这并不是说这是普遍的，或者永远都是这样。
Blaine ：您可以通过使用软件进行扩展。 “语言不缩放。框架不缩放。体系结构缩放。”
缩放是一个社会问题。 您的业务，操作人员和工程人员之间的协调至关重要，如果不成功，那么扩展工作将失败。 如果您的公司不了解为使增长成功而进行协调的必要，那么您将失败。 YouTube通过正确地利用社交功能来进行扩展。 他们购买了服务器，制定了容量计划，并确定了带宽。 他们选择了一件事情，做得很好，并决定作为一个规模扩大的组织，这并不是在天才工程师的努力下发生的神奇事情。
你会失败的。 快速学习，永不失败。 没关系。 不要构建可扩展的服务，因为您可能会发现交互设计是错误的，并且您将不得不回头再做一次。 同时，没有按比例构建的人可能已经正确地进行了交互设计，现在比您提前6个月到一年。
FiveRuns ：性能改进/可伸缩性改进是“容易的”-固定性能或可伸缩性并不总是像从外部看起来那样容易-容易受到批评，要在给定所有约束的情况下实际解决起来要困难得多。 根据我们的经验，解决性能和可伸缩性问题需要技术和问题领域的深度和经验。
Randy ：性能与可伸缩性之间的区别；-)
可伸缩面板
1978
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
