“这个网页打开太慢了！”，对Web网站这样的抱怨是经常性的和普遍性的，尤其是自从Web应用开始逐渐替代桌面应用以来。虽然Web带来了全球交付这样的理想特性，但是也在性能层面带来了相应的挑战。
用户给了你一个“龟速”网页的url，那好，你该怎么做呢？网页打开慢的问题是源自于哪里？是一开始就是这么慢吗？是对所有用户都很慢吗？要解决网页打开慢的问题并且确保在一周后不会再次变慢，有许多诸如此类的问题需要得到解决。
虽然在网上可以搜索到一些性能优化的资料，但它们通常都是关于Jit、垃圾回收、SQL查询优化、ORM陷阱等这样一些特定主题的。考虑到实现优化的美好前景是诱人的，这里冒出了这样的一个问题：针对当前的性能问题，如何知道所选定的优化方法将会切实地产生好的结果？
无疑在这个工作中的某一环是有所缺失的。我们需要能可持续地找到性能问题所在的方法。通过使用该方法，我们能发现系统中较慢的部分，并有切实措施支持我们对性能问题的诊断。掌握了性能问题所在，我们就可以进一步地确定是否需要进行性能改进，并对利益相关者解释所有这一切。
对于所发现的上述性能问题，进行准确地甄别是更有效的处理方法。问题在一开始可能并非是一个网页加载慢的问题。在存在超时的情况下（例如负载均衡器可能几秒后才会为连接提供服务），完全无法被区分开这是一个死锁问题或是响应时间慢的问题，因为这两个问题导致了同样的结果，就是产生了超时。这需要数据去找到导致问题的真正原因。
为了阐明准确甄别性能问题的重要性，下面列举了一些导致Web应用响应慢的可能问题排查点：
还可以罗列出更多的性能问题排查点，这取决于需处理系统的复杂度和规模。在如此之多的系统组件都可影响性能优化问题的情况下，如何才能确诊性能问题呢？答案概括为一个词：数据。你需要来自于每个系统组件的、相关且有意义的数据。对于Web应用响应慢的问题，数据可以证明每个系统组件是对问题是有影响的还是完全无关的。
数据在手，就可以开始从上述列表中按你的思路去抽取问题排查点进行分析，这类似于在排序树中进行查找。每次在树中向下走一层，就越接近于性能问题的细节和实质，依次甄别性能问题是否存在于：
在这样树中逐层下行时，性能问题会变得越来越清晰。对于每个层次上的问题排查点，定位性能问题所需的数据必须要与对应的问题精度相匹配。这时有必要去使用性能分析工具或SQL执行计划这样的工具。
为有效地利用时间，很有必要重申一下Amdahl定律：
无论一个任务改进的程度如何，该任务中没有从改进中受益的部分限制了理论上的任务加速。
例如在一个Web请求中，假定需要100毫秒的服务器处理时间和5秒的SQL查询时间。即使你可以将服务器处理时间优化到低于1毫秒，但是这对整体响应时间的改进很小，也就是从5.1秒变成5秒。改进SQL处理所需的5秒时间是潜在收益最大的优化。
这种逐层厘清优化问题所在的自顶向下方法，对于局限在单一页面中的优化问题具有很好的效果。那么应用于跨越多个页面的优化问题上时效果又如何呢？例如，一些页面所存在的间歇性地打开慢问题，是由于子系统跟不上整体工作节奏，或是由于系统中存在某个再次重启可能就无法继续工作的老旧网络交换机。
这种情况下，侧重于应用的监控方法显示出它的局限性所在。这需要更多的软件层面和硬件层面上的指标，用于对系统中的每个组件进行评估。
在硬件层面，首先所能想到就是web服务器和数据库服务器，但它们只是冰山的一角。必须要识别和监控所有系统中的硬件组件，这包括：服务器、网络交换机、路由器、负载均衡器、防火墙、SAN等。
鉴于系统管理员的常规工作就是硬件监控，可能对于系统管理员而言上述的所有指标是显而易见的。但是这里有个重要警告：如果将这些硬件指标从软件指标中分离处理，那么从性能角度看所有这些硬件指标中的大部分是毫无用处的。换句话说，指标只有置于相应的环境中才能发挥最大作用。
例如，在一些情况下可能在数据库服务器上CPU占用率平均达50%是完全正常的，但是对于其它服务器而言这就是个定时炸弹。50%的CPU占用率，如果是在峰值时刻这意味着仍有很大空间去运行更繁重的任务。但如果是在闲暇时间段中而50%的CPU占用率频繁发生，这就意味着应用可能无法承受传入请求的突发峰值。
底线就是，为评估系统的健康度，CPU、内存和磁盘等全系统范围指标必须要与应用指标相关联。为给出更完全的系统健康状况视图，可以对请求吞吐量这样的应用指标和CPU占用率这样的系统指标进行可视化。
APM工具提供数据采集、数据存储和数据可视化这些基础性操作。通常是由代理负责采集数据并将数据发送给数据存储，并使用Web界面以集中在Web请求上的仪表盘方式对数据进行可视化。
APM可用于：
在这里给出了实例。
下面并非详尽地列出了支持对ASP.NET和IIS开箱即用的APM工具清单：
基础设施监控工具在主机层面采集指标，这可更完整地反映性能。这些指标是在硬件和软件层面采集的。
轻量级分析工具为特定Web请求提供了高层次的指标，并在开发人员浏览Web页面时就可提供实时反馈。这些工具可用于所有的环境类型中（包括开发环境、QA验证、模拟环境、生产环境等），因此非常适合于对特定页面性能的快速评估。
与相应的具有完全功能的分析工具相比，轻量级分析工具的本质差异在于它们并非附属于过程，这意味着在使用轻量级分析工具时无需操心它们所产生的开销。
在开发环境中，轻量级分析工具对当前正编写的代码提供了实时反馈。这对于发现N+1或响应时间慢等问题是非常有用的，因为响应时间总是显示在页面的一角上。
用性能计数器填补空白
Windows系统中的性能计数器（Performance counter）提供了硬件和软件层次上不同方面的指标。监控工具通常以性能计数器为报告方式，例如CPU和内存占用情况。但是通常会缺失一些有用的计数器，例如垃圾回收时间等。最切实可行的入门方法是使用基本列表并在迭代中添加必要的相关计数器。此外，使用perfmon对性能计数器进行实时地采集和可视化是可行的。在很多情况下，将用户定制指标或插件与APM工具进行集成也是可行的。
由于在很多应用中普遍地使用了数据库，持久层（即SQL数据库）常常成为性能的瓶颈。用于SQL监控的专业工具可提供资源使用指标，以及一些特定的指标，例如等待时间、每秒编译次数等，在这里仅列举几个。
在提供下列数据情况下，可以发现一些类型的问题并可对性能进行改进：
SQL监控工具包括：
所有子系统都需要在某种程度上进行监控。对于低吞吐量或非关键的系统，简单的数据采集和可视化即足矣。在此外的情况下则需要更加高级的、专业的监控。
当已确诊某个特定页面或代码段检测是响应慢的，代码分析工具可为性能问题鉴定提供最详尽的视图。代码分析工具还可为数据库查询和Web请求这样的外部调用提供了精准视图。
分析工具：
内存监控和垃圾回收指标有助于潜在问题的检测。但这些指标在显示了存在问题的同时，通常并未给出问题的所在。如果需要队内存和垃圾回收问题进行深入地探究，内存分析工具就可派上用场。
分析工具：
JetBrains dotMemory
RedGate Ants Memory Profiler
性能问题也可能来自于前端。当前这个问题十分常见，因为以JavaScript主导的单页应用的大量涌现。所有的主流浏览器都已嵌入了诸如代码分析和内存分析这样的工具。显示事件和请求的序列的工具有利于一眼就确定问题是源于前端还是后端。
工具：
页面分析工具
高层次客户端工具为发现并解决性能问题的提供了便利着手点。这些工具可以针对响应时间问题的产生根源提供高层次的视图，并给出一些相应的建议。例如Google的PageSpeed Insights就是这样的一个免费工具。
系统性能相关的因素和工具的数量是非常之多，这看上去似乎十分复杂。但是它们可以用一个词进行概括：数据。对系统有一个清晰的和准确的视图，这使得推理性能问题成为可能。这也使你可以在现场学习如何去解决性能问题，因为性能指标和图表将会引导你去发现到底是什么影响了系统性能。
你一直关注国内外哪些技术？
国内阿里人工智能、腾讯毫秒响应系统还是百度第三代Spider？还是国外Operator研究的购物AI、Facebook的实时数据流处理或LinkedIn用Apache Helix构建的云系统？12月北京，敬请期待100+位技术专家的合力筹备！点击“阅读原文”了解更多！
原文来自:聊聊架构
声明：所有来源为“聚合数据”的内容信息，未经本网许可，不得转载！如对内容有异议或投诉，请与我们联系。邮箱：marketing@think-land.com
分享
支持识别各类商场、超市及药店的购物小票，包括店名、单号、总金额、消费时间、明细商品名称、单价、数量、金额等信息，可用于商品售卖信息统计、购物中心用户积分兑换及企业内部报销等场景
涉农贷款地址识别，支持对私和对公两种方式。输入地址的行政区划越完整，识别准确度越高。
根据给定的手机号、姓名、身份证、人像图片核验是否一致
通过企业关键词查询企业涉讼详情，如裁判文书、开庭公告、执行公告、失信公告、案件流程等等。
IP反查域名是通过IP查询相关联的域名信息的功能，它提供IP地址历史上绑定过的域名信息。
苏公网安备 32059002001776号
