因此在java0中对于此项进行了重大改进.ppt

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 选择正确的堆大小： 43 垃圾收集将调整堆大小，使其占用空间保持在 40% 至 70% 之间 堆占用空间超过 70% 会引起垃圾收集过于频繁 ? 触发器增多便等于变慢 堆占用空间低于 40% 意味着垃圾收集频率不足，周期长于所需要的周期长度? 触发器收缩等于变慢 因此，应将堆最大容量设置成比应用程序最大占用空间大 43% 最大占用空间 + 43% 意味着占用空间为整个堆的 70% 堆最大大小 = 占用空间 + (0.3 x 堆最大大小) (0.7 x 堆最大大小) = 占用空间堆最大大小 = 占用空间 / 0.7堆最大大小 = 占用空间 * 1.43 例如，对于 79 MB 占用空间，请指定 100MB 最大堆大小 = 70 MB + (0.43 x 70 MB)  = 70 MB + 30 MB  = 100 MB * 解决 Java 运行时问题 添加更多资源到 Java 运行时 – Java 堆：增加 Java 堆大小 –“原生”堆：升级到 64 位或减少 Java 堆大小 降低内存需求 – 减少 Java 应用程序占用空间 * 增加后的 Java 堆大小 * 对垃圾收集停顿时间的影响 减少： 垃圾收集所用时间 59% 然而，这仅占全部时间的 4.84% * 页面响应性能基准测试：基线 页面性能 PlantsbyWebSphere  * 页面响应性能基准测试：删除的分页 页面性能 PlantsbyWebSphere  * 页面响应性能基准测试：增加后的 Java 堆大小 页面性能 PlantsbyWebSphere  * 页面性能提高 PlantsByWebSphere 0.4% servlet_ShoppingServlet 0.0% servlet_ShoppingServlet{2} 33.2% Shopping{1} -0.6% Shopping{4} 4.5% Shopping_1_1 2.9% Shopping_2_2 0.1% Shopping_2_3 2.1% Shopping_2_4 14.2% Shopping_2_5 8.2% 页面性能提高 0.6% 至 33.2% 无异常值：0.0% 至 14.2% 总增长只有大约 4% 对总体页面性能的影响相对较小 * Java 应用程序 典型资源限制： – 内存：缓存不足影响应用程序吞吐量和响应速度 – CPU：线程不足会限制可伸缩性 – 同步：同步资源限制应用程序的可伸缩性和吞吐量 – I/O：I/O 阻塞限制吞吐量和响应速度 难以诊断 解决的成本很高（或不可能） * Java 应用程序 CPU 使用 Java 方法过多使用 CPU 可突显潜在优化范围 – 不必要地过多调用代码 ? 通过事件驱动的模型很容易完成 – 算法不是最高效的 ? 如果开发时性能不是重点，则很容易完成 修复受限于 CPU 的应用程序需要知道运行的是什么代码 – 识别出适合于优化的方法 ? 对应用程序不会用到的方法进行优化是在浪费时间 – 识别出哪些方法所花费的时间超过预期 ? “为什么花费这么多时间在这个微不足道的方法上?” * Java 应用程序同步 吞吐量不会随负载而线性增加 CPU 吞吐量限制仍然很低 – 无法伸缩 – 并非所有 CPU 都被利用 – 吞吐量和响应速度方面的限制 为了应用程序的正确性，线程需要彼此同步，而此处存在瓶颈 – 由于大量线程同时需要同步资源而导致 – 由于拥有资源的线程长时间占用资源而导致 – 或两者兼而有之 * 运行情况中心：应用程序方法 CPU 使用 /DetailsPage.aspx?Page_Id=42 * 运行情况中心：应用程序同步 * ShoppingServlet.deliberateSlowMethod() * 页面响应性能基准测试：基线 页面性能 PlantsbyWebSphere