from: http://www.infoq.com/cn/articles/scalability-panel
简摘：
问题1：许多人把性能和技术混为一谈。你们怎么回应这种误解呢？
…性能是服务于一个单独请求时的资源使用问题。可伸缩性是当要服务更多（或更大）请求时资源消费量如何随之增长的问题…
— 这里可能有一个笔误，应该不是“技术”，而是“可伸缩性”
问题2：当你碰到性能瓶颈时，你如何开始调查是什么导致了这一问题？
…通常是一个搜集观测资料（即，与许多人进行交谈）并缩小问题范围的过程..
…直觉（快速但不可靠，而且容易产生错误）和监测（需要预先的工作，但是这能让你随心所欲地分析问题)..
— 我们一般会做较多的log和监控
问题3：当处理Web应用的问题时，你发现什么工具最有用？
— 具体看是哪个层面的问题，如果页面的问题，yslow、httpwatch都是不错的工具
cgi/servlet方面，用log/jprofile
daemon，可以用gdb or strace/ gprof
问题4：当你有一个堆栈（或核心）问题需要诊断时，什么工具可以提供帮助？
…GDB和DTrace是用于C++的基础架构…
问题5：你认为像Yahoo!性能前十名等等这样的文章有用吗？领域或应用的可伸缩是个问题吗？
— yahoo性能前10名应该是yahoo performance 14 rules吧
问题6：实现可伸缩性和性能调优通常被看作是一种“救火”措施；目标是是立刻修正问题。你们在一个成熟的代码库上是如何跟踪性能衰退的？
…在eBay，所有项目都经过了严格的负载和性能测试阶段…
… 我认为这些都是在应用程序运行的时候才能检测到的。要确保一个应用被有效地划分并部署到真实环境的服务器上。如果一切正常，再把它部署到另一个服务器上，然后再是另一个…
— cool,灰度发布
…
不要试图在部署之前就捕获性能问题。你不可能重建真实环境中的条件，因此你不可能得到真实可靠的测量结果…
…监测。非常仔细的监测…
…适当地建立一个基线是很重要的：一个已知的好的性能表现。并且试图梳理出任何交织于最终用户功能瑕疵的性能问题…
问题7：那么捕获问题的真正重要的衡量标准是什么？
…取决于你的应用。任何事都有响应时间。找到你认为花了最长时间的地方，对它们进行计时…
…我们全体都同意最终的衡量标准是捕获了客户期望响应的那一个。通过响应，我们真正把整个系统中的其它元素汇集到了一起…
问题8：性能对应用程序的总体“健康”能起什么作用？
…性能是一个重要的部分，但仅仅是部分…
…性能绝对是基础…
…通常，我们都同意把性能不佳看做是一个大bug…
问题9：真正的性能和感知的性能之间的存在概念差异。对修复来说哪个更重要？
…感知的性能是最终用户感觉得到的，因此最应该修正…
— 就是响应率跟响应时间的区别，我们应该努力提升响应率，对于静态页面就是首屏显示时间;
…掩饰。感知的性能更重要。…
问题10：几乎每个星期，总有些人发布一个新的Web或应用服务器或数据库/ORM层软件。怎么看待这种情况？这是好事情——还是让Job调优更加困难了？
…我们专注于使用最好的工具组合——新的不见得就是好的…
…我要说的是在一个像eBay这样24×7都要运转的站点，我们在使用经证明是好的技术时需要非常小心。这是我们对公司的责任。在我们考虑引入任何新东西的时候，在我们考虑将其应用到站点之前都要经过非常广泛的评估…
问题11：那么在这一领域还有哪些内容经常被曲解？
…你只能通过使用软件实现伸缩性。“语言是不能伸缩的。框架是不能伸缩的。而架构是可以伸缩的。”…
…以我们的经验，修正性能和伸缩性问题需要对技术和问题领域两方面都有深入了解和经验。…
…经常被曲解的是性能和可伸缩性这两者间的区别…
— 在架构术语中，extensibility和scalability经常被搅浑