性能调试之总结
来源:互联网 发布:网络剧 有毒 第一集 编辑:程序博客网 时间:2024/06/08 14:27
1. 现象: 打开某页面取数据的时候, 有的数据比较快,有的数据比较慢
解决方案:原因是分析取数据的sql语句, 某一个子查询,取出的数据集中的数据量,
有时候非常大,有时候符合条件的数据量却很小, 把外围的条件调整到内层的
子查询的条件中, 把数据集的冗余数据直接在数据集中去除
在数据量较小的集合内再做数据的计算
2. 现象: 取出符合条件的数据较慢
解决方案: 原因是通过sql语句,取出数据之后,在内存中,再遍历数据集合,
这样一方面降低了数据库的访问性能,另一方面占用了Java虚拟机
的内存。导致性能下降。
把内存中的过滤条件调整到数据库端的sql语句中,
直接在数据端过滤数据,不在内存中,再遍历结果集,
而直接把符合条件的数据返回至页面,这样就较大的提高了系统的性能。
3. 现象: 保存数据较慢
解决方案:
因为保存之前,首先是把表格中的数据保存到javascript的内存变量之中,
然后发送请求至后台,返回状态之后,再刷新页面。再取数据,
导致页面延时,体现出保存数据较慢的状态。应该合理的利用业务规则,
保存之后,显示返回的状态, 不再刷新页面。
4. 现象:数据集的运算比较慢
解决方案:数组是性能比较高的数据集的保存方式。
/**
* src 源数组
* srcPos 源数组中的起始位置
* dest 目标数组
* destPos 目标数组的起点
* 从源数据复制的子数组的长度
**/
public static native void arraycopy(Object src, int srcPos,
Object dest, int destPos,
int length);
解决方案:原因是分析取数据的sql语句, 某一个子查询,取出的数据集中的数据量,
有时候非常大,有时候符合条件的数据量却很小, 把外围的条件调整到内层的
子查询的条件中, 把数据集的冗余数据直接在数据集中去除
在数据量较小的集合内再做数据的计算
2. 现象: 取出符合条件的数据较慢
解决方案: 原因是通过sql语句,取出数据之后,在内存中,再遍历数据集合,
这样一方面降低了数据库的访问性能,另一方面占用了Java虚拟机
的内存。导致性能下降。
把内存中的过滤条件调整到数据库端的sql语句中,
直接在数据端过滤数据,不在内存中,再遍历结果集,
而直接把符合条件的数据返回至页面,这样就较大的提高了系统的性能。
3. 现象: 保存数据较慢
解决方案:
因为保存之前,首先是把表格中的数据保存到javascript的内存变量之中,
然后发送请求至后台,返回状态之后,再刷新页面。再取数据,
导致页面延时,体现出保存数据较慢的状态。应该合理的利用业务规则,
保存之后,显示返回的状态, 不再刷新页面。
4. 现象:数据集的运算比较慢
解决方案:数组是性能比较高的数据集的保存方式。
/**
* src 源数组
* srcPos 源数组中的起始位置
* dest 目标数组
* destPos 目标数组的起点
* 从源数据复制的子数组的长度
**/
public static native void arraycopy(Object src, int srcPos,
Object dest, int destPos,
int length);
0 0
- 性能调试之总结
- JVM性能调试之jmap
- OD调试之总结
- ORACLE 性能调试 总结中ing
- 高并发性能调试经验深度总结
- android性能测试调试工具之dumpsys
- python调试技术之性能优化
- Spark性能调试之小分区合并
- 性能调试
- Linux下调试与性能分析工具的总结
- VC6.0之Debug调试总结
- vxwkrks6.6之tffs调试总结
- VC6.0之Debug调试总结
- 项目总结之调试和部署
- CCT之CAMERA TUNNING调试学习总结
- CCT之CAMERA TUNNING调试学习总结
- Android逆向之动态调试总结
- CCT之CAMERA TUNNING调试学习总结
- CXF
- MFC中的视图
- 责任链模式【Chain of Responsibility Pattern】
- 互联网和金融 在数据挖掘上究竟存在什么区别
- Life is beautiful
- 性能调试之总结
- bug修复个人总结
- 上传文件超过限制,造成长时间无响应的解决方案
- 在开发中,增加小的方法的一些个人感悟
- 二叉树的基本操作 C语言
- 读KentBeck的实现模式《英文版》 个人总结
- js 中的null和undefined相等的条件判断
- 结构小结
- 数据库重构『英文版』读后的个人总结