性能与缓存.pptVIP

TechEd 2002 ASP.NET: 性能与缓存 刘 灏开发合作部 微软(中国)公司 …与 J2EE的比较 CafeP.NET 比 Java优越的性能与效率 外包的电子商务方案 200,000 前端店, 每月五千万次访问 Java 实现非常复杂, 性能差 全部用.Net Beta1重建 性能提高100倍 1/5的代码量 一个星期 熟悉掌握Visual Basic? .NET 议程 性能概述 ASP.NET 性能最佳实践 逻辑/物理设计实践 语言/代码建议 COM 交互建议 数据建议 输出缓存 性能概述 性能是一项功能 设计时就考虑性能 不要在事后再加入性能! 在项目开发的整个过程中反复测试 两种量化Web性能的方法: 1) 机器吞吐率 (requests/sec) 2) 响应时间 (time to first/last bytes) 测试Web 性能 通过给服务器加负载来测试 使用多台客户端机器加载 免费Microsoft Web Application Stress 工具 测试多种场景: 模拟对站点的端对端场景遍历 测试单页性能 需计算的数值: 不同负载下的Request/sec (100, 250, 500, 750, 1000等等同时访问的客户) 辨明在可接受TTFB/TTLB 响应时间内的最大客户负载 关键的性能计数器 处理器, CPU % 使用率 低数值 = 受阻或者锁竞争 ASP.NET, 入列请求数 线性增长意味着服务器已满负荷 ASP.NET 应用, 每秒请求数 动态吞吐量 (应当一致) ASP.NET 应用, 总错误数 指示功能错误 (应当是0) ASP.NET 应用, 工作进程重启 指示严重功能错误 ASP.NET 性能最佳实践 最佳实践 “干净”的代码 而不是拼凑在一起的方案 更容易优化 更容易维护 遵循好的设计实践: 逻辑/物理设计 语言选择 COM 交互 数据访问 输出缓存 逻辑/物理设计实践 逻辑实践 推荐: 使用逻辑三层模型 页面 (.aspx) 和用户控件 (.ascx) 可重用类型 (组件) 放在 \bin 目录下 数据放在 SQL 数据库中 推荐: 为 Web Farm设计 不要假定 访问者永远会回到同一服务器 注意静态变量和应用状态 Web Farm会话状态 物理部署 推荐: 用同一个进程 应避免 (可能时): 对 XML Web 服务的同步调用 通过 DCOM的远程调用 使用XML Web 服务: 因特网上应用之间的通讯 不要用于应用内通讯 物理部署 推荐: 使用ISA 服务器 当需要 DMZ 安全域时: 只允许通过ISA访问 ISA 隧道通过DMZ 到达ASP.NET 减少进程转换 DMZ 性能指标 测试场景: 物理多机器部署 设计目标: 不能访问应用服务器 测试两种技术: ASP.NET 使用远程调用访问逻辑 ISA 前端访问包含页面和商务逻辑的ASP.NET服务器 三层部署性能 语言/代码推荐 代码性能 .NET 通用语言运行环境 (CLR) 运行性能大幅提高 运行时JIT 编译到本机代码 优化的垃圾回收器 简单问题: 代码分离还是混合? 没有性能差别 简单问题: VB .NET 或者 C#? 没有可觉察的差别, 然而… 语言选择 相同代码提供相同性能 …然而, 你可以编写不同代码: 语言建议 建议: 避免晚绑定 在 VB 和 JScript中 显式定义所有变量类型(Dim a as Long) 避免使用Object类型的晚绑定方法 %@ Page Language=“VB” Explicit=“true” % 要求声明所有变量类型(要求DIM) 依然允许晚绑定 %@ Page Language=“VB” Strict=“true” % 禁止使用任何晚绑定 语言性能指标 测试场景: MSN 主页 (大约 3000 行代码) 没有数据访问或者网络调用 COM或者.NET商务组件 测试3种技术: ASP/COM 实现 VB.NET早绑定 C#.NET早绑定 MSN 性能测试 COM 交互建议 COM 交互 建议: 尽量避免交互 最好将COM代码移植到.NET 可能会很昂贵, 尤其对于数组操作 “受管” 与 “不受管” 转换 如果你必须做交互重新设计API 少一些“啰唢” 多一些“块头” 注意单元线程组件 缺省情况 ASP.NET 使用MTA线程 损害STA 组件性能 注意所有VB6组件! 交互建议 标注页面让它运行在 STA 兼容模式: 如果组件是单元线程模式 (VB6) %@ Page ASPCompat=“true” % 影响 对 ASP.NET性能有负面影响 无法进行XCOPY部署 产生早绑定 .NET 包装 使用TL