第一篇：Oracle DBA优化数据库性能心得体会
Oracle DBA优化数据库性能心得体会
很多的时侯，做Oracle DBA的我们，当应用管理员向我们通告现在应用很慢、数据库很慢的时侯，我们到数据库时做几个示例的Select也发现同样的问题时，有些时侯我们会无从下手，因为我们认为数据库的各种命种率都是满足Oracle文档的建议。实际上如今的优化己经向优化等待(waits)转型了，实际中性能优化最根本的出现点也都集中在IO，这是影响性能最主要的方面，由系统中的等待去发现Oracle库中的不足、操作系统某些资源利用的不合理是一个比较好的办法，下面把我的一点实践经验与大家分享一下，本文测重于Unix环境。
一、通过操作系统的一些工具检查系统的状态，比如CPU、内存、交换、磁盘的利用率，根据经验或与系统正常时的状态相比对，有时系统表面上看起来看空闲这也可能不是一个正常的状态，因为cpu可能正等待IO的完成。除此之外我们还应观注那些占用系统资源(cpu、内存)的进程。
1、如何检查操作系统是否存在IO的问题？使用的工具有sar,这是一个比较通用的工具。
Rp1#sar-u 2 10
即每隔2秒检察一次，共执行20次，当然这些都由你决定了。
示例返回：
HP-UX hpn2 B.11.00 U 9000/800 08/05/03
18:26:32 %usr %sys %wio %idle
注：我在redhat下查看是这种结果，不知%system就是所谓的%wio。
Linux 2.4.21-20.ELsmp(YY075)05/19/2005
10:36:07 AM CPU %user %nice %system %idle
10:36:09 AM all 0.00 0.00 0.13 99.87
10:36:11 AM all 0.00 0.00 0.00 100.00
10:36:13 AM all 0.25 0.00 0.25 99.49
10:36:15 AM all 0.13 0.00 0.13 99.75
10:36:17 AM all 0.00 0.00 0.00 100.00
10:36:17 AM CPU %user %nice %system %idle
10:36:19 AM all 0.00 0.00 0.00 100.00
10:36:21 AM all 0.00 0.00 0.00 100.00
10:36:23 AM all 0.00 0.00 0.00 100.00
10:36:25 AM all 0.00 0.00 0.00 100.00
其中的%usr指的是用户进程使用的cpu资源的百分比，%sys指的是系统资源使用cpu资源的百分比，%wio指的是等待io完成的百分比，这是值得我们观注的一项，%idle即空闲的百分比。如果wio列的值很大，如在35%以上，说明你的系统的IO存在瓶颈，你的CPU花费了很大的时间去等待IO的完成。Idle很小说明系统CPU很忙。像我的这个示例，可以看到wio平均值为11说明io没什么特别的问题，而我的idle值为零，说明我的cpu已经满负荷运行
了。
当你的系统存在IO的问题，可以从以下几个方面解决:
＊联系相应的操作系统的技术支持对这方面进行优化，比如hp-ux在划定卷组时的条带化等方面。
＊查找Oracle中不合理的sql语句，对其进行优。
＊对Oracle中访问量频繁的表除合理建索引外，再就是把这些表分表空间存放以免访问上产生热点，再有就是对表合理分区。
常用的工具便是vmstat，对于hp-unix来说可以用glance,Aix来说可以用topas,当你发现vmstat中pi列非零，memory中的free列的值很小，glance,topas中内存的利用率多于80%时，这时说明你的内存方面应该调节一下了，方法大体有以下几项。
＊划给Oracle使用的内存不要超过系统内存的1/2,一般保在系统内存的40%为益。
＊为系统增加内存。
＊如果你的连接特别多，可以使用MTS的方式。
＊打全补丁，防止内存漏洞。
3、如何找到点用系用资源特别大的Oracle的session及其执行的语句。
Hp-unix可以用glance,top，IBM AIX可以用topas，此外可以使用ps的命令。通过这些程序我们可以找到点用系统资源特别大的这些进程的进程号，我们就可以通过以下的sql语句发现这个pid正在执行哪个sql，这个sql最好在pl/sql developer,toad等软件中执行, 把<>中的spid换成你的spid就可以了。
SELECT a.username,a.machine,a.program,a.sid,a.serial#,a.status,c.piece,c.sql_text from v$session a,v$process b,v$sqltext c WHERE b.spid='ORCL' AND b.addr=a.paddr AND
a.sql_address=c.address(+)order BY c.piece
我们就可以把得到的这个sql分析一下，看一下它的执行计划是否走索引，对其优化避免全表扫描，以减少IO等待，从而加快语句的执行速度。
提示：我在做优化sql时，经常碰到使用in的语句，这时我们一定要用exists把它给换掉，因为Oracle在处理In时是按Or的方式做的，即使使用了索引也会很慢。
比如：
SELECT col1,col2,col3 FROM table1 a
WHERE a.col1 not in(SELECT col1 FROM table2)
可以换成：
SELECT col1,col2,col3 FROM table1 a
WHERE not exists
(SELECT 'x' FROM table2 b
WHERE a.col1=b.col1)
4、另一个有用的脚本：查找前十条性能差的sql。
SELECT * FROM(select PARSING_USER_ID,EXECUTIONS,SORTS,COMMAND_TYPE,DISK_READS,sql_text FROM v$sqlarea
order BY disk_reads DESC)where ROWNUM<10;
二、迅速发现Oracle Server的性能问题的成因，我们可以求助于v$session_wait这个视图，看系统的这些session在等什么，使用了多少的IO。以下是我提供的参考脚本：
脚本说明：查看占io较大的正在运行的session。
SELECT se.sid,se.serial#,pr.SPID,se.username,se.status,se.terminal,se.program,se.MODULE,、se.sql_address,st.event,st.p1text,si.physical_reads,si.block_changes FROM v$session se,v$session_wait st,v$sess_io si,v$process pr WHERE st.sid=se.sid AND st.sid=si.sid AND se.PADDR=pr.ADDR AND se.sid>6 AND st.wait_time=0 AND st.event NOT LIKE '%SQL%' ORDER BY physical_reads DESC
对检索出的结果的几点说明：
1、我是按每个正在等待的session已经发生的物理读排的序，因为它与实际的IO相关。
2、你可以看一下这些等待的进程都在忙什么，语句是否合理？
Select sql_address from v$session where sid=;
Select * from v$sqltext where address=;
执行以上两个语句便可以得到这个session的语句。你也以用alter system kill session 'sid,serial#';把这个session杀掉。
3、应观注一下event这列，这是我们调优的关键一列，下面对常出现的event做以简要的说
明：
a、buffer busy waits，free buffer waits这两个参数所标识是dbwr是否够用的问题，与IO很大相关的，当v$session_wait中的free buffer wait的条目很小或没有的时侯，说明你的系统的dbwr进程决对够用，不用调整；free buffer wait的条目很多，你的系统感觉起来一定很慢，这时说明你的dbwr已经不够用了，它产生的wio已经成为你的数据库性能的瓶颈，这时的解决办法如下：
a.1增加写进程，同时要调整db_block_lru_latches参数。
示例：修改或添加如下两个参数
db_writer_processes=4
db_block_lru_latches=8
a、2开异步IO，IBM这方面简单得多，hp则麻烦一些，可以与Hp工程师联系。
b、db file sequential read，指的是顺序读，即全表扫描，这也是我们应该尽量减少的部分，解决方法就是使用索引、sql调优，同时可以增大db_file_multiblock_read_count这个参数。
c、db file scattered read,这个参数指的是通过索引来读取，同样可以通过增加db_file_multiblock_read_count这个参数来提高性能。
d、latch free,与栓相关的了，需要专门调节。
e、其他参数可以不特别观注。
其他的优化手段似乎主要集中在SQL查询语句上面，Oracle本身也提供了优化器。看来DBA的学问不少啊。
第二篇：SQL语句性能优化
我也做了很长时间医疗软件，也写过不少sql优化，没有详细记录下来，个人感觉下面转载的更符合医院医疗软件实际业务，很认可大部分所写的原则，固转载过来，以作借鉴。软件的根本还是在于更细更精，在于从客户的实际使用考虑问题。
性能优化原则1:永远避免困境
利用缓存把字典数据取到中间服务器或是客户端替代直接sql查询,如,门诊医生站把字典下载到客户端,减少执行次数。
一次性取数据到客户端，然后再逐条处理，而不是分次取数据，处理好一条数据再取下一条再处理。例：门诊收费取hjcfmxk例子，原来是一张处方条明细都查询一次，查询后再处理，现改为一次把所有明细都取过来，然后一条条处理
尽量减少光标，看能不能用临时表
性能优化原则2:kiss原则
对于where 条件中的左边可以利用索引的字段Keep it simple stupid，左边尽量避免用函数(substring,isnull,upper,lower)，参加计算+,-*/
例子1：select * from ZY_BRFYMXK where substring(zxrq,1,8)='20081212‘
select * from ZY_BRFYMXK where zxrq between '2008121200' and '2008121224' 例子2：
select * from zy_detail_charge where SUBSTRING(patient_id,1,10)=
substring('000005090600',1,10)这句耗时30秒以上
select * from zy_detail_charge where patient_id like substring('000005090600',1,10)+'%' 这句耗时2秒以内
性能优化原则3:尽可能利用到索引
例：select * from ZY_BRFYMXK a(nolock),VW_LSYZK b(nolock)where a.syxh=3 and a.yzxh=b.xh and a.fylb=0
select * from ZY_BRFYMXK a(nolock),VW_LSYZK b(nolock)where a.syxh=3 and a.yzxh=b.xh and a.fylb=0 and b.syxh=3
性能优化原则4:or,避而远之
对于索引字段尽力避免用or，普通字段可以用or，解决要么分解成多个sql,要么用业务规则避免，例：declare @rq1 ut_rq16,@syxh ut_syxh
select @rq1='20081201'
select @syxh=157
性能优化原则5:避免大批量数据取到前台
例： select * from ZY_BRSYK cyrq between ‘20080901’ and ‘20081201‘,对于大医院每天100多人，90天是9000条数据
性能优化原则6:事务,尽可能的短吧
所有计算、对临时表的更新都应但放在事务外，事务中最好只有更新和插入正式表操作.因为事务中产生的锁只有在commit tran是才会释放。
性能优化原则7:热表，留在最后吧
热表是频繁调用的表。如：sf_mzcfk,zy_brfymxk,bq_fyqqk.对于热表尽量放在事务最后：这样锁的时间短。大家都坚持这样，死锁的可能性就小。如果都是热表各个存储过程更新表的顺序应当一样这样可以避免死锁
性能优化原则8:创建临时表一定要避免在事务中作
如create #tempXX(…)
Select * into #tempXX from …
因为创建临时表会锁tempdb的系统表
例：生成#temp1放在事务内外，用sp_lock2 ‘’观察结果
if object_id('tempdb..#temp1','U')is not null
drop table #temp1
begin tran
select * into #temp1 from ZY_BRSYK where ryrq>'20080901‘
select * from #temp1
waitfor delay '00:00:10'
commit
性能优化原则9:大的报表查询避免与正常业务碰撞
如果没有查询服务器，那要在存储过程中限制不能操作加上如：
declare @rq1 ut_rq16,@rq2 ut_rq16,@now ut_rq16
select @rq1=convert(varchar(8),getdate(),112)+'08:00:00'
select @rq1=convert(varchar(8),getdate(),112)+'11:30:00'
select @now=convert(char(8),getdate(),112)+convert(char(8),getdate(),8)
if @now>@rq1 and @now<@rq2
begin
select '上午繁忙时间段不能作此查询'
return
end
性能优化原则10:存储过程避免大的if…else…
这个常出项在业务相同表不同的存储过程中，因为这样常到if …else …原来医技接口中很多这种存储过程，当时把门诊住院业务放在一个存储过程中。这样最大的问题是sql server会根据sql语句来compile存储，这个过程会生成优化计划，决定用那个索引。如果存储过程用到门诊表compile一下，到用到住院表是发现不对，又会compile一下，这样不停compile.compile很号时间要1-2秒，而且一个存储过成在compile是，所有调用这个存储过程的进程都要在排队等候,因为他会独占锁这个存储过程
例：usp_yjjk_getwzxxm_old.sql,后改为：
usp_yjjk_getwzxxm.sql, usp_yjjk_getwzxxm_mz.sql,usp_yjjk_getwzxxm_zy.sql
性能优化原则11:进攻是最好的防守
在普通编程语句对于数据校验总是用防守办法先判断,后再作相应处理。而在sql中先处理再判断性能会好很多。
--更新药品库存。
If exists(select 1 from YK_YKZKC WHERE idm=100 and kcsl>50)
begin
update YK_YKZKC set kcsl=kcsl-50 where idm=100
End
Else begin
rollback tran
Select ‘F库存不够’
return
end
--改为
update YK_YKZKC set kcsl=kcsl-50 where idm=100 and kcsl>50
If @@rowcount<=0
Begin
Rollbakc tran
Select ‘F库存不够’
end
--取未执行的医技项目,日表没有数据就到年表中查找
if exists(select a.* from SF_MZCFK a(nolock),SF_CFMXK b(nolock)
begin
select a.* into #temp1 from SF_MZCFK a(nolock),SF_CFMXK b(nolock)
end
else begin
select a.* into #temp1 from SF_NMZCFK a(nolock),SF_NCFMXK b(nolock)
end
--改为
Insert into #temp1 select a.*
from SF_MZCFK a(nolock),SF_CFMXK b(nolock)
If @@rowcount=0
Begin
Insert into #temp1 select a.*
from SF_NMZCFK a(nolock),SF_NCFMXK b(nolock)
end
性能优化原则12:trig最后的手段
Trig（触发器）的处理的处理机制是满足条件时就会在源语句后面加上trig中的代码进行执行。
它有两个致命的弊端：（1）不清楚有trig的人会对于执行结果感到迷惑。如常有在插入一张表如果主键是indentity的值常取用select @@identity。但如是有trig,tring中有表插入操作，这时的@@identity可能就不是想要的值。（2）trig会束缚选择。如：有一套单据主表和明细表，当明细表的金额更新时，要同步主表的金额，当程序是一条条更新明细时用trig的作法是每当更新一条明细记录时都算一处所有明细表的总金额，再去更新主表的金额。这样有多少条明细就要算多少次，好的作法是不要trig,直接在sql语句中明细更新完明后，一次性算出总金额每条单据的总金额，再更新主表的金额。
对于trig如果有其他手段就一定要避免用trig.性能优化原则13:用户说好才是真的好
1）有时sql语句性能难以优化，但用户对于系统响应速度还是不满意。这时可以从业务分析处理。
如：我们退费模块录入发票号原来是用fph like ‘XXX%’。用户报怨慢，后来改为先用fph=‘XXX’来查，如查不到再fph like ‘XXX%’。这样在绝大部情况下速度都非常快，同时也满足小部分情况下模糊查询的需求。
如：我们的程序要查日表和年表。如果通过日表union表视图去查会非常慢，性能也难以优化。程序改为普通情况下不查年表，用户勾上年表标志时才查年表。
（2）查询统计很多数据时间比较长，就以查询完一部分数据后可以显示这部分数据或是用提示，这样用户清楚系统在作事情也知道大概进度。这样情绪上会好很多。
（3）查询模块常有一进入时也默认一个查询，如果性能好，查询又合用户心意，这种设计非常好，如果性能不好，那就不是好的设计。用户对于进入都困难的模块是没有好感的。
（4）有户的耐心与查询出的记录成正比。用户痛恨等待很久却没有查询出记录。
对于非常慢的查询，如果有些子查询非常快可以先作这样查询以避免查询很久却没有数据出来的情况。如：按病历号查在院病人所有费有明细，可以先查一下这个病历是不是有对应病人。
实战技巧1:用exists、in代替distinct
Distinct实际上是先收集再删除这样两步都耗资源。
Exists,in会隐式过滤掉重复的记录
例查自2009年以来有金额大于100的药品的病人
select distinct a.blh,a.hzxm from ZY_BRXXK a(nolock),ZY_BRSYK b(nolock),ZY_BRFYMXK c(nolock)where a.patid=b.patid and b.syxh=c.syxh and c.zxrq>'2009' and c.zje>100--改为
select a.blh,a.hzxm from ZY_BRXXK a where exists(select 1 from ZY_BRSYK
b(nolock),ZY_BRFYMXK c(nolock)where a.patid=b.patid and b.syxh=c.syxh and
c.zxrq>'2009'and c.zje>100)
实战技巧2:缩短union
select …from A,B,C,D,E1
where(E1的条件)
and(其他表联接条件)
union
select …from A,B,C,D,E2
where(E2的条件)
and(其他表接接条件)
改为
select …from A,B,C,D,(select...from E1where(E1条件)
union
select …from E2where(E2条件))E where(其他条件)
当涉及ABCD表部分耗资源而E1,E2不耗资源时是这样，如果反过来则改后的性能不一定好。查2009年4月后入院的在院病人在2905病区发生的所有费用明细
select a.hzxm,b.cyrq,d.ypmc,d.ypgg,c.ypsl/c.dwxs ypsl, c.ypdw
select a.hzxm,b.cyrq,d.ypmc,d.ypgg,c.ypsl/c.dwxs ypsl, c.ypdw
from ZY_BRXXK a(nolock),ZY_BRSYK b(nolock),ZY_BRFYMXK c(nolock),YK_YPCDMLK d where a.patid=b.patid and b.ryrq>'200904' and b.brzt not in(3,8,9)and b.syxh=c.syxh and c.bqdm='2905' and c.idm=d.idm
union all
select a.hzxm,b.cyrq,d.name,d.xmgg,c.ypsl/c.dwxs ypsl, c.ypdw
from ZY_BRXXK a(nolock),ZY_BRSYK b(nolock),ZY_BRFYMXK c(nolock),YY_SFXXMK d where a.patid=b.patid and b.ryrq>'200904' and b.brzt not in(3,8,9)and b.syxh=c.syxh and c.bqdm='2905' and c.ypdm=d.id and c.idm=0
--改为
select a.hzxm,b.cyrq,d.ypmc,d.ypgg,c.ypsl/c.dwxs ypsl, c.ypdw
from ZY_BRXXK a(nolock),ZY_BRSYK b(nolock),ZY_BRFYMXK c(nolock),(select ypmc,ypgg,ypdm,idm idm from YK_YPCDMLK union select name,xmgg,id,0 from YY_SFXXMK)d
where a.patid=b.patid and b.ryrq>'200904' and b.brzt not in(3,8,9)and b.syxh=c.syxh and c.bqdm='2905' and c.idm=d.idm and c.ypdm=d.ypdm
实战技巧3:合并sql
把表和where条件类似的两个或是多个sql合并为一个sql.--查2009年以后的普通、急诊、专家挂号人数
declare @ptghs int,@jzghs int,@zjghs int
select @ptghs=0,@jzghs=0,@zjghs=0
select @ptghs=count(*)from GH_GHZDK where ghrq>'2009' and ghlb=0
select @jzghs=count(*)from GH_GHZDK where ghrq>'2009' and ghlb=1
select @zjghs=count(*)from GH_GHZDK where ghrq>'2009' and ghlb=2
select @ptghs,@jzghs,@zjghs
--改为
select @ptghs=0,@jzghs=0,@zjghs=0
select @ptghs=sum(case when ghlb=0 then 1 else 0 end),@jzghs=sum(case when ghlb=1 then 1 else 0 end), @zjghs=sum(case when ghlb=2 then 1 else 0 end)
from GH_GHZDK where ghrq>'2009'
select @ptghs,@jzghs,@zjghs
实战技巧4:去掉游标
把游标当作编程语言的for,do---while的方式，很多情况下都可以去掉,如果光标中间sql语句只有一条一般都是可以去掉光标改为一句sql。
--查当天出院出院日期在2009年4月1到9日间病人的zfdj,zfje置为0
declare @syxh ut_syxh
declare cur1 cursor for select syxh from ZY_BRSYK where cyrq>='20090401' and cyrq<'20090410'
open cur1
fetch cur1 into @syxh
while @@fetch_status=0
begin
fetch cur1 into @syxh
end
close cur1
deallocate cur1
--改为
update ZY_BRFYMXK set zfdj=0,zfje=0
from ZY_BRFYMXK a,ZY_BRSYK b
where a.syxh=b.syxh and b.cyrq>='20090401' and b.cyrq<'20090410'
实战技巧5:取代count
利用内部函数代替
declare @count int
select * into #tmep1 from ZY_BRFYMXK WHERE zxrq>'200901'
select @count=@@rowcount—可以得到count值
select @count
select @count=count(*)from #tmep1—可以被取代
select @count
利用exists而不count判断有没有记录
declare @count int
Select @count=count(1)from ZY_BRFYMXK WHERE zxrq>'2009‘
If @count>0 … else ….--改为
If exists(Select 1 from ZY_BRFYMXK WHERE zxrq>'2009’)… else ….
第三篇：编程语言的数据库性能比较
编程语言的数据库性能比较
摘要：随着计算机技术不断发展，各种数据库编程工具也随着发展，使当今的大多数程序开发人员可以摆脱枯燥无味的用计算机指令或汇编语言开发软件，而是利用一系列高效的、具有良好可视化的编程工具去开发各种数据库软件，从而达到事半功倍的效果，但是现在市面上的数据库编程工具门类众多，优良不齐，比如VB，VC，DEPHI，PB等，对此我特别针对流行的开发语言介绍相应的较为成熟的数据库编程工具。
几种支持数据库的语言介绍
VB
全称Visual Basic，它是以Basic语言作为其基本语言的一种可视化编程工具。在中国乃至全世界都能看到它的身影，它曾是在中国最为流行的编程工具，到现在还占据着非常重要的地位，对于它的好坏大家都有一定的了解，VB作为一种较早出现的开发程序以其容易学习，开发效率较高，具有完善的帮助系统等优点曾影响了好几代编程人员，但是由于VB不具备跨平台这个特性，从而也决定了VB在未来的软件开发中将会逐渐地退出其历史舞台；它对组件技术的支持是基于COM和ActiveX,对于组件技术不断完善发展的今天，它也显出了它的落后性；同时VB在进行系统底层开发的时候也是相对复杂的，调用API函数需声明，调用不方便，不能进行DDK编程，不可能深入Ring0编程，不能嵌套汇编；而且面向对象的特性差；网络功能和数据库功能也没有非常突出的表现，综上所述，VB作为一种可视化的开发工具由于其本身的局限性，导致了它在未来软件开发中逐
步被其他工具所代替。
PB
全称PowerBuilder，是开发MIS系统和各类数据库跨平台的首选工具，使用简单，容易学习，容易掌握，在代码执行效率上也有相当出色的表现。PB是一种真正的4GL语言（第四代语言），可随意直接嵌套SQL语句返回值被赋值到语句的变量中，支持语句级游标，存储过程和数据库函数，是一种类似SQLJ的规范，数据访问中具有无可比拟的灵活性。但是它在系统底层开发中犯了跟VB一样的错误，调用API函数需声明，调用不方便，不能进行DDK编程，不可能深入Ring0编程，不能嵌套汇编；在网络开发中提供了较多动态生成Web页面的用户对象和服务以及系统对象，非常适合编写服务端动态Web应用，有利于商业逻辑的封装；但是用于网络通讯的支持不足；静态页面定制支持有限，使得PB在网络方面的应用也不能非常广泛。面向对象特向也不是太好。
C++Builder/Delphi
它们都是基于VCL库的可视化开发工具，它们在组件技术的支持、数据库支持、系统底层开发支持、网络开发支持、面向对象特性等各方面都有相当不错的表现，并且学习使用较为容易，充分提现了所见即所得的可视化开发方法，开发效率高。由于两者都是Borland 公司的产品，自然继承了该公司一贯以来的优良传统：代码执行效率高。但是，它们并不是毫无缺点，它们所作的最大不足之处就是他们的帮助系统在众多的编程工具中是属于比较差的。C++Builder 的VCL库是基 1
于Object pascal(面向对象pascal),使得C++Builder在程序的调试执行上都面向落后于其他编程工具。而Delphi则是它的语言不够广泛，开发系统软件功能
不足两个比较大的缺点。
Visual C++
是基于MFC库的可视化的开发工具，从总体上说它是一个功能强大但是不便使用的一种工具。它在网络开发和多媒体开发都具有不俗的表现，帮助系统也做得非常不错（Microsoft 在细节方面的处理往往都让人觉得亲切），但是虽然是使用C++作为基本语言，但是它在面向对象特性上却不够好，主要是为了兼容C的程序，结果顾此失彼；在组件支持上也不太好，虽然说除了支持COM,ActiveX外还支持CORBA,但是没有任何IDE支持，是所有C编译器的功能, 需要CORBA中间
件支持；最大的问题是开发效率也不高。
Java
目前比较出名的是Borland出的JBuilder和IBM出的Visual Age for Java,两种工具都有一定数量的是用人群。JBuilder继承了C++Builder/Delphi的特点，在可视化上做得非常不错，使用简便。由于Java本身语言的特点使得他们在网络开发中具有高人一等的表现，而且面向对象特性高，支持的组件技术也非常多，跨平台的特性也使得它在现在和未来的开发中占据越来越重要的地位。但是在系统底层开发和多媒体开发中却表现得并不让人那么满意，这个可能跟设计Java的意图有关吧。
第四篇：计算机系统性能优化总结
计算机系统性能优化总结
现今，计算机技术在社会各行各业都得到了广泛的应用。计算机给我们的学习、生活和工作都带来了极大的便利。但随着我们对计算机整体性能要求的提高，计算机系统性能的优化就显得尤为重要。
一、计算机系统运行不佳的原因分析
计算机系统运行性能不佳的原因有很多。如，系统平台结构不好、系统配置不好或参数设置不对；应用系统数据结构设计不合理，加大了系统的输入和输出需求；应用系统算法或逻辑处理有问题，使计算机系统达不到最佳的运行状态。
二、计算机系统性能优化措施
1.合理地配置各种软件，使计算机系统发挥最好的功能。计算机系统由硬件系统和软件系统组成，二者之间相互依赖，这就要求我们在使用计算机软件的过程中，使用一些速度较快、版本较高和功能较完善的软件，并仔细阅读各种软件的使用说明，避免在应用过程中发生冲突。作为编程人员，在编写应用程序的过程中，要充分考虑应用系统数据结构设计的合理性，以便使计算机系统达到最佳的运行状态。
2.调整输入和输出系统。在计算机系统的应用过程中，我们进行的大多数操作就是输入和输出。因此，输入和输出操作是影响计算机性能的一个重要因素。随着科技的日益发
展，磁盘的平均寻址时间日益缩短，但与中央处理器的运算相比，仍然缓慢很多。在观察一些系统运行时，经常出现中央处理器处在空闲状态而应用程序却迟迟不能完成的情况。究其原因，就是因为磁盘的输入和输出的速度太慢，数据没有读（写）入内存中。因此，在实际的应用过程中，我们可以考虑把数据文件存放在不同的磁盘上，让多个磁盘并行工作，从而解决输入和输出的瓶颈问题。如果输入和输出总数明显不合理，就要考虑查找引起输入和输出数量增大的原因，从而优化应用程序，减少输入和输出的次数，提高系统的性能。
3.安排相同性质的处理过程同时运行，以确保中央处理器和输入和输出的绝对通畅。一台计算机能够同时运行多个应用程序，从使用系统资源的角度来看，这些应用程序可以分为面向输入和输出与面向运算2种类型。
系统中如果有2个或多个面向输入和输出的应用在同时运行，就会造成中央处理器闲置而大量磁盘输入和输出拥塞和等待的情况，使得各个应用程序的性能变差。系统中如果有2个或多个面向运算的应用程序同时运行时，就会造成磁盘空转的情况。因此，要尽量避免让多个面向输入和输出或多个面向运算的应用程序同时运行。最好的安排就是让面向输入和输出与面向运算的应用程序合理搭配，使每个应用都能获得足够的系统服务而又互不影响。
4.合理地使用中央处理器。一般来说，在一个计算机系统中，中央处理器的速度要远远高于输入和输出的速度，因而输入和输出速度往往是影响系统性能的主要因素。但必须指出的是，这种规则只适用于普通的情况。如果不知道中央处理器能力也有一定限制，盲目地、不合理地使用中央处理器，中央处理器也会成为影响系统性能的主要因素。
通过对计算机系统的性能进行优化，排除了系统中的各种不合理因素，缩短了系统的响应时间，使计算机系统能更好地发挥作用，从而为我们提供更好的服务。
第五篇：网站前端性能优化总结
一、服务器侧优化
1.添加 Expires 或 Cache-Control 信息头
某些经常使用到、并且不会经常做改动的图片（banner、logo等等）、静态文件（登录首页、说明文档等）可以设置较长的有效期（expiration date），这些HTTP头向客户端表明了文档的有效性和持久性。如果有缓存，文档就可以从缓存（除已经过期）而不是从服务器读取。接着，客户端考察缓存中的副本，看看是否过期或者失效，以决定是否必须从服务器获得更新。
各个容器都有针对的方案,，以 Apache 为例：
ExpiresActive On ExpiresByType image/gif “access plus 1 weeks”
表示gif文件缓存一周，配置可以根据具体的业务进行调整，具体配置可以参考：http://lamp.linux.gov.cn/Apache/ApacheMenu/mod/mod_expires.html
2.压缩内容
对于绝大多数站点，这都是必要的一步，能有效减轻网络流量压力。
表示zlib在压缩时可以最大程度的使用内存，压缩html、文本、xml和php这几种类型的文件，指定扩展名为html、htm、xml、php、css和js的文件启用压缩。
具体配置可以参考：http://lamp.linux.gov.cn/Apache/ApacheMenu/mod/mod_deflate.html
3.设置 Etags
在使用etags之前，有必要复习一下 RFC2068 中规定的返回值 200 和 304 的含义：
200--OK 304--Not Modified
客户端在请求一份文件的时候，服务端会检查客户端是否存在该文件，如果客户端不存在该文件，则下载该文件并返回200；如果客户端存在该文件并且该文件在规定期限内没有被修改（Inode，MTime和Size），则服务端只返回一个304，并不返回资源内容，客户端将会使用之前的缓存文件。而etags就是判断该文件是否被修改的记号，与服务器端的资源一一关联，所以etags对于CGI类型的页面缓存尤其有用。
下图是优化前的首页：（注意，此时没有压缩首页图片，即使使用了缓存，仍需要5s左右的时间）
化前的某页面
需要注意的是，使用etags会增加服务器端的负载，在实际应用中需要自行平衡。
二、Cookie优化
1.减小Cookie体积
HTTP coockie可以用于权限验证和个性化身份等多种用途。coockie内的有关信息是通过HTTP文件头来在web服务器和浏览器之间进行交流的。因此保持coockie尽可能的小以减少用户的响应时间十分重要。
使cookie体积尽量小；
在合适的子域名上设置bookie，以免影响其他子域名下的响应；
设置合理的过期时间，去掉不必要的cookie。
下面对比一下各个网站的cookie：
图中可以看出，6K的cookie显然是不必要的。
2.对于页面内容使用无coockie域名
当浏览器在请求中同时请求一张静态的图片和发送coockie时，服务器对于这些coockie不会做任何地使用。因此它们只是因为某些负面因素而创建的网络传输。所以你应该确定对于静态内容的请求是无coockie的请求。创建一个子域名并用他来存放所有静态内容。
例如，域名是
3.切分组件到多个域
主要的目的是提高页面组件并行下载能力，但注意，也不要同时使用过多的域名，否则就会出现第一条DNS lookup过多的问题，一般情况下两个域名就可以了。
4.杜绝 http 404 错误
对页面链接的充分测试加上对 Web 服务器 error 日志的不断跟踪可以有效减少 404 错误，并提升用户体验。
后记：
这次总结给我带来的启发并不在于提升系统性能性能本身，提升性能只是一个很表面上的东西，网上的方法有很多，测试的方法也有很多，照着都做一遍，性能确实会有所提升，但是这种知其然而不知其所以然的性能提升是没有意义的，这便是本文的目的所在。
点击咨询 