急!求助性能问提

eric_qp 2004-12-25 10:39:21
小弟最近遇见一个性能方面的难题,希望各位大虾不吝赐教。
下面是我们遇见的问题的简述:


我们用的平台是Oracle+Oracle Applicaion Server+Solaris。
我们的应用其实很小。在访问最频繁的时候也最多1000个用户左右,
用户的操作很简单,填几个页面的参数(参数总共不多于50个,这些参数的值的累计不会超过2K),
可能存在着一些的查询,查询的规模比较小
上传一些文件,文件数不多于5个,文件大小总共一般都在1M以下


我们开发的几个应用开始是用的Jsp+JavaBean+Oracle模式。
结果,应用的性能很低。在最繁忙的时候,20分钟,甚至10分钟都上不去了。
在到达性能瓶颈时,我们发现是中间件即Oracle Applicaion Server的相关应用的OC4J实例宕掉了
(http server组件即Apache模块没有问题,静态网站速度还可以)。
而系统和Oracle没有问题,
cpu和内存使用率平均都在30%以下。
我们的系统是sun公司的V880服务器,配置较高,相对于我们的应用应该是错错有余。


通过监控,我们发现在系统出现问题时,数据库的连接将近20000个
(我们以前没有这方面的开发经验,所以开始是用JDBC或JavaBean直接连接数据库进行操作,所以数据库连接数会特别高)。
我们以为是数据库连接数太多造成性能瓶颈,最后,我们通过在Oracle Applicaion Server
中配置数据源,在程序中通过Naming.lookup来查找数据源获取数据库连接的方式来操作数据库。
结果是数据库的连接数下去了,在到达性能瓶颈时,数据库的连接不到200个。
但问题还是没有解决,这次,中间件即Oracle Applicaion Server的相关应用的OC4J实例还是会较快宕掉,
但在OC4J实例宕机的之前,Oracle的数据库进程会超过150个,使整个系统不能够再连接Oracle了。


另外,由于我们有时经常修改服务器上的JSP程序,在很多时候会出现在访问相关JSP程序时,发生内存不足,无法编译的问题。

以前我们部署的应用,是在建立的一个OC4J实例下创建了一个WEB CONTEXT,然后,以后开发、编写的所有应用都直接在上面建立
子目录来进行的。最多的时候在目录下面有近3000多个JSP文件。

后来,我们按照应用的分类重新部署了这些应用,发现,性能还是没有显著改善。

我们的数据库,中间件以及系统在安装后的各种配置参数最初没有进行特意的优化,
前一段时间对Oracle Applicaion Server相关参数进行了配置,发现,性能还是没有显著改善

我们的应用的性能问题是Oracle Applicaion Server中间件、Oracle数据库、solaris的参数配置问题,还是程序开发的方式问题
还是部署的问题,还是程序本身实现的思路、方法问题,还是各种问题和因素的组合
各位大虾有没有关于开发JSP应用的成功经验,对我们的问题有没有建议,有没有各种参数配置问题、程序开发的方式、部署等方面的
建议或文档,还请各位大虾不吝赐教

我的信箱是eric_qp@sina.com



...全文
60 2 打赏 收藏 转发到动态 举报
写回复
用AI写文章
2 条回复
切换为时间正序
请发表友善的回复…
发表回复
eric_qp 2004-12-29
  • 打赏
  • 举报
回复
谢谢,我再试试
yy2008vv 2004-12-25
  • 打赏
  • 举报
回复
这种问题只能有工具去测,推荐性能测试工具Optimizet
检查程序是否有地方没有释放数据库连接,特别在容易发生异常地方
200多M 作者梁敬彬、梁敬弘 上篇 开启惊喜之门——带意识地学Oracle 第1章意识,少做事从学习开始 2 1.1 选择先学什么颇有学问 2 1.1.1 梁老师课堂爆笑开场 2 1.1.2 看似跑题的手机分类 4 1.1.3 学什么先了解做什么 5 1.2 善于规划分类才有效果 7 1.2.1 分类与角色密切相关 7 1.2.2 角色自我认识有讲究 9 1.3 明白学以致用方有意义 11 第2章震惊,体验物理体系之旅 13 2.1 必须提及的系列知识 13 2.2 物理体系从老余开店慢慢铺开 16 2.2.1 老余的三个小故事 16 2.2.1.1 顾客的尺寸 16 2.2.1.2 有效的调整 17 2.2.1.3 记录的习惯 18 2.2.2 体系结构原理初探 20 2.2.2.1 从一普通查询SQL说起20 2.2.2.2 老余故事终现用心良苦23 2.2.2.3 一起体会Oracle代价 27 2.2.3 体系结构原理再探 30 2.2.3.1 从一普通更新语句说起30 2.2.3.2 体系结构中提交的探讨34 2.2.3.3 劳模的评选 38 2.2.3.4 回滚的研究 40 2.2.3.5 一致的查询 43 2.2.3.6 一致读的原理46 2.2.3.7 实践的体会 49 2.3 体系学习让SQL性能提升千倍 65 2.3.1 一起探索体系学习的意义 65 2.3.1.1 同学们不知所学何用 66 2.3.1.2 实际上大有用武之地 67 2.3.2 单车到飞船的经典之旅 70 2.3.2.1 未优化前,单车速度 70 2.3.2.2 绑定变量,摩托速度 72 2.3.2.3 静态改写,汽车速度 74 2.3.2.4 批量提交,动车速度 75 2.3.2.5 集合写法,飞机速度 77 2.3.2.6 直接路径,火箭速度 78 2.3.2.7 并行设置,飞船速度 79 2.3.3 精彩的总结与课程展望 80 2.3.3.1 最大的收获应该是思想80 2.3.3.2 老师的课程展望与规划81 第3章神奇,走进逻辑体系世界 84 3.1 长幼有序的逻辑体系 84 3.2 逻辑体系从老余养殖细细说起 85 3.2.1 农场之体系逻辑结构 85 3.2.2 农场之BLOCK漫谈89 3.2.3 农场之区与段 91 3.2.4 农场之表空间的分类 93 3.2.4.1 表空间与系统农场93 3.2.4.2 表空间与临时农场93 3.2.4.3 表空间与回滚农场94 3.2.5 逻辑结构之初次体会 94 3.2.5.1 逻辑结构之BLOCK 94 3.2.5.2 逻辑结构之TABLESPACE 95 3.2.5.3 逻辑结构之USER 97 3.2.5.4 逻辑结构之EXTENT 97 3.2.5.5 逻辑结构之SEGMENT 98 3.2.6 逻辑结构之二次体会 100 3.2.6.1 BLOCK的大小与调整 100 3.2.6.2 PCTFREE参数与调整 101 3.2.6.3 PCTFREE与生效范围 102 3.2.6.4 EXTENT尺寸与调整 103 3.2.7 逻辑结构之三次体会 104 3.2.7.1 已用与未用表空间情况104 3.2.7.2 表空间大小与自动扩展105 3.2.7.3 回滚表空间新建与切换109 3.2.7.4 临时表空间新建与切换111 3.2.7.5 临时表空间组及其妙用114 3.3 课程结束你给程序安上了翅膀 117 3.3.1 过度扩展与性能 117 3.3.2 PCTFREE与性能120 3.3.3 行迁移与优化 123 3.3.4 块的大小与应用 124 第4章祝贺,表的设计成就英雄 131 4.1 表的设计之五朵金花 131 4.2 表的特性从老余一家展开描述 132 4.2.1 老余一家各施所长 132 4.2.2 普通堆表不足之处 132 4.2.2.1 表更新日志开销较大 133 4.2.2.2 delete无法释放空间 136 4.2.2.3 表记录太大检索较慢 139 4.2.2.4 索引回表读开销很大 140 4.2.2.5 有序插入却难有序读出143 4.2.3 奇特的全局临时表 146 4.2.3.1 分析全局临时表的类型146 4.2.3.2 观察各类DML的REDO量 147 4.2.3.3 全局临时表两大重要特性 149 4.2.4 神通广大的分区表 153 4.2.4.1 分区表类型及原理155 4.2.4.2 分区表最实用的特性 165 4.2.4.3 分区索引类型简述176 4.2.4.4 分区表之相关陷阱177 4.2.5 有趣的索引组织表 184 4.2.6 簇表的介绍及应用 187 4.3 理解表设计的你成为项目组英雄 189 第5章惊叹,索引天地妙不可言 191 5.1 看似简单无趣的索引知识 191 5.2 索引探秘从小余缉凶拉开帷幕 192 5.2.1 BTREE索引的精彩世界 192 5.2.1.1 BTREE索引结构图展现192 5.2.1.2 到底是物理还是逻辑结构 194 5.2.1.3 索引结构三大重要特点198 5.2.1.4 插播小余缉凶精彩故事201 5.2.1.5 妙用三特征之高度较低203 5.2.1.6 巧用三特征之存储列值219 5.2.1.7 活用三特征之索引有序248 5.2.1.8 不可不说的主外键设计265 5.2.1.9 组合索引高效设计要领272 5.2.1.10变换角度看索引的危害289 5.2.1.11如何合理控制索引数量295 5.2.2 位图索引的玫瑰花之刺 297 5.2.2.1 统计条数奋勇夺冠297 5.2.2.2 即席查询一骑绝尘302 5.2.2.3 遭遇更新苦不堪言306 5.2.2.4 重复度低一败涂地309 5.2.2.5 了解结构真相大白311 5.2.3 小心函数索引步步陷阱 315 5.2.3.1 列运算让索引失去作用315 5.2.3.2 函数索引是这样应用的317 5.2.3.3 避免列运算的经典案例319 5.3 索引让一系列最熟悉的SQL飞起来了 325 第6章经典,表的连接学以致用 327 6.1 表的连接之江南三剑客 327 6.2 三大类型从小余跳舞一一道来 328 6.2.1 跳舞也能跳出连接类型 328 6.2.1.1 感觉怪异的嵌套循环 328 6.2.1.2 排序合并及哈希连接 329 6.2.2 各类连接访问次数差异 330 6.2.2.1 嵌套循环的表访问次数330 6.2.2.2 哈希连接的表访问次数337 6.2.2.3 排序合并的表访问次数340 6.2.3 各类连接驱动顺序区别 341 6.2.3.1 嵌套循环的表驱动顺序341 6.2.3.2 哈希连接的表驱动顺序343 6.2.3.3 排序合并的表驱动顺序345 6.2.4 各类连接排序情况分析 347 6.2.4.1 除嵌套循环都需排序 347 6.2.4.2 排序只需取部分字段 347 6.2.4.3 关于排序的经典案例 349 6.2.5 各类连接限制场景对比 350 6.2.5.1 哈希连接的限制 350 6.2.5.2 排序合并的限制 353 6.2.5.3 嵌套循环无限制 355 6.3 你动手装备的表连接威震三军 355 6.3.1 嵌套循环与索引 356 6.3.2 哈希连接与索引 362 6.3.3 排序合并与索引 363 下篇飞翔意识天空——思想与案例的分享 第7章搞定!不靠技术靠菜刀 368 7.1 SQL被一刀剁了 369 7.2 整个模块丢弃了 370 7.3 调用次数减少了 371 7.4 排序不再需要了 372 7.5 大表砍成小表了 373 7.6 排重操作消失了 373 7.7 插入阻碍小多了 374 7.8 迁移事情不做了 375 第8章升级!靠技术改隐形刀 377 8.1 大表等同小表了 378 8.2 大表切成小表了 379 8.3 索引变身小表了 380 8.4 删除动作不做了 380 8.5 清表角度变换了 381 8.6 提交次数缩减了 382 8.7 迁移越来越快了 384 8.8 SQL语句精简了 385 第9章提问,也是智慧的体现 391 9.1 描述要考虑周全 392 9.2 用词要尽量准确 393 9.3 说明要力求简洁 394 9.4 问过的避免再问 396 9.5 能搜能试不问 396 第10章买鱼,居然买出方法论 398 10.1 小余买鱼系列故事 398 10.1.1 诊断与改进 398 10.1.2 需求与设计 401 10.1.3 资源的利用 403 10.1.4 真正的需求 404 10.2 买鱼买出了方法论 405 10.2.1 一套流程 405 10.2.2 两大法宝 407 10.3 方法论的应用案例 408 10.3.1 从我们的这一套流程说起 408 10.3.1.1 诊断 408 10.3.1.2 改进优化(首次优化) 409 10.3.1.3 需求与设计(再次优化) 410 10.3.1.4 资源利用(花絮) 412 10.3.2 案例映衬了经典两大法宝 412 第11章宝典,规范让你少做事 414 11.1 抓狂,为何事总忙不完 415 11.1.1 技术能力不足的新人们 415 11.1.2 不懂提问智慧的求助者 415 11.1.3 产生各种失误的粗心者 416 11.1.3.1 啊,小黄的DDL惹祸 416 11.1.3.2 惨,老师登错环境了 417 11.1.3.3 糟,小罗忘操作…… 417 11.1.4 解决问题缓慢的技术员 419 11.1.4.1 优化效率低下的小高 419 11.1.4.2 为何老师能快速解决 420 11.1.5 陷入种种困境的开发者 422 11.1.5.1 超长SQL使小郑烦恼 422 11.1.5.2 缺少注释让小叶沮丧 422 11.1.6 总是考虑不全的设计者 423 11.1.6.1 未提前规划的王工 423 11.1.6.2 不了解特性的刘工 424 11.2 淡定,规范少做无谓事 425 11.2.1 学习规范——促成新人快速成长 426 11.2.2 求助规范——引导求助不再迷糊 427 11.2.3 操作规范——协助粗心者不犯错 428 11.2.4 流程规范——保障问题快速解决 429 11.2.4.1 动态整体 429 11.2.4.2 动态局部 432 11.2.4.3 静态整体 439 11.2.4.4 静态局部 448 11.2.5 开发规范——让开发者驾轻就熟 451 11.2.5.1 SQL编写规范 452 11.2.5.2 PL/SQL编写规范 455 11.2.6 设计规范——助设计者运筹帷幄 457 11.2.6.1 表规范 458 11.2.6.2 索引规范 461 11.2.6.3 环境参数规范 467 11.2.6.4 命名规范 469
智能小区报警系统方案设计 一、 好士佳城市安全防范网络系统简介 随着微电子技术与网络技术的飞速发展,人们对于居住环境的安全、方便、舒适提出了 越来越高的要求,因此智能化住宅就随之出现,也随着改革开放的深入和市场经济的迅 速发展、提高,城市外来流动人口大量增加,带来许多不安定因素,刑事案件特别是入 室盗窃、抢劫居高不下,因此家庭智能安全防范系统是智能化小区建设中不可缺少的一 项,而以往的做法是安装防盗门、防盗网,但普遍存在有碍美观,不符合防火要求,而 且不能有效地防止犯罪分子对住宅的入侵,故利用高科技的电子防盗报警系统也就应运 而生。目前我国大多数家庭都是双职工,当发生警情时,不能有效地处理,因此,必须 设立小区报警中心,在发生警情时,除了现场报警外,同时还向小区的保安中心进行电 脑联网报警,以便警情得到迅速处理。针对以上情况,现由香港安时科技有限公司和好 士佳电器有限公司吸取国内外安防产品的优点取长补短,联合研制开发出适合我国国情 的防盗报警网络系统,该系统具有性能稳定、价格适中、系统容量大、误报率极低、施 工操作方便等优点,是一套先进的电子科技安防系统,是入室盗窃、抢劫等犯罪分子的 克星,也是一套预防火灾、气体泄漏的先进仪器,同时是在发生意外情况时紧求助的 最好帮手,它改善了传统的防范设施只防不报的弱点,给小区带来全新的安全概念,建 立一个可靠和开放的安全环境。该系统经公安部安全技术防范产品检测中心检验,通过 并取得生产销售许可证,被广州市政府列为2000年度拆除防盗网的推荐安保产品。 二、 好士佳系统功能简介 本系统是采用最新数码技术、微机处理技术、无线遥控技术的高智能、全方位安保系统 。本产品安全可靠、安装方便、振作简单,可匹配连接各种传感器、烟感器、泄漏探测 器等探头。并可联成网络,方便集中防范管理,是盗警、火警、气体泄漏、紧求助等 事作能及时处理解决的最佳卫士。 用户通过无线遥控器设置主机的状态: 有人在家时,可设置门钟状态。如有人进入触发传感器,主机发出门钟声,此时不拔号 ;也可设置为在家周边防范状态,此时主机只接收门窗等周边传感器信号。室内传感器 处于非工作状态。如周边有人非法闯入,主机立即向外报警。 当用户离家时,设置为离家设防状态。此时主机接收所有传感器传来的信号,如有非法 进入。主机将自动向外报警。报警中心在电子地图上自动显示出警情方位,信息栏显示 用户户主名、家庭成员、住址、电话等详细信息。让派出所能迅速出警,以最快的速度 赶往现场。 遥控器上记有紧报警功能键,无论主机处于布防或撤防状态,当用户触发此键时,主 机立即向接警中心发出求救信号。 用户可选择适当位置安装单个紧按钮。其状态与功能同遥控器上的报警键相同(用户 自选)。 主机留有专用接口,可接上煤气泄漏传感器(用户自选),无论主机处于何种状态,当 煤气浓度超过安全系数时,主机立即将报警信号发出给接警中心。 报警监听。当报警触发后报警器自动拔通主人话机,此时主人可用*键对室内情况进行监 听。 主机设置有报警拔号5个号码,用户可设置要求通知的手机、电话、传呼机号码,多方位 的通知接警中心或用户本人。 小区或集中用户可选择报警直拔管理中心或门卫电话,设置语音提示用户详细地址,以 便时处理。 三、"好士佳"防盗报警系统能达到以下要求 广泛性——使小区内每个家庭都能得到保护。(防止盗窃、火警气体泄漏等。) 实用性——每个家庭的防范系统能在实际可能发生受侵的情况及时自动报警,并且操作简 便,环节少,易学易用。 系统性——在案情发生时,除能现场报警外,也能自动拨打用户的指定手机,固定电话或 将警情传到小区的保安报警中心。 可靠性——该系统结构设计合理,产品耐用、质量可靠、误报率极低。 投资可行性——该系统性价比高,与国内同类产品相比,功能齐全。尤其比美国C K、以 色列的乐可利等系统的处警方式更符合国情,而价格更经济合理。 四、"好士佳"防盗报警系统特点 系统容量大——网络容纳十万以上住户信息。 安装方便——该系统基本采用不布线安装,不影响房屋结构和内部装修。 功能强大——设有八个防区布控,进出延时可调。远程监听,异地布防设防、电话线防剪 、防盗打等功能、兼容性强、可兼容各类型有线、无线探头,集防盗、紧求助、防煤 气泄漏、火灾自动报警于一体。 系统先进——采用先进的后台电脑软件控制,功能齐全、强大,相当于小区中设立了110报 警中心。 五、"好士佳"防盗报警系统结构及其功能 由住户室内的智能防盗报警控制主机以无线电波的形式接收各红外探头,紧求助按钮 、烟感探头,气体泄漏探头,门磁探头等发出的数据,分析后通过电话网络传送到小区 的电脑报警中心,通过电脑显示出该用户的所有资料(包括户主姓名、电话、地址), 发生何类型报警等级,并发出警号声以作提示保安人员

67,541

社区成员

发帖
与我相关
我的任务
社区描述
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
社区管理员
  • Java EE
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧