第一篇：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 錯誤，并提升用戶體驗。
后記：
這次總結給我帶來的啟發并不在于提升系統性能性能本身，提升性能只是一個很表面上的東西，網上的方法有很多，測試的方法也有很多，照著都做一遍，性能確實會有所提升，但是這種知其然而不知其所以然的性能提升是沒有意義的，這便是本文的目的所在。
點擊咨詢 