诊断.NET遗留问题

时间:2010-04-21 05:09:17

标签: c# .net profiling diagnostics legacy-app

假设您正在接管旧版.NET应用程序。用C#编写

您将用于评估申请健康状况的前5个诊断措施,概况分析或其他方面是什么?

我不仅仅关注诊断的“什么”部分,还关注“如何”。对于例如确实有必要评估应用程序的快速/最佳响应时间。 ...但有没有办法通过代码库的技术诊断来建立/衡量它,而不仅仅是获得用户体验反馈?

alt text http://chhs.gmu.edu/images_files/office_of_academic_outreach/images/s07-assessment-image.jpg

是的,肯定会有一些 awesome 工具用于此目的...如果你也列出它们会很棒。

5 个答案:

答案 0 :(得分:21)

答案 1 :(得分:1)

这些不是编码技巧或剖析建议,而是评估任何语言的程序健康状况的一般方法。按重要性排序

  1. 最终用户是否满意?
  2. 稳定吗?
  3. 它健壮吗?
  4. 快吗?
  5. 内存占用长期是否稳定以及我期望的是什么?
  6. 如果对所有这5个问题的答案都是肯定的,那么你就拥有了健康的应用程序。我认为1-3真的是最重要的。它内部可能不是很漂亮,也可能是右下角的丑陋,但如果它符合这些规格并且应该永远保持在传统模式(即小错误修正),那么它是健康的

答案 2 :(得分:1)

我建议围绕某些区域编写测试。我不是单元测试的忠实粉丝 - 虽然我最终写了很多。我更喜欢测试系统部分的系统测试 - 所以从域关闭,服务关闭,演示者关闭等不一定是整个系统,而是整个系统的一部分。如果您正在寻找效率,那么这些测试可以在代码周围运行StopWatch,如果花费的时间太长则会失败。

另一件好事是通过RedGate的 ANTs Profiler 或Jetbrains的 dotTrace 运行标准任务。它会告诉你什么花了时间和运行了多少次,这意味着你可以看到可以优化/缓存的位置。

如果您正在使用NHibernate,那么 NHProf 非常棒(或者我认为Ayende现在已经发布了 UberProf ,其中涵盖了更多数据库访问策略。)这将警告您任何愚蠢的数据库访问正在进行中。如果不使用 SQL Server探查器,可能会显示您反复请求相同的数据,但需要更多的努力来过滤掉垃圾。如果您最终使用它,那么您可以将其保存到数据库表,然后您可以以更智能的方式查询。

如果您正在寻找健壮性,那么使用的好处是记录策略 - 捕获所有异常并记录它们。这很容易使用 log4net 进行设置。如果你遇到某些你有点怀疑的点,也要记录。然后将其运行到服务器(我使用 kiwi syslog服务器,这很容易设置并且非常强大),它可以写入数据库,您可以对结果进行分析。我建议不要使用log4net的ADO.NET appender,因为它不是异步的,所以会减慢你的应用程序。

最后,根据应用程序的内容,如果您真的非常热衷于测试其健康状况,可以使用 WaTIN Winforms等效来测试前端。这甚至可能是一个长时间的测试,观察应用程序在使用时的内存/处理器使用情况。如果您不那么担心,那么 Windows性能分析器将允许您在使用时查看应用程序的各个方面。总是很有用,但你必须真正地去寻找有用的指标。​​

希望这有帮助。

答案 3 :(得分:0)

我要研究的前两个大项目是:

  1. 使用日志记录添加全局异常处理,以及搜索可能“吞噬”异常的任何异常处理,隐藏应用程序的问题(我认为还有一个Windows性能计数器,它将公开每秒的异常数量)这是你的应用程序抛出的)。这有助于发现应用程序中任何潜在的数据一致性问题。
  2. 添加一些性能监视和日志记录到应用程序可能正在使用的任何数据持久性和/或外部网络服务依赖项,例如记录数据库查询或需要花费超过X时间的Web服务调用。

答案 4 :(得分:0)

如果这与数据库交互,您应该了解磁盘I / O以及磁盘阵列/硬盘驱动器的碎片程度。对于MS SQL,请分析任何存储过程并查看表中的索引和主键。

你真的不需要这方面的工具,只需要审查计数器和与DBA交谈的繁琐工作。