XAF-由于try catch导致的性能问题一例

前几天在制作PMMS系统时,有天突然发现性能问题下降严重,发布到客户机后,每点击一个按钮要花5-10秒的时间,与本机的200-600毫秒差距很大。

经过多处优化后没有效果。

后来想起,最近增加的功能是“日志”功能,即,在每次点击按钮后,取得客户端的IP,机器名,并记录访问了哪些界面。

在取得机器名时,asp.net取得有几种方法,但是在不同环境下效果是不同的,asp.net客户端的权限是很小的,比如在局域网中,信任程度高一些,能取得到,而到了互联网中,却不能取到,由于在调试过程中将取机器名的语句中加了try catch,即,取机器名失败后,直接忽略了,try catch语句在出错时,是非常浪费时间的。

在发布后,没办法取得到机器名,所以报错,居然花了5-10的时间。最终先去掉了取机器名的功能。暂时解决问题。

时间: 2024-12-30 11:22:52

XAF-由于try catch导致的性能问题一例的相关文章

频繁分配释放内存导致的性能问题的分析

频繁分配释放内存导致的性能问题的分析 现象 1 压力测试过程中,发现被测对象性能不够理想,具体表现为: 进程的系统态CPU消耗20,用户态CPU消耗10,系统idle大约70 2 用ps -o majflt,minflt -C program命令查看,发现majflt每秒增量为0,而minflt每秒增量大于10000. 初步分析 majflt代表major fault,中文名叫大错误,minflt代表minor fault,中文名叫小错误. 这两个数值表示一个进程自启动以来所发生的缺页中断的次数

log4j导致的性能问题

问题背景 双十一零点时,有一个服务A(后文该服务都用A来代替)的tp99由平常的50ms左右突然彪到60000ms,导致调用端积累了几十W的数据,同时,也影响到了同一个docker上的其他服务.那为什么会出现这种问题呢,且看下面排查过程. 问题分析 1.将一台docker上其他服务都进行下线,同时将其他docker上的A服务进行下线,也就是说调用方只能调用到该docker上的A服务.这个时候发现除了A服务性能比较差,其他服务基本恢复正常. 2.将A服务的每一步认为耗时的地方都加上日志打印,包括内

导致Oracle性能抖动的参数提醒

前言 不知不觉,技术人生系列·我和数据中心的故事来到了第四期.小y又和大家见面了! 当您看到业务系统压测呈现以下波浪形的tps曲线时,你会怎么下手? 小y(中亦科技)今天要和大家分享的就是这样一个业务系统压测性能问题的分析和解决过程.这个问题困扰了客户相当长一段时间,幸运的是,小y通过远程在10分钟定位到了问题的原因并帮助客户最终解决了问题.需要说明的是,在这个CASE中,只调整数据库参数是不够的,还需要做其他分析和调整才可以解决问题.为了保持原汁原味,同时增加文章的趣味性,小y除了会继续坚持以

Oracle归档日志满导致数据库性能异常慢

这个问题遇到的时候,我没有查看告警日志,一直以为是数据库的锁阻塞影响了性能.知道查看日志才发现时归档日志已满.才导致这种问题的产生: Errors in file /DBBK/oracle/diag/rdbms/orcl/orcl/trace/orcl_arc0_28918.trc: ORA-19809: limit exceeded for recovery files ORA-19804: cannot reclaim 34764800 bytes disk space from 40705

线上nginx proxy buffer导致的性能问题

最近有一个项目访问量突然变大,但发现前端的nginx负载会很高,导致出现4xx和5xx的异常,响应时间也变长了.今天有时间,解决了一下.下面记录一下解决思路和方法.我们这个项目部署在azure.最前端是azure 的负载均衡器(lb),lb后面是2台nginx主机,型号是D2v3(2核8G).在我们实际使用中,一台nginx主机rpm达到30k,cpu,内存,网络都是没有任何压力的.所以一台主机支持的最大访问量应该远远大于30k.但今天这个项目rpm撑到3k的时候,系统负载就很高了.这个项目后端

Spark处理数据出现大量GC导致处理性能变慢的原因及解决方案

Spark应用程序处理的大数据多是运行于JVM上的,经常要面对GC优化问题.下面给出由于Linux系统原因导致的GC耗时异常的处理方式: 打开Spark的GC日志,在spark-env.sh文件中的SPARK_JAVA_OPTS参数上添加 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps 如果每次GC回收的量基本相同,但是在某一时间点,耗时异常大,这种情况下,有两种可能: 1.GC收集对象所在内存被swap了 2.GC线程进入IO等待状

oracle浅析导致数据库性能问题的常见原因

㈠ 不合理的大表全表扫描 详见:点击打开链接 v$session_longops视图记录了超过6秒的所有SQL语句        这其中绝大部是全表扫描的语句! ㈡ 语句共享性不好 常出没在OLTP,由于app没有合理使用绑定变量,导致大量重复的语句Parse,浪费大量的shared pool,使CPU利用率居高不下 ㈢ 过量的排序操作 有个原则:能不排序就不排序        特别是multi-pass,与事务设计.缺乏索引.优化器的选择等均有关系 ㈣ 大量递归SQL语句 由sys执行,以大量

论 try catch是否影响性能

在实际项目中,io,数据库,网络等等,不可避免会发生未知异常,try catch 可以有效的避免页面崩溃,网上有人说一个页四五个try catch影响效率,这里给出验证: 实例:100个线程,分别循环100次作为实验单位: package com.example; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.atomi

分区索引并行导致的性能问题

问题现象;生产环境报ORA-17144=statement handle not executed 然后我把sql抓出来手工运行一遍执行计划如下: ---------------------------------------------------------- Plan hash value: 644608605 ------------------------------------------------------------------------------------------