SQL Server數(shù)據(jù)庫(kù)如下方法來(lái)優(yōu)化查詢 :
1、把數(shù)據(jù)、日志、索引放到不同的I/O設(shè)備上，增加讀取速度，以前可以將Tempdb應(yīng)放在RAID0上，SQL2000不在支持。數(shù)據(jù)量(尺寸)越大，提高I/O越重要.
2、縱向、橫向分割表，減少表的尺寸(sp_spaceuse)
3、升級(jí)硬件
4、根據(jù)查詢條件,建立索引,優(yōu)化索引、優(yōu)化訪問(wèn)方式，限制結(jié)果集的數(shù)據(jù)量。注意填充因子要適當(dāng)(最好是使用默認(rèn)值0)。索引應(yīng)該盡量小，使用字節(jié)數(shù)小的列建索引好(參照索引的創(chuàng)建),不要對(duì)有限的幾個(gè)值的字段建單一索引如性別字段
5、提高網(wǎng)速;
6、擴(kuò)大服務(wù)器的內(nèi)存,Windows 2000和SQL server 2000能支持4-8G的內(nèi)存。配置虛擬內(nèi)存：虛擬內(nèi)存大小應(yīng)基于計(jì)算機(jī)上并發(fā)運(yùn)行的服務(wù)進(jìn)行配置。運(yùn)行 Microsoft SQL Server? 2000 時(shí)，可考慮將虛擬內(nèi)存大小設(shè)置為計(jì)算機(jī)中安裝的物理內(nèi)存的 1.5 倍。如果另外安裝了全文檢索功能，并打算運(yùn)行 Microsoft 搜索服務(wù)以便執(zhí)行全文索引和查詢，可考慮：將虛擬內(nèi)存大小配置為至少是計(jì)算機(jī)中安裝的物理內(nèi)存的 3 倍。將 SQL Server max server memory 服務(wù)器配置選項(xiàng)配置為物理內(nèi)存的 1.5 倍(虛擬內(nèi)存大小設(shè)置的一半)。
7、增加服務(wù)器 CPU個(gè)數(shù);但是必須明白并行處理串行處理更需要資源例如內(nèi)存。使用并行還是串行程是MsSQL自動(dòng)評(píng)估選擇的。單個(gè)任務(wù)分解成多個(gè)任務(wù)，就可以在處理器上運(yùn)行。例如耽擱查詢的排序、連接、掃描和GROUP BY字句同時(shí)執(zhí)行，SQL SERVER根據(jù)系統(tǒng)的負(fù)載情況決定最優(yōu)的并行等級(jí)，復(fù)雜的需要消耗大量的CPU的查詢最適合并行處理。但是更新操作Update,Insert， Delete還不能并行處理。
8、如果是使用like進(jìn)行查詢的話，簡(jiǎn)單的使用index是不行的，但是全文索引，耗空間。 like 'a%' 使用索引 like '%a' 不使用索引用 like '%a%' 查詢時(shí)，查詢耗時(shí)和字段值總長(zhǎng)度成正比,所以不能用CHAR類型，而是VARCHAR。對(duì)于字段的值很長(zhǎng)的建全文索引。
9、DB Server 和APPLication Server 分離;OLTP和OLAP分離
10、分布式分區(qū)視圖可用于實(shí)現(xiàn)數(shù)據(jù)庫(kù)服務(wù)器聯(lián)合體。聯(lián)合體是一組分開(kāi)管理的服務(wù)器，但它們相互協(xié)作分擔(dān)系統(tǒng)的處理負(fù)荷。這種通過(guò)分區(qū)數(shù)據(jù)形成數(shù)據(jù)庫(kù)服務(wù)器聯(lián)合體的機(jī)制能夠擴(kuò)大一組服務(wù)器，以支持大型的多層 Web 站點(diǎn)的處理需要。有關(guān)更多信息，參見(jiàn)設(shè)計(jì)聯(lián)合數(shù)據(jù)庫(kù)服務(wù)器。(參照SQL幫助文件'分區(qū)視圖')
a、在實(shí)現(xiàn)分區(qū)視圖之前，必須先水平分區(qū)表
b、在創(chuàng)建成員表后，在每個(gè)成員服務(wù)器上定義一個(gè)分布式分區(qū)視圖，并且每個(gè)視圖具有相同的名稱。這樣，引用分布式分區(qū)視圖名的查詢可以在任何一個(gè)成員服務(wù)器上運(yùn)行。系統(tǒng)操作如同每個(gè)成員服務(wù)器上都有一個(gè)原始表的復(fù)本一樣，但其實(shí)每個(gè)服務(wù)器上只有一個(gè)成員表和一個(gè)分布式分區(qū)視圖。數(shù)據(jù)的位置對(duì)應(yīng)用程序是透明的。
11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收縮數(shù)據(jù)和日志 DBCC SHRINKDB,DBCC SHRINKFILE. 設(shè)置自動(dòng)收縮日志.對(duì)于大的數(shù)據(jù)庫(kù)不要設(shè)置數(shù)據(jù)庫(kù)自動(dòng)增長(zhǎng)，它會(huì)降低服務(wù)器的性能。在T-sql的寫法上有很大的講究，下面列出常見(jiàn)的要點(diǎn)：首先，DBMS處理查詢計(jì)劃的過(guò)程是這樣的：
1、 查詢語(yǔ)句的詞法、語(yǔ)法檢查
2、 將語(yǔ)句提交給DBMS的查詢優(yōu)化器
3、 優(yōu)化器做代數(shù)優(yōu)化和存取路徑的優(yōu)化
4、 由預(yù)編譯模塊生成查詢規(guī)劃
5、 然后在合適的時(shí)間提交給系統(tǒng)處理執(zhí)行
6、 最后將執(zhí)行結(jié)果返回給用戶其次，看一下SQL SERVER的數(shù)據(jù)存放的結(jié)構(gòu)：一個(gè)頁(yè)面的大小為8K(8060)字節(jié)，8個(gè)頁(yè)面為一個(gè)盤區(qū)，按照B樹(shù)存放。
12.commit和rollback的區(qū)別 Rollback:回滾所有的事物。 Commit:提交當(dāng)前的事物. 沒(méi)有必要在動(dòng)態(tài)SQL里寫事物，如果要寫請(qǐng)寫在外面如： begin tran exec(@s) commit trans 或者將動(dòng)態(tài)SQL 寫成函數(shù)或者存儲(chǔ)過(guò)程。
13、在查詢Select語(yǔ)句中用Where字句限制返回的行數(shù),避免表掃描,如果返回不必要的數(shù)據(jù)，浪費(fèi)了服務(wù)器的I/O資源，加重了網(wǎng)絡(luò)的負(fù)擔(dān)降低性能。如果表很大，在表掃描的期間將表鎖住，禁止其他的聯(lián)接訪問(wèn)表,后果嚴(yán)重。
14、SQL的注釋申明對(duì)執(zhí)行沒(méi)有任何影響
15、盡可能不使用光標(biāo)，它占用大量的資源。如果需要row-by-row地執(zhí)行，盡量采用非光標(biāo)技術(shù),如：在客戶端循環(huán)，用臨時(shí)表，Table變量，用子查詢，用Case語(yǔ)句等等。游標(biāo)可以按照它所支持的提取選項(xiàng)進(jìn)行分類： 只進(jìn) 必須按照從第一行到最后一行的順序提取行。
FETCH NEXT 是唯一允許的提取操作,也是默認(rèn)方式?？蓾L動(dòng)性可以在游標(biāo)中任何地方隨機(jī)提取任意行。游標(biāo)的技術(shù)在SQL2000下變得功能很強(qiáng)大，他的目的是支持循環(huán)。有四個(gè)并發(fā)選項(xiàng) READ_ONLY：不允許通過(guò)游標(biāo)定位更新(Update)，且在組成結(jié)果集的行中沒(méi)有鎖。 OPTIMISTIC WITH valueS:樂(lè)觀并發(fā)控制是事務(wù)控制理論的一個(gè)標(biāo)準(zhǔn)部分。樂(lè)觀并發(fā)控制用于這樣的情形，即在打開(kāi)游標(biāo)及更新行的間隔中，只有很小的機(jī)會(huì)讓第二個(gè)用戶更新某一行。當(dāng)某個(gè)游標(biāo)以此選項(xiàng)打開(kāi)時(shí)，沒(méi)有鎖控制其中的行，這將有助于最大化其處理能力。如果用戶試圖修改某一行，則此行的當(dāng)前值會(huì)與最后一次提取此行時(shí)獲取的值進(jìn)行比較。如果任何值發(fā)生改變，則服務(wù)器就會(huì)知道其他人已更新了此行，并會(huì)返回一個(gè)錯(cuò)誤。如果值是一樣的，服務(wù)器就執(zhí)行修改。選擇這個(gè)并發(fā)選項(xiàng)OPTIMISTIC WITH ROW VERSIONING:此樂(lè)觀并發(fā)控制選項(xiàng)基于行版本控制。使用行版本控制，其中的表必須具有某種版本標(biāo)識(shí)符，服務(wù)器可用它來(lái)確定該行在讀入游標(biāo)后是否有所更改。在 SQL Server 中，這個(gè)性能由 timestamp 數(shù)據(jù)類型提供，它是一個(gè)二進(jìn)制數(shù)字，表示數(shù)據(jù)庫(kù)中更改的相對(duì)順序。每個(gè)數(shù)據(jù)庫(kù)都有一個(gè)全局當(dāng)前時(shí)間戳值：@@DBTS。每次以任何方式更改帶有 timestamp 列的行時(shí)，SQL Server 先在時(shí)間戳列中存儲(chǔ)當(dāng)前的 @@DBTS 值，然后增加 @@DBTS 的值。如果某 個(gè)表具有 timestamp 列，則時(shí)間戳?xí)挥浀叫屑?jí)。服務(wù)器就可以比較某行的當(dāng)前時(shí)間戳值和上次提取時(shí)所存儲(chǔ)的時(shí)間戳值，從而確定該行是否已更新。服務(wù)器不必比較所有列的值，只需比較 timestamp 列即可。如果應(yīng)用程序?qū)](méi)有 timestamp 列的表要求基于行版本控制的樂(lè)觀并發(fā)，則游標(biāo)默認(rèn)為基于數(shù)值的樂(lè)觀并發(fā)控制。 SCROLL LOCKS 這個(gè)選項(xiàng)實(shí)現(xiàn)悲觀并發(fā)控制。在悲觀并發(fā)控制中，在把數(shù)據(jù)庫(kù)的行讀入游標(biāo)結(jié)果集時(shí)，應(yīng)用程序?qū)⒃噲D鎖定數(shù)據(jù)庫(kù)行。在使用服務(wù)器游標(biāo)時(shí)，將行讀入游標(biāo)時(shí)會(huì)在其上放置一個(gè)更新鎖。如果在事務(wù)內(nèi)打開(kāi)游標(biāo)，則該事務(wù)更新鎖將一直保持到事務(wù)被提交或回滾;當(dāng)提取下一行時(shí)，將除去游標(biāo)鎖。如果在事務(wù)外打開(kāi)游標(biāo)，則提取下一行時(shí)，鎖就被丟棄。因此，每當(dāng)用戶需要完全的悲觀并發(fā)控制時(shí)，游標(biāo)都應(yīng)在事務(wù)內(nèi)打開(kāi)。更新鎖將阻止任何其它任務(wù)獲取更新鎖或排它鎖，從而阻止其它任務(wù)更新該行。然而，更新鎖并不阻止共享鎖，所以它不會(huì)阻止其它任務(wù)讀取行，除非第二個(gè)任務(wù)也在要求帶更新鎖的讀取。滾動(dòng)鎖根據(jù)在游標(biāo)定義的 Select 語(yǔ)句中指定的鎖提示，這些游標(biāo)并發(fā)選項(xiàng)可以生成滾動(dòng)鎖。滾動(dòng)鎖在提取時(shí)在每行上獲取，并保持到下次提取或者游標(biāo)關(guān)閉，以先發(fā)生者為準(zhǔn)。下次提取時(shí)，服務(wù)器為新提取中的行獲取滾動(dòng)鎖，并釋放上次提取中行的滾動(dòng)鎖。滾動(dòng)鎖獨(dú)立于事務(wù)鎖，并可以保持到一個(gè)提交或回滾操作之后。如果提交時(shí)關(guān)閉游標(biāo)的選項(xiàng)為關(guān)，則 COMMIT 語(yǔ)句并不關(guān)閉任何打開(kāi)的游標(biāo)，而且滾動(dòng)鎖被保留到提交之后，以維護(hù)對(duì)所提取數(shù)據(jù)的隔離。所獲取滾動(dòng)鎖的類型取決于游標(biāo)并發(fā)選項(xiàng)和游標(biāo) Select 語(yǔ)句中的鎖提示。鎖提示 只讀 樂(lè)觀數(shù)值 樂(lè)觀行版本控制 鎖定無(wú)提示 未鎖定 未鎖定 未鎖定 更新 NOLOCK 未鎖定 未鎖定未鎖定 未鎖定 HOLDLOCK 共享 共享 共享 更新 UPDLOCK 錯(cuò)誤 更新 更新 更新 TABLOCKX 錯(cuò)誤 未鎖定 未鎖定更新其它 未鎖定 未鎖定 未鎖定 更新 *指定 NOLOCK 提示將使指定了該提示的表在游標(biāo)內(nèi)是只讀的。
16、用Profiler來(lái)跟蹤查詢，得到查詢所需的時(shí)間，找出SQL的問(wèn)題所在;用索引優(yōu)化器優(yōu)化索引
17、注意UNion和UNion all 的區(qū)別。UNION all好
18、注意使用DISTINCT，在沒(méi)有必要時(shí)不要用，它同UNION一樣會(huì)使查詢變慢。重復(fù)的記錄在查詢里是沒(méi)有問(wèn)題的
19、查詢時(shí)不要返回不需要的行、列
20、用sp_configure 'query governor cost limit'或者SET QUERY_GOVERNOR_COST_LIMIT來(lái)限制查詢消耗的資源。當(dāng)評(píng)估查詢消耗的資源超出限制時(shí)，服務(wù)器自動(dòng)取消查詢,在查詢之前就扼殺掉。 SET LOCKTIME設(shè)置鎖的時(shí)間
21、用select top 100 / 10 Percent 來(lái)限制用戶返回的行數(shù)或者SET ROWCOUNT來(lái)限制操作的行
22、在SQL2000以前，一般不要用如下的字句: "IS NULL", "<>", "!=", "!>", "!<", "NOT", "NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE '%500'"，因?yàn)樗麄儾蛔咚饕潜頀呙琛Ｒ膊灰赪here字句中的列名加函數(shù)，如Convert，substring等,如果必須用函數(shù)的時(shí)候，創(chuàng)建計(jì)算列再創(chuàng)建索引來(lái)替代.還可以變通寫法：Where SUBSTRING(firstname,1,1) = 'm'改為Where firstname like 'm%'(索引掃描)，一定要將函數(shù)和列名分開(kāi)。并且索引不能建得太多和太大。NOT IN會(huì)多次掃描表，使用EXISTS、NOT EXISTS ，IN , LEFT OUTER JOIN 來(lái)替代，特別是左連接,而Exists比IN更快，最慢的是NOT操作.如果列的值含有空，以前它的索引不起作用，現(xiàn)在2000的優(yōu)化器能夠處理了。相同的是IS NULL，"NOT", "NOT EXISTS", "NOT IN"能優(yōu)化她，而"<>"等還是不能優(yōu)化，用不到索引。
23、使用Query Analyzer，查看SQL語(yǔ)句的查詢計(jì)劃和評(píng)估分析是否是優(yōu)化的SQL。一般的20%的代碼占據(jù)了80%的資源，嚴(yán)重優(yōu)化的重點(diǎn)是這些慢的地方。
24、如果使用了IN或者OR等時(shí)發(fā)現(xiàn)查詢沒(méi)有走索引，使用顯示申明指定索引： Select * FROM PersonMember (INDEX = IX_Title) Where processid IN ('男'，'女')
25、將需要查詢的結(jié)果預(yù)先計(jì)算好放在表中，查詢的時(shí)候再Select。這在SQL7.0以前是最重要的手段。例如醫(yī)院的住院費(fèi)計(jì)算。
26、MIN() 和 MAX()能使用到合適的索引。
27、數(shù)據(jù)庫(kù)有一個(gè)原則是代碼離數(shù)據(jù)越近越好，所以優(yōu)先選擇Default,依次為Rules,Triggers, Constraint(約束如外健主健CheckUNIQUE……,數(shù)據(jù)類型的最大長(zhǎng)度等等都是約束),Procedure.這樣不僅維護(hù)工作小，編寫程序質(zhì)量高，并且執(zhí)行的速度快。
28、如果要插入大的二進(jìn)制值到Image列，使用存儲(chǔ)過(guò)程，千萬(wàn)不要用內(nèi)嵌Insert來(lái)插入(不知JAVA是否)。因?yàn)檫@樣應(yīng)用程序首先將二進(jìn)制值轉(zhuǎn)換成字符串(尺寸是它的兩倍)，服務(wù)器受到字符后又將他轉(zhuǎn)換成二進(jìn)制值.存儲(chǔ)過(guò)程就沒(méi)有這些動(dòng)作: 方法：Create procedure p_insert as insert into table(Fimage) values (@image), 在前臺(tái)調(diào)用這個(gè)存儲(chǔ)過(guò)程傳入二進(jìn)制參數(shù)，這樣處理速度明顯改善。
29、Between在某些時(shí)候比IN 速度更快,Between能夠更快地根據(jù)索引找到范圍。用查詢優(yōu)化器可見(jiàn)到差別。 select * from chineseresume where title in ('男','女') Select * from chineseresume where between '男' and '女' 是一樣的。由于in會(huì)在比較多次，所以有時(shí)會(huì)慢些。
30、在必要是對(duì)全局或者局部臨時(shí)表創(chuàng)建索引，有時(shí)能夠提高速度，但不是一定會(huì)這樣，因?yàn)樗饕埠馁M(fèi)大量的資源。他的創(chuàng)建同是實(shí)際表一樣。
31、不要建沒(méi)有作用的事物例如產(chǎn)生報(bào)表時(shí)，浪費(fèi)資源。只有在必要使用事物時(shí)使用它。
32、用OR的字句可以分解成多個(gè)查詢，并且通過(guò)UNION 連接多個(gè)查詢。他們的速度只同是否使用索引有關(guān),如果查詢需要用到聯(lián)合索引，用UNION all執(zhí)行的效率更高.多個(gè)OR的字句沒(méi)有用到索引，改寫成UNION的形式再試圖與索引匹配。一個(gè)關(guān)鍵的問(wèn)題是否用到索引。
33、盡量少用視圖，它的效率低。對(duì)視圖操作比直接對(duì)表操作慢,可以用stored procedure來(lái)代替她。特別的是不要用視圖嵌套,嵌套視圖增加了尋找原始資料的難度。我們看視圖的本質(zhì)：它是存放在服務(wù)器上的被優(yōu)化好了的已經(jīng)產(chǎn)生了查詢規(guī)劃的SQL。對(duì)單個(gè)表檢索數(shù)據(jù)時(shí)，不要使用指向多個(gè)表的視圖，直接從表檢索或者僅僅包含這個(gè)表的視圖上讀，否則增加了不必要的開(kāi)銷,查詢受到干擾.為了加快視圖的查詢，MsSQL增加了視圖索引的功能。
34、沒(méi)有必要時(shí)不要用DISTINCT和ORDER BY，這些動(dòng)作可以改在客戶端執(zhí)行。它們?cè)黾恿祟~外的開(kāi)銷。這同UNION 和UNION ALL一樣的道理。
select top 20 ad.companyname,comid,position,ad.referenceid,worklocation, convert(varchar(10),ad.postDate,120) as postDate1,workyear,degreedescription FROM jobcn_query.dbo.COMPANYAD_query ad where referenceID in('JCNAD00329667','JCNAD132168','JCNAD00337748','JCNAD00338345',
83 <!---->
'JCNAD00333138','JCNAD00303570','JCNAD00303569',
'JCNAD00303568','JCNAD00306698','JCNAD00231935','JCNAD00231933',
'JCNAD00254567','JCNAD00254585','JCNAD00254608',
'JCNAD00254607','JCNAD00258524','JCNAD00332133','JCNAD00268618',
'JCNAD00279196','JCNAD00268613') order by postdate desc
35、在IN后面值的列表中，將出現(xiàn)最頻繁的值放在最前面，出現(xiàn)得最少的放在最后面，減少判斷的次數(shù)。
36、當(dāng)用Select INTO時(shí)，它會(huì)鎖住系統(tǒng)表(sysobjects，sysindexes等等)，阻塞其他的連接的存取。創(chuàng)建臨時(shí)表時(shí)用顯示申明語(yǔ)句，而不是 select INTO. drop table t_lxh begin tran select * into t_lxh from chineseresume where name = 'XYZ' --commit 在另一個(gè)連接中Select * from sysobjects可以看到 Select INTO 會(huì)鎖住系統(tǒng)表，Create table 也會(huì)鎖系統(tǒng)表(不管是臨時(shí)表還是系統(tǒng)表)。所以千萬(wàn)不要在事物內(nèi)使用它!!!這樣的話如果是經(jīng)常要用的臨時(shí)表請(qǐng)使用實(shí)表，或者臨時(shí)表變量。
37、一般在GROUP BY 個(gè)HAVING字句之前就能剔除多余的行，所以盡量不要用它們來(lái)做剔除行的工作。他們的執(zhí)行順序應(yīng)該如下最優(yōu)：select 的Where字句選擇所有合適的行，Group By用來(lái)分組個(gè)統(tǒng)計(jì)行，Having字句用來(lái)剔除多余的分組。這樣Group By 個(gè)Having的開(kāi)銷小，查詢快.對(duì)于大的數(shù)據(jù)行進(jìn)行分組和Having十分消耗資源。如果Group BY的目的不包括計(jì)算，只是分組，那么用Distinct更快
38、一次更新多條記錄比分多次更新每次一條快,就是說(shuō)批處理好
39、少用臨時(shí)表，盡量用結(jié)果集和Table類性的變量來(lái)代替它,Table 類型的變量比臨時(shí)表好
40、在SQL2000下，計(jì)算字段是可以索引的，需要滿足的條件如下：
a、計(jì)算字段的表達(dá)是確定的
b、不能用在TEXT,Ntext，Image數(shù)據(jù)類型
c、必須配制如下選項(xiàng) ANSI_NULLS = ON, ANSI_PADDINGS = ON, …….
41、盡量將數(shù)據(jù)的處理工作放在服務(wù)器上，減少網(wǎng)絡(luò)的開(kāi)銷，如使用存儲(chǔ)過(guò)程。存儲(chǔ)過(guò)程是編譯好、優(yōu)化過(guò)、并且被組織到一個(gè)執(zhí)行規(guī)劃里、且存儲(chǔ)在數(shù)據(jù)庫(kù)中的SQL語(yǔ)句，是控制流語(yǔ)言的集合，速度當(dāng)然快。反復(fù)執(zhí)行的動(dòng)態(tài)SQL,可以使用臨時(shí)存儲(chǔ)過(guò)程，該過(guò)程(臨時(shí)表)被放在Tempdb中。以前由于SQL SERVER對(duì)復(fù)雜的數(shù)學(xué)計(jì)算不支持，所以不得不將這個(gè)工作放在其他的層上而增加網(wǎng)絡(luò)的開(kāi)銷。SQL2000支持UDFs,現(xiàn)在支持復(fù)雜的數(shù)學(xué)計(jì)算，函數(shù)的返回值不要太大，這樣的開(kāi)銷很大。用戶自定義函數(shù)象光標(biāo)一樣執(zhí)行的消耗大量的資源，如果返回大的結(jié)果采用存儲(chǔ)過(guò)程
42、不要在一句話里再三的使用相同的函數(shù)，浪費(fèi)資源,將結(jié)果放在變量里再調(diào)用更快
43、Select COUNT(*)的效率教低，盡量變通他的寫法，而EXISTS快.同時(shí)請(qǐng)注意區(qū)別： select count(Field of null) from Table 和 select count(Field of NOT null) from Table 的返回值是不同的!!!
44、當(dāng)服務(wù)器的內(nèi)存夠多時(shí)，配制線程數(shù)量 = 最大連接數(shù)+5，這樣能發(fā)揮最大的效率;否則使用 配制線程數(shù)量<最大連接數(shù)啟用SQL SERVER的線程池來(lái)解決,如果還是數(shù)量 = 最大連接數(shù)+5，嚴(yán)重的損害服務(wù)器的性能。
45、按照一定的次序來(lái)訪問(wèn)你的表。如果你先鎖住表A，再鎖住表B，那么在所有的存儲(chǔ)過(guò)程中都要按照這個(gè)順序來(lái)鎖定它們。如果你(不經(jīng)意的)某個(gè)存儲(chǔ)過(guò)程中先鎖定表B，再鎖定表A，這可能就會(huì)導(dǎo)致一個(gè)死鎖。如果鎖定順序沒(méi)有被預(yù)先詳細(xì)的設(shè)計(jì)好，死鎖很難被發(fā)現(xiàn)
46、通過(guò)SQL Server Performance Monitor監(jiān)視相應(yīng)硬件的負(fù)載 Memory: Page Faults / sec計(jì)數(shù)器如果該值偶爾走高，表明當(dāng)時(shí)有線程競(jìng)爭(zhēng)內(nèi)存。如果持續(xù)很高，則內(nèi)存可能是瓶頸。
Process:
1、% DPC Time 指在范例間隔期間處理器用在緩延程序調(diào)用(DPC)接收和提供服務(wù)的百分比。(DPC 正在運(yùn)行的為比標(biāo)準(zhǔn)間隔優(yōu)先權(quán)低的間隔)。 由于 DPC 是以特權(quán)模式執(zhí)行的，DPC 時(shí)間的百分比為特權(quán)時(shí)間百分比的一部分。這些時(shí)間單獨(dú)計(jì)算并且不屬于間隔計(jì)算總數(shù)的一部 分。這個(gè)總數(shù)顯示了作為實(shí)例時(shí)間百分比的平均忙時(shí)。
2、%Processor Time計(jì)數(shù)器 如果該參數(shù)值持續(xù)超過(guò)95%，表明瓶頸是CPU?？梢钥紤]增加一個(gè)處理器或換一個(gè)更快的處理器。
3、% Privileged Time 指非閑置處理器時(shí)間用于特權(quán)模式的百分比。(特權(quán)模式是為操作系統(tǒng)組件和操縱硬件驅(qū)動(dòng)程序而設(shè)計(jì)的一種處理模式。它允許直接訪問(wèn)硬件和所有內(nèi)存。另一種模式為用戶模式，它是一種為應(yīng)用程序、環(huán)境分系統(tǒng)和整數(shù)分系統(tǒng)設(shè)計(jì)的一種有限處理模式。操作系統(tǒng)將應(yīng)用程序線程轉(zhuǎn)換成特權(quán)模式以訪問(wèn)操作系統(tǒng)服務(wù))。特權(quán)時(shí)間的 % 包括為間斷和 DPC 提供服務(wù)的時(shí)間。特權(quán)時(shí)間比率高可能是由于失敗設(shè)備產(chǎn)生的大數(shù)量的間隔而引起的。這個(gè)計(jì)數(shù)器將平均忙時(shí)作為樣本時(shí)間的一部分顯示。
4、% User Time表示耗費(fèi)CPU的數(shù)據(jù)庫(kù)操作，如排序，執(zhí)行aggregate functions等。如果該值很高，可考慮增加索引，盡量使用簡(jiǎn)單的表聯(lián)接，水平分割大表格等方法來(lái)降低該值。 Physical Disk: Curretn Disk Queue Length計(jì)數(shù)器該值應(yīng)不超過(guò)磁盤數(shù)的1.5~2倍。要提高性能，可增加磁盤。 SQLServer:Cache Hit Ratio計(jì)數(shù)器該值越高越好。如果持續(xù)低于80%，應(yīng)考慮增加內(nèi)存。 注意該參數(shù)值是從SQL Server啟動(dòng)后，就一直累加記數(shù)，所以運(yùn)行經(jīng)過(guò)一段時(shí)間后，該值將不能反映系統(tǒng)當(dāng)前值。
84 <!---->
47、分析select emp_name form employee where salary > 3000 在此語(yǔ)句中若salary是Float類型的，則優(yōu)化器對(duì)其進(jìn)行優(yōu)化為Convert(float,3000)，因?yàn)?000是個(gè)整數(shù)，我們應(yīng)在編程時(shí)使用3000.0而不要等運(yùn)行時(shí)讓DBMS進(jìn)行轉(zhuǎn)化。同樣字符和整型數(shù)據(jù)的轉(zhuǎn)換。
48、查詢的關(guān)聯(lián)同寫的順序
select a.personMemberID, * from chineseresume a,personmember b where personMemberID = b.referenceid and a.personMemberID = 'JCNPRH39681' （A = B ,B = '號(hào)碼'）
select a.personMemberID, * from chineseresume a,personmember b where a.personMemberID = b.referenceid and a.personMemberID = 'JCNPRH39681' and b.referenceid = 'JCNPRH39681' （A = B ,B = '號(hào)碼'， A = '號(hào)碼'）
select a.personMemberID, * from chineseresume a,personmember b where b.referenceid = 'JCNPRH39681' and a.personMemberID = 'JCNPRH39681' （B = '號(hào)碼'， A = '號(hào)碼'）
49、
(1)IF 沒(méi)有輸入負(fù)責(zé)人代碼 THEN code1=0 code2=9999 ELSE code1=code2=負(fù)責(zé)人代碼 END IF 執(zhí)行SQL語(yǔ)句為: Select 負(fù)責(zé)人名 FROM P2000 Where 負(fù)責(zé)人代碼>=:code1 AND負(fù)責(zé)人代碼 <=:code2
<clk></clk> (2)IF 沒(méi)有輸入負(fù)責(zé)人代碼 THEN Select 負(fù)責(zé)人名 FROM P2000 ELSE code= 負(fù)責(zé)人代碼 Select 負(fù)責(zé)人代碼 FROM P2000 Where 負(fù)責(zé)人代碼=:code END IF 第一種方法只用了一條SQL語(yǔ)句,第二種方法用了兩條SQL語(yǔ)句。在沒(méi)有輸入負(fù)責(zé)人代碼時(shí),第二種方法顯然比第一種方法執(zhí)行效率高,因?yàn)樗鼪](méi)有限制條件; 在輸入了負(fù)責(zé)人代碼時(shí),第二種方法仍然比第一種方法效率高,不僅是少了一個(gè)限制條件,還因相等運(yùn)算是最快的查詢運(yùn)算。我們寫程序不要怕麻煩
50、關(guān)于JOBCN現(xiàn)在查詢分頁(yè)的新方法(如下)，用性能優(yōu)化器分析性能的瓶頸，如果在I/O或者網(wǎng)絡(luò)的速度上，如下的方法優(yōu)化切實(shí)有效，如果在CPU或者內(nèi)存上，用現(xiàn)在的方法更好。請(qǐng)區(qū)分如下的方法，說(shuō)明索引越小越好。
begin
DECLARE @local_variable table (FID int identity(1,1),ReferenceID varchar(20))
insert into @local_variable (ReferenceID)
select top 100000 ReferenceID from chineseresume order by ReferenceID
select * from @local_variable where Fid > 40 and fid <= 60
end 和
begin
DECLARE @local_variable table (FID int identity(1,1),ReferenceID varchar(20))
insert into @local_variable (ReferenceID)
select top 100000 ReferenceID from chineseresume order by updatedate
select * from @local_variable where Fid > 40 and fid <= 60
end 的不同
begin
create table #temp (FID int identity(1,1),ReferenceID varchar(20))
insert into #temp (ReferenceID)
select top 100000 ReferenceID from chineseresume order by updatedate
select * from #temp where Fid > 40 and fid <= 60 drop table #temp
end
另附：存儲(chǔ)過(guò)程編寫經(jīng)驗(yàn)和優(yōu)化措施 From：網(wǎng)頁(yè)教學(xué)網(wǎng)
一、適合讀者對(duì)象：數(shù)據(jù)庫(kù)開(kāi)發(fā)程序員，數(shù)據(jù)庫(kù)的數(shù)據(jù)量很多，涉及到對(duì)SP(存儲(chǔ)過(guò)程)的優(yōu)化的項(xiàng)目開(kāi)發(fā)人員，對(duì)數(shù)據(jù)庫(kù)有濃厚興趣的人。
二、介紹：在數(shù)據(jù)庫(kù)的開(kāi)發(fā)過(guò)程中，經(jīng)常會(huì)遇到復(fù)雜的業(yè)務(wù)邏輯和對(duì)數(shù)據(jù)庫(kù)的操作，這個(gè)時(shí)候就會(huì)用SP來(lái)封裝數(shù)據(jù)庫(kù)操作。如果項(xiàng)目的SP較多，書寫又沒(méi)有一定的規(guī)范，將會(huì)影響以后的系統(tǒng)維護(hù)困難和大SP邏輯的難以理解，另外如果數(shù)據(jù)庫(kù)的數(shù)據(jù)量大或者項(xiàng)目對(duì)SP的性能要求很，就會(huì)遇到優(yōu)化的問(wèn)題，否則速度有可能很慢，經(jīng)過(guò)親身經(jīng)驗(yàn)，一個(gè)經(jīng)過(guò)優(yōu)化過(guò)的SP要比一個(gè)性能差的SP的效率甚至高幾百倍。
三、內(nèi)容：
1、開(kāi)發(fā)人員如果用到其他庫(kù)的Table或View，務(wù)必在當(dāng)前庫(kù)中建立View來(lái)實(shí)現(xiàn)跨庫(kù)操作，最好不要直接使用“databse.dbo.table_name”，因?yàn)閟p_depends不能顯示出該SP所使用的跨庫(kù)table或view，不方便校驗(yàn)。
2、開(kāi)發(fā)人員在提交SP前，必須已經(jīng)使用set showplan on分析過(guò)查詢計(jì)劃，做過(guò)自身的查詢優(yōu)化檢查。
3、高程序運(yùn)行效率，優(yōu)化應(yīng)用程序，在SP編寫過(guò)程中應(yīng)該注意以下幾點(diǎn)：
a)SQL的使用規(guī)范：
i. 盡量避免大事務(wù)操作，慎用holdlock子句，提高系統(tǒng)并發(fā)能力。
ii. 盡量避免反復(fù)訪問(wèn)同一張或幾張表，尤其是數(shù)據(jù)量較大的表，可以考慮先根據(jù)條件提取數(shù)據(jù)到臨時(shí)表中，然后再做連接。
iii. 盡量避免使用游標(biāo)，因?yàn)橛螛?biāo)的效率較差，如果游標(biāo)操作的數(shù)據(jù)超過(guò)1萬(wàn)行，那么就應(yīng)該改寫;如果使用了游標(biāo)，就要盡量避免在游標(biāo)循環(huán)中再進(jìn)行表連接的操作。
iv. 注意where字句寫法，必須考慮語(yǔ)句順序，應(yīng)該根據(jù)索引順序、范圍大小來(lái)確定條件子句的前后順序，盡可能的讓字段順序與索引順序相一致，范圍從大到小。
v. 不要在where子句中的“=”左邊進(jìn)行函數(shù)、算術(shù)運(yùn)算或其他表達(dá)式運(yùn)算，否則系統(tǒng)將可能無(wú)法正確使用索引。
vi. 盡量使用exists代替select count(1)來(lái)判斷是否存在記錄，count函數(shù)只有在統(tǒng)計(jì)表中所有行數(shù)時(shí)使用，而且count(1)比count(*)更有效率。
vii. 盡量使用“>=”，不要使用“>”。
viii. 注意一些or子句和union子句之間的替換
ix. 注意表之間連接的數(shù)據(jù)類型，避免不同類型數(shù)據(jù)之間的連接。
x. 注意存儲(chǔ)過(guò)程中參數(shù)和數(shù)據(jù)類型的關(guān)系。
xi. 注意insert、update操作的數(shù)據(jù)量，防止與其他應(yīng)用沖突。如果數(shù)據(jù)量超過(guò)200個(gè)數(shù)據(jù)頁(yè)面(400k)，那么系統(tǒng)將會(huì)進(jìn)行鎖升級(jí)，頁(yè)級(jí)鎖會(huì)升級(jí)成表級(jí)鎖。
b)索引的使用規(guī)范：
i. 索引的創(chuàng)建要與應(yīng)用結(jié)合考慮，建議大的OLTP表不要超過(guò)6個(gè)索引。
ii. 盡可能的使用索引字段作為查詢條件，尤其是聚簇索引，必要時(shí)可以通過(guò)index index_name來(lái)強(qiáng)制指定索引
iii. 避免對(duì)大表查詢時(shí)進(jìn)行table scan，必要時(shí)考慮新建索引。
iv. 在使用索引字段作為條件時(shí)，如果該索引是聯(lián)合索引，那么必須使用到該索引中的第一個(gè)字段作為條件時(shí)才能保證系統(tǒng)使用該索引，否則該索引將不會(huì)被使用。
v. 要注意索引的維護(hù)，周期性重建索引，重新編譯存儲(chǔ)過(guò)程。
c)tempdb的使用規(guī)范：
i. 盡量避免使用distinct、order by、group by、having、join、cumpute，因?yàn)檫@些語(yǔ)句會(huì)加重tempdb的負(fù)擔(dān)。
ii. 避免頻繁創(chuàng)建和刪除臨時(shí)表，減少系統(tǒng)表資源的消耗。
iii. 在新建臨時(shí)表時(shí)，如果一次性插入數(shù)據(jù)量很大，那么可以使用select into代替create table，避免log，提高速度;如果數(shù)據(jù)量不大，為了緩和系統(tǒng)表的資源，建議先create table，然后insert。
iv. 如果臨時(shí)表的數(shù)據(jù)量較大，需要建立索引，那么應(yīng)該將創(chuàng)建臨時(shí)表和建立索引的過(guò)程放在單獨(dú)一個(gè)子存儲(chǔ)過(guò)程中，這樣才能保證系統(tǒng)能夠很好的使用到該臨時(shí)表的索引。
v. 如果使用到了臨時(shí)表，在存儲(chǔ)過(guò)程的最后務(wù)必將所有的臨時(shí)表顯式刪除，先truncate table，然后drop table，這樣可以避免系統(tǒng)表的較長(zhǎng)時(shí)間鎖定。
vi. 慎用大的臨時(shí)表與其他大表的連接查詢和修改，減低系統(tǒng)表負(fù)擔(dān)，因?yàn)檫@種操作會(huì)在一條語(yǔ)句中多次使用tempdb的系統(tǒng)表。
d)合理的算法使用：
根據(jù)上面已提到的SQL優(yōu)化技術(shù)和ASE Tuning手冊(cè)中的SQL優(yōu)化內(nèi)容,結(jié)合實(shí)際應(yīng)用,采用多種算法進(jìn)行比較,以獲得消耗資源最少、效率最高的方法。具體可用ASE調(diào)優(yōu)命令：set statistics io on, set statistics time on , set showplan on 等。
轉(zhuǎn)自：http://fableking.iteye.com/blog/360900
posted @
2011-08-13 12:41 [ 王志偉 ] 閱讀(286) |
評(píng)論 (0) |
編輯 收藏千萬(wàn)人同時(shí)訪問(wèn)的網(wǎng)站，一般是有很多個(gè)數(shù)據(jù)庫(kù)同時(shí)工作，說(shuō)明白一點(diǎn)就是數(shù)據(jù)庫(kù)集群和并發(fā)控制，這樣的網(wǎng)站實(shí)時(shí)性也是相對(duì)的。這些網(wǎng)站都有一些共同的特點(diǎn)：數(shù)據(jù)量大，在線人數(shù)多，并發(fā)請(qǐng)求多，pageview高，響應(yīng)速度快?？偨Y(jié)了一下各個(gè)大網(wǎng)站的架構(gòu)，主要提高效率及穩(wěn)定性的幾個(gè)地方包括：
1、程序
程序開(kāi)發(fā)是一方面，系統(tǒng)架構(gòu)設(shè)計(jì)（硬件+網(wǎng)絡(luò)+軟件）是另一方面。
軟件架構(gòu)方面，做網(wǎng)站首先需要很多web服務(wù)器存儲(chǔ)靜態(tài)資源，比如圖片、視頻、靜態(tài)頁(yè)等，千萬(wàn)不要把靜態(tài)資源和應(yīng)用服務(wù)器放在一起。
一個(gè)好的程序員寫出來(lái)的程序會(huì)非常簡(jiǎn)潔、性能很好，一個(gè)初級(jí)程序員可能會(huì)犯很多低級(jí)錯(cuò)誤，這也是影響網(wǎng)站性能的原因之一。
網(wǎng)站要做到效率高，不光是程序員的事情，數(shù)據(jù)庫(kù)優(yōu)化、程序優(yōu)化這是必須的，在性能優(yōu)化上要數(shù)據(jù)庫(kù)和程序齊頭并進(jìn)！緩存也是兩方面同時(shí)入手。第一，數(shù)據(jù)庫(kù)緩存和數(shù)據(jù)庫(kù)優(yōu)化，這個(gè)由dba完成（而且這個(gè)有非常大的潛力可挖，只是由于我們都是程序員而忽略了他而已）。第二，程序上的優(yōu)化，這個(gè)非常的有講究，比如說(shuō)重要一點(diǎn)就是要規(guī)范ＳＱＬ語(yǔ)句，少用in 多用or，多用preparestatement 存儲(chǔ)過(guò)程，另外避免程序冗余如查找數(shù)據(jù)少用雙重循環(huán)等。另外選用優(yōu)秀的開(kāi)源框架加以支持，我個(gè)人認(rèn)為中后臺(tái)的支持是最最重要的，可以選取spring＋ibatis。因?yàn)閕batis直接操作SQL并有緩存機(jī)制。spring的好處就不用我多說(shuō)了，ＩＯＣ的機(jī)制可以避免new對(duì)象，這樣也節(jié)省開(kāi)銷。據(jù)我分析，絕大部分的開(kāi)銷就是在NEW的時(shí)候和連接數(shù)據(jù)庫(kù)時(shí)候產(chǎn)生的，請(qǐng)盡量避免。另外可以用一些內(nèi)存測(cè)試工具來(lái)做一個(gè)demo說(shuō)明hibernate和ibatis誰(shuí)更快！前臺(tái)你想用什么就用什么，struts,webwork都成，如果覺(jué)得自己挺牛X可以試試用tapestry。
用數(shù)據(jù)庫(kù)也未必不能解決訪問(wèn)量巨大所帶來(lái)的問(wèn)題，作成靜態(tài)文件硬盤的尋址時(shí)間也未必少于數(shù)據(jù)庫(kù)的搜索時(shí)間，當(dāng)然對(duì)資料的索引要下一翻工夫。我自己覺(jué)得門戶往往也就是當(dāng)天、熱門的資料點(diǎn)擊率較高，將其做緩存最多也不過(guò)1~2G的數(shù)據(jù)量吧，舉個(gè)例子：
◎ 拿網(wǎng)易新聞來(lái)說(shuō)http://news.163.com/07/0606/09/3GA0D10N00011229.html
格式化一下，方便理解：http://域名/年/月日/新聞所屬分類/新聞ID.html
可以把當(dāng)天發(fā)布的、熱門的、瀏覽量大的作個(gè)緩存，用hashtable（key：年-月-日-分類-ID，value：新聞對(duì)象），靜態(tài)將其放到內(nèi)存（速度絕對(duì)快過(guò)硬盤尋址靜態(tài)頁(yè)面）。
通常是采用oracle存儲(chǔ)過(guò)程＋2個(gè)weblogic，更新機(jī)制也幾乎一樣每簽發(fā)一條新聞，就會(huì)生成靜態(tài)頁(yè)面，然后發(fā)往前端的web服務(wù)器，前端的web都是做負(fù)載均衡的。另外還有定時(shí)程序，每5-15分鐘自動(dòng)生成一次。在發(fā)布新聞的同時(shí)將數(shù)據(jù)緩存。當(dāng)然緩存也不會(huì)越來(lái)越大，在個(gè)特定的時(shí)間段（如凌晨）刪除過(guò)期的數(shù)據(jù)。做一個(gè)大的網(wǎng)站遠(yuǎn)沒(méi)有想象中那么簡(jiǎn)單，服務(wù)器基本就要百十個(gè)的。
這樣可以大大增加一臺(tái)計(jì)算機(jī)的處理速度，如果一臺(tái)機(jī)器處理不了，可以用httpserver集群來(lái)解決問(wèn)題了。
2、網(wǎng)絡(luò)
中國(guó)的網(wǎng)絡(luò)分南電信和北網(wǎng)通，訪問(wèn)的ip就要區(qū)分南北進(jìn)入不同的網(wǎng)絡(luò)。
3、集群
通常會(huì)使用CDN與GSBL與DNS負(fù)載均衡技術(shù)，每個(gè)地區(qū)一組前臺(tái)服務(wù)器群，比如新浪和搜狐，而網(wǎng)易，百度使用了DNS負(fù)載均衡技術(shù)，每個(gè)頻道一組前臺(tái)服務(wù)器；一搜使用了DNS負(fù)載技術(shù)，所有頻道共用一組前臺(tái)服務(wù)器集群。
網(wǎng)站使用基于Linux集群的負(fù)載均衡，失敗恢復(fù)，包括應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器，基于linux-ha的服務(wù)狀態(tài)檢測(cè)及高可用化。
應(yīng)用服務(wù)器集群可以采用apache+tomcat集群和weblogic集群等；web服務(wù)器集群可以用反向代理，也可以用NAT的方式，或者多域名解析都可以；Squid也可以，方法很多，可以根據(jù)情況選擇。
4、數(shù)據(jù)庫(kù)
因?yàn)槭乔f(wàn)人同時(shí)訪問(wèn)的網(wǎng)站，所以一般是有很多個(gè)數(shù)據(jù)庫(kù)同時(shí)工作的，說(shuō)明白一點(diǎn)就是數(shù)據(jù)庫(kù)集群和并發(fā)控制，數(shù)據(jù)分布到地理位置不同的數(shù)據(jù)中心，以免發(fā)生斷電事故。
主流的數(shù)據(jù)庫(kù)有Sun的是MySQL和Oracle。
Oracle是一款優(yōu)秀的、廣泛采用的商業(yè)數(shù)據(jù)庫(kù)管理軟件。有很強(qiáng)大的功能和安全性，可以處理相對(duì)海量的數(shù)據(jù)。而MySQL是一款非常優(yōu)秀的開(kāi)源數(shù)據(jù)庫(kù)管理軟件，非常適合用多臺(tái)PC Server組成多點(diǎn)的存儲(chǔ)節(jié)點(diǎn)陣列(這里我所指的不是MySQL自身提供的集群功能)，每單位的數(shù)據(jù)存儲(chǔ)成本也非常的低廉。用多臺(tái)PC Server安裝MySQL組成一個(gè)存儲(chǔ)節(jié)點(diǎn)陣列，通過(guò)MySQL自身的Replication或者應(yīng)用自身的處理，可以很好的保證容錯(cuò)(允許部分節(jié)點(diǎn)失效)，保證應(yīng)用的健壯性和可靠性?？梢赃@么說(shuō)，在關(guān)系數(shù)據(jù)庫(kù)管理系統(tǒng)的選擇上，可以考慮應(yīng)用本身的情況來(lái)決定。
MySQL數(shù)據(jù)庫(kù)服務(wù)器的master-slave模式，利用數(shù)據(jù)庫(kù)服務(wù)器在主從服務(wù)器間進(jìn)行同步，應(yīng)用只把數(shù)據(jù)寫到主服務(wù)器，而讀數(shù)據(jù)時(shí)則根據(jù)負(fù)載選擇一臺(tái)從服務(wù)器或者主服務(wù)器來(lái)讀取，將數(shù)據(jù)按不同策略劃分到不同的服務(wù)器（組）上，分散數(shù)據(jù)庫(kù)壓力。
另外還有一點(diǎn)的是，那些網(wǎng)站的靜態(tài)化網(wǎng)頁(yè)并不是真的，而是通過(guò)動(dòng)態(tài)網(wǎng)頁(yè)與靜態(tài)網(wǎng)頁(yè)網(wǎng)址交換所出現(xiàn)的假象，這可以用urlrewrite這樣的開(kāi)源網(wǎng)址映射器實(shí)現(xiàn)。這樣的網(wǎng)站實(shí)時(shí)性也是相對(duì)的，因?yàn)樵跀?shù)據(jù)庫(kù)復(fù)制數(shù)據(jù)的時(shí)候有一個(gè)過(guò)程，一般在技術(shù)上可以用到hibernate和ecache，但是如果要使網(wǎng)站工作地更好，可以使用EJB和websphere，weblogic這樣大型的服務(wù)器來(lái)支持，并且要用oracle這樣的大型數(shù)據(jù)庫(kù)。
大型門戶網(wǎng)站不建議使用Mysql數(shù)據(jù)庫(kù)，除非你對(duì)Mysql數(shù)據(jù)的優(yōu)化非常熟悉。Mysql數(shù)據(jù)庫(kù)服務(wù)器的master-slave模式，利用數(shù)據(jù)庫(kù)服務(wù)器在主從服務(wù)器間進(jìn)行同步，應(yīng)用只把數(shù)據(jù)寫到主服務(wù)器，而讀數(shù)據(jù)時(shí)則根據(jù)負(fù)載選擇一臺(tái)從服務(wù)器或者主服務(wù)器來(lái)讀取，將數(shù)據(jù)按不同策略劃分到不同的服務(wù)器（組）上，分散數(shù)據(jù)庫(kù)壓力。
大型網(wǎng)站要用oracle，數(shù)據(jù)方面操作盡量多用存儲(chǔ)過(guò)程，絕對(duì)提升性能；同時(shí)要讓DBA對(duì)數(shù)據(jù)庫(kù)進(jìn)行優(yōu)化，優(yōu)化后的數(shù)據(jù)庫(kù)與沒(méi)優(yōu)化的有天壤之別；同時(shí)還可以擴(kuò)展分布式數(shù)據(jù)庫(kù)，以后這方面的研究會(huì)越來(lái)越多；
5、頁(yè)面
從開(kāi)始就考慮使用虛擬存儲(chǔ)/簇文件系統(tǒng)。它能讓你大量并行IO訪問(wèn)，而且不需要任何重組就能夠增加所需要的磁盤。
頁(yè)面數(shù)據(jù)調(diào)用更要認(rèn)真設(shè)計(jì)，一些數(shù)據(jù)查詢可以不通過(guò)數(shù)據(jù)庫(kù)的方式，實(shí)時(shí)性要求不高的可以使用lucene來(lái)實(shí)現(xiàn)，即使有實(shí)時(shí)性的要求也可以用lucene（基于Java的全文索引/檢索引擎），lucene+compass還是非常優(yōu)秀的。
新聞?lì)惖木W(wǎng)站可以用靜態(tài)頁(yè)存儲(chǔ)，采用定時(shí)更新機(jī)制減輕服務(wù)器負(fù)擔(dān)；首頁(yè)每個(gè)小模塊可以使用oscache緩存，這樣不用每次都拉數(shù)據(jù)。
前端的基于靜態(tài)頁(yè)面緩存的web加速器，主要應(yīng)用有squid等。squid 將大部分靜態(tài)資源(圖片，js，css等）緩存起來(lái)，直接返回給訪問(wèn)者，減少應(yīng)用服務(wù)器的負(fù)載
網(wǎng)站的靜態(tài)化網(wǎng)頁(yè)并不是真的，而是通過(guò)動(dòng)態(tài)網(wǎng)頁(yè)與靜態(tài)網(wǎng)頁(yè)網(wǎng)址交換做出現(xiàn)的假象，這可以用urlrewrite這樣的開(kāi)源網(wǎng)址映射器實(shí)現(xiàn)，后綴名為htm或者h(yuǎn)tml并不能說(shuō)明程序生成了靜態(tài)頁(yè)面，可能是通過(guò)url重寫來(lái)實(shí)現(xiàn)的，為的只不過(guò)是在搜索引擎中提升自己網(wǎng)站的覆蓋面積罷了。
生成靜態(tài)頁(yè)面的服務(wù)器和www服務(wù)器是兩組不同的服務(wù)器，頁(yè)面生成后才會(huì)到www服務(wù)器，一部分?jǐn)?shù)據(jù)庫(kù)并不是關(guān)系數(shù)據(jù)庫(kù)，這樣更適合信息衍生，www、mail服務(wù)器、路由器多，主要用負(fù)載平衡解決訪問(wèn)瓶頸。
◎ 靜態(tài)頁(yè)面的缺點(diǎn)：
1) 增加了程序的復(fù)雜度
2) 不利于管理資料
3) 速度不是最快
4) 傷硬盤
6、緩存
從一開(kāi)始就應(yīng)該使用緩存，高速緩存是一個(gè)更好的地方存儲(chǔ)臨時(shí)數(shù)據(jù)，比如Web站點(diǎn)上跟蹤一個(gè)特定用戶的會(huì)話產(chǎn)生的臨時(shí)文件，就不再需要記錄到數(shù)據(jù)庫(kù)里。
不能用lucene實(shí)現(xiàn)的可以用緩存，分布式緩存可以用memcached，如果有錢的話用10來(lái)臺(tái)機(jī)器做緩存，> 10G的存儲(chǔ)量相信存什么都?jí)蛄耍蝗绻麤](méi)錢的話可以在頁(yè)面緩存和數(shù)據(jù)緩存上下功夫，多用OSCACHE和EHCACHE，SWARMCACHE也可以，不過(guò)據(jù)說(shuō)同步性不是很好；
可以使用Memcache（分布式緩存）進(jìn)行緩存，用大內(nèi)存把這些不變的數(shù)據(jù)全都緩存起來(lái)，而當(dāng)修改時(shí)就通知cache過(guò)期，memcache是LJ開(kāi)發(fā)的一款分布式緩存產(chǎn)品，很多大型網(wǎng)站在應(yīng)用，我們可以把Cache Server與App Server裝在一起。因?yàn)镃ache Server對(duì)CPU消耗不大，而有了Cache Server的支援，App Server對(duì)內(nèi)存要求也不是太高，所以可以和平共處，更有效的利用資源。
單機(jī)內(nèi)存緩存、文件緩存、數(shù)據(jù)庫(kù)緩存等的策略都是可以很簡(jiǎn)單的實(shí)現(xiàn)的，例如可以使用微軟的Caching Application Block，但如何在集群環(huán)境中使多個(gè)緩存、多層緩存并保存同步是個(gè)重大問(wèn)題。大型網(wǎng)站一般都使用緩存服務(wù)器群，并使用多層緩存。業(yè)內(nèi)最常用的有：
Squid cache，Squid服務(wù)器群，把它作為web服務(wù)器端前置cache服務(wù)器緩存相關(guān)請(qǐng)求來(lái)提高web服務(wù)器速度。Squid將大部分靜態(tài)資源(圖片，js，css等）緩存起來(lái)，直接返回給訪問(wèn)者，減少應(yīng)用服務(wù)器的負(fù)載
memcache，memcache服務(wù)器群，一款分布式緩存產(chǎn)品，很多大型網(wǎng)站在應(yīng)用; 它可以應(yīng)對(duì)任意多個(gè)連接，使用非阻塞的網(wǎng)絡(luò)IO。由于它的工作機(jī)制是在內(nèi)存中開(kāi)辟一塊空間，然后建立一個(gè)HashTable，Memcached自管理這些HashTable。因?yàn)橥ǔ＞W(wǎng)站應(yīng)用程序中最耗費(fèi)時(shí)間的任務(wù)是數(shù)據(jù)在數(shù)據(jù)庫(kù)的檢索，而多個(gè)用戶查詢相同的SQL時(shí)，數(shù)據(jù)庫(kù)壓力會(huì)增大，而通過(guò)memcache的查詢緩存命中，數(shù)據(jù)直接從memcache內(nèi)存中取，每次緩存命中將替換到數(shù)據(jù)庫(kù)服務(wù)器的一次往返，到達(dá)數(shù)據(jù)庫(kù)服務(wù)器的請(qǐng)求更少，間接地提高了數(shù)據(jù)庫(kù)服務(wù)器的性能，從而使應(yīng)用程序運(yùn)行得更快。它通過(guò)基于內(nèi)存緩存對(duì)象來(lái)減少數(shù)據(jù)庫(kù)查詢的方式改善網(wǎng)站系統(tǒng)的反應(yīng)，其最吸引人的一個(gè)特性就是支持分布式部署。有關(guān)memcache，以下文章可以參考：參考1，參考2，參考3官方站點(diǎn)。
e-Accelerator，比較特殊，PHP的緩存和加速器。是一個(gè)免費(fèi)開(kāi)源的PHP加速、優(yōu)化、編譯和動(dòng)態(tài)緩存的項(xiàng)目，它可以通過(guò)緩存PHP代碼編譯后的結(jié)果來(lái)提高PHP腳本的性能，使得一向很復(fù)雜和離我們很遠(yuǎn)的 PHP腳本編譯問(wèn)題完全得到解決。通過(guò)使用eAccelerator，可以優(yōu)化你的PHP代碼執(zhí)行速度，降低服務(wù)器負(fù)載，可以提高PHP應(yīng)用執(zhí)行速度最高達(dá)10倍。
7、服務(wù)器操作系統(tǒng)與Web服務(wù)器
最底層首先是操作系統(tǒng)。好的操作系統(tǒng)能提高好的性能、穩(wěn)定性和安全性，而這些對(duì)大型網(wǎng)站的性能、安全性和穩(wěn)定性都是至關(guān)重要的。
- 淘寶網(wǎng)（阿里巴巴）: Linux操作系統(tǒng) + Web 服務(wù)器: Apache
- 新浪：FreeBSD + Web 服務(wù)器：Apache
- Yahoo：FreeBSD + Web 服務(wù)器：自己的
- Google: 部分Linux + Web 服務(wù)器：自己的
- 百度：Linux + Web 服務(wù)器: Apache
- 網(wǎng)易：Linux + Web 服務(wù)器: Apache
- eBay: Windows Server 2003/8 (大量) + Web 服務(wù)器：Microsoft IIS
- MySpace: Windows Server 2003/8 + Web 服務(wù)器：Microsoft IIS
由此可見(jiàn)，開(kāi)源操作系統(tǒng)做Web應(yīng)用是首選已經(jīng)是一個(gè)既定事實(shí)。在開(kāi)源操作系統(tǒng)中Linux和FreeBSD差不太多，很難說(shuō)哪個(gè)一定比另外一個(gè)要優(yōu)秀很多、能夠全面的超越對(duì)手，應(yīng)該是各有所長(zhǎng)。但熟悉Linux的技術(shù)人員更多些，利于系統(tǒng)管理、優(yōu)化等，所以Linux使用更廣泛。而Windows Server和IIS雖然有的網(wǎng)站使用，但不開(kāi)源，而且需要購(gòu)買微軟的一系列應(yīng)用產(chǎn)品，限制了其使用。總之，開(kāi)源操作系統(tǒng)，尤其是Linux做Web應(yīng)用是首選已經(jīng)是一個(gè)既定事實(shí)。
常用的系統(tǒng)架構(gòu)是:
- Linux + Apache + PHP + MySQL
- Linux + Apache + Java (WebSphere) + Oracle
- Windows Server 2003/2008 + IIS + C#/ASP.NET + 數(shù)據(jù)庫(kù)
以上一些不太成熟的想法，可以從某一個(gè)層次開(kāi)始，逐步細(xì)化，把產(chǎn)品的性能指標(biāo)提高上去。
轉(zhuǎn)自：
http://blog.sina.com.cn/s/blog_56fd58ab0100o2hw.html
posted @
2011-08-13 12:29 [ 王志偉 ] 閱讀(495) |
評(píng)論 (0) |
編輯 收藏
以前在安裝sql的時(shí)候，如此提示，我只要重新啟動(dòng)即可，可是今天重新啟動(dòng)了N次計(jì)算機(jī)，問(wèn)題卻絲毫沒(méi)有解決，依然提示這樣的話。“以前的某個(gè)程序安裝已在安裝計(jì)算機(jī)上創(chuàng)建掛起的文件操作。運(yùn)行安裝程序之前必須重新啟動(dòng)計(jì)算機(jī)。” 只好google以下，最終得知是安裝程序在先前的安裝過(guò)程中在系統(tǒng)注冊(cè)表留下某些信息，導(dǎo)致不能安裝。于是經(jīng)過(guò)多次試，發(fā)現(xiàn)刪除掉如下鍵值信息即可安裝：
在運(yùn)行窗口輸入regedit，打開(kāi)注冊(cè)表編輯器，在HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\session Manager中找到PendingFileRenameOperations，刪除該鍵值（這個(gè)鍵值是安裝程序暫掛項(xiàng)目，只要找到對(duì)應(yīng)的應(yīng)用程序清除掉就行了），關(guān)閉注冊(cè)表編輯器。重新安裝SQL Server 2000即可。
特整理收藏與下，以便查找。
資料引用:http://www.knowsky.com/340304.html
posted @
2011-07-03 22:23 [ 王志偉 ] 閱讀(191) |
評(píng)論 (0) |
編輯 收藏
打開(kāi)Sql Server 2000企業(yè)管理器時(shí)，顯示的錯(cuò)誤狀態(tài)：
MMC 不能打開(kāi)文件 C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.MSC。
分析：
參看文件是否存在或被損壞。
無(wú)論那種，先將其刪除
然后，在運(yùn)行框中輸入 mmc，打開(kāi)控制臺(tái)
執(zhí)行以下三個(gè)步驟：
1、控制臺(tái)--添加/刪除管理單元--添加--找到Microsoft SQL 企業(yè)管理器--添加--關(guān)閉--確定
2、控制臺(tái)--選項(xiàng)--控制臺(tái)模式選擇"用戶模式完全訪問(wèn)"--將下面的選擇全部取消
3、控制臺(tái)--另存為--存儲(chǔ)為:C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.MSC
在第三步時(shí)可能會(huì)遇到“無(wú)法保存”，這種現(xiàn)象。
則在運(yùn)行框中輸入 regsvr32 C:\Windows\system32\msxml3.dll
然后再執(zhí)行上面的第三步，即可
參考：
http://www.leezao.cn/article.asp?id=467
posted @
2011-07-03 22:22 [ 王志偉 ] 閱讀(789) |
評(píng)論 (0) |
編輯 收藏
性能測(cè)試過(guò)程中，我們?cè)撊绾伪O(jiān)控java虛擬機(jī)內(nèi)存的使用情況，用以判斷JVM是否存在內(nèi)存問(wèn)題呢？如何判斷JVM垃圾回收是否正常？一般的top指令基本上滿足不了這樣的需求，因?yàn)樗饕O(jiān)控的是總體的系統(tǒng)資源，很難定位到j(luò)ava應(yīng)用程序。
在項(xiàng)目實(shí)踐過(guò)程中，我們探索和使用了一款新工具－－Jstat。
先秀一下。Jstat是JDK自帶的一個(gè)輕量級(jí)小工具。全稱“Java Virtual Machine statistics monitoring tool”，它位于java的bin目錄下，主要利用JVM內(nèi)建的指令對(duì)Java應(yīng)用程序的資源和性能進(jìn)行實(shí)時(shí)的命令行的監(jiān)控，包括了對(duì)Heap size和垃圾回收狀況的監(jiān)控?？梢?jiàn)，Jstat是輕量級(jí)的、專門針對(duì)JVM的工具，非常適用。
那，該怎么用呢？
語(yǔ)法結(jié)構(gòu)如下：jstat [Options] vmid [interval] [count]
Options — 選項(xiàng)，我們一般使用 -gcutil 查看gc情況
vmid — VM的進(jìn)程號(hào)，即當(dāng)前運(yùn)行的java進(jìn)程號(hào)
interval– 間隔時(shí)間，單位為秒或者毫秒
count — 打印次數(shù)，如果缺省則打印無(wú)數(shù)次
下面給出一個(gè)實(shí)際的例子：
注：由于JVM內(nèi)存設(shè)置較大，圖中百分比變化不太明顯
圖中參數(shù)含義如下：
S0 — Heap上的 Survivor space 0 區(qū)已使用空間的百分比
S1 — Heap上的 Survivor space 1 區(qū)已使用空間的百分比
E — Heap上的 Eden space 區(qū)已使用空間的百分比
O — Heap上的 Old space 區(qū)已使用空間的百分比
P — Perm space 區(qū)已使用空間的百分比
YGC — 從應(yīng)用程序啟動(dòng)到采樣時(shí)發(fā)生 Young GC 的次數(shù)
YGCT– 從應(yīng)用程序啟動(dòng)到采樣時(shí) Young GC 所用的時(shí)間(單位秒)
FGC — 從應(yīng)用程序啟動(dòng)到采樣時(shí)發(fā)生 Full GC 的次數(shù)
FGCT– 從應(yīng)用程序啟動(dòng)到采樣時(shí) Full GC 所用的時(shí)間(單位秒)
GCT — 從應(yīng)用程序啟動(dòng)到采樣時(shí)用于垃圾回收的總時(shí)間(單位秒)
上圖的示例，紅框中，我們可以看到，5次young gc之后，垃圾內(nèi)存被從Eden space區(qū)(E)放入了Old space區(qū)(O)，并引起了百分比的變化，導(dǎo)致Survivor space使用的百分比從19.69%(S0)降到10.34%(S1)。有效釋放了內(nèi)存空間。綠框中，我們可以看到，一次full gc之后，Old space區(qū)(O)的內(nèi)存被回收，從36.81%降到35.01%。
圖中同時(shí)打印了young gc和full gc的總次數(shù)、總耗時(shí)。而，每次young gc消耗的時(shí)間，可以用相間隔的兩行YGCT相減得到。每次full gc消耗的時(shí)間，可以用相隔的兩行FGCT相減得到。例如紅框中表示的第一行、第二行之間發(fā)生了1次young gc，消耗的時(shí)間為52.281-52.252＝0.029秒。
常駐內(nèi)存區(qū)(P)的使用率，始終停留在37.6%左右，說(shuō)明常駐內(nèi)存沒(méi)有突變，比較正常。
如果young gc和full gc能夠正常發(fā)生，而且都能有效回收內(nèi)存，常駐內(nèi)存區(qū)變化不明顯，則說(shuō)明java內(nèi)存釋放情況正常，垃圾回收及時(shí)，java內(nèi)存泄露的幾率就會(huì)大大降低。但也不能說(shuō)明一定沒(méi)有內(nèi)存泄露。
以上，介紹了Jstat按百分比查看gc情況的功能。其實(shí)，它還有其它功能，例如加載類信息統(tǒng)計(jì)功能、內(nèi)存池信息統(tǒng)計(jì)功能等，那些是以絕對(duì)值的形式打印出來(lái)的，比較少用，在此就不做介紹。
為了更全面的監(jiān)控JVM內(nèi)存使用情況，我們需要引入更強(qiáng)大的工具來(lái)進(jìn)一步分析–JConsole。敬請(qǐng)關(guān)注。
--------
一、概述
SUN 的JDK中的幾個(gè)工具，非常好用。秉承著有免費(fèi)，不用商用的原則。以下簡(jiǎn)單介紹一下這幾種工具。(注：本文章下的所有工具都存在JDK5.0以上版本的工具集里，同javac一樣，不須特意安裝) 。
我一共找到以下四個(gè)工具：重點(diǎn)看看jconsole和jmap。
jps
:與unix上的ps類似，用來(lái)顯示本地的java進(jìn)程，可以查看本地運(yùn)行著幾個(gè)java程序，并顯示他們的進(jìn)程號(hào)。
jstat
:一個(gè)極強(qiáng)的監(jiān)視VM內(nèi)存工具。可以用來(lái)監(jiān)視VM內(nèi)存內(nèi)的各種堆和非堆的大小及其內(nèi)存使用量。
jmap
:打印出某個(gè)java進(jìn)程（使用pid）內(nèi)存內(nèi)的，所有‘對(duì)象’的情況（如：產(chǎn)生那些對(duì)象，及其數(shù)量）。
jconsole
:一個(gè)java GUI監(jiān)視工具，可以以圖表化的形式顯示各種數(shù)據(jù)。并可通過(guò)遠(yuǎn)程連接監(jiān)視遠(yuǎn)程的服務(wù)器VM。
二、 使用介紹：
1、jstat ：我想很多人都是用過(guò)unix系統(tǒng)里的ps命令，這個(gè)命令主要是用來(lái)顯示當(dāng)前系統(tǒng)的進(jìn)程情況，有哪些進(jìn)程，及其 id。 jps 也是一樣，它的作用是顯示當(dāng)前系統(tǒng)的java進(jìn)程情況，及其id號(hào)。我們可以通過(guò)它來(lái)查看我們到底啟動(dòng)了幾個(gè)java進(jìn)程（因?yàn)槊恳粋€(gè)java程序都會(huì)獨(dú)占一個(gè)java虛擬機(jī)實(shí)例），和他們的進(jìn)程號(hào)（為下面幾個(gè)程序做準(zhǔn)備），并可通過(guò)opt來(lái)查看這些進(jìn)程的詳細(xì)啟動(dòng)參數(shù)。
使用方法：在當(dāng)前命令行下打 jps(需要JAVA_HOME，沒(méi)有的話，到改程序的目錄下打) 。
可惜沒(méi)有l(wèi)inux下的ps好用，名稱不好用。但是在第四個(gè)工具jconsole的界面里面會(huì)有具體JAR包的名稱。
2、jstat ：對(duì)VM內(nèi)存使用量進(jìn)行監(jiān)控。
jstat工具特別強(qiáng)大，有眾多的可選項(xiàng)，詳細(xì)查看堆內(nèi)各個(gè)部分的使用量，以及加載類的數(shù)量。使用時(shí)，需加上查看進(jìn)程的進(jìn)程id，和所選參數(shù)。以下詳細(xì)介紹各個(gè)參數(shù)的意義。
jstat -class pid:顯示加載class的數(shù)量，及所占空間等信息。
jstat -compiler pid:顯示VM實(shí)時(shí)編譯的數(shù)量等信息。
jstat -gc pid:可以顯示gc的信息，查看gc的次數(shù)，及時(shí)間。其中最后五項(xiàng)，分別是young gc的次數(shù)，young gc的時(shí)間，full gc的次數(shù)，full gc的時(shí)間，gc的總時(shí)間。
jstat -gccapacity:可以顯示，VM內(nèi)存中三代（young,old,perm）對(duì)象的使用和占用大小，如：PGCMN顯示的是最小perm的內(nèi)存使用量，PGCMX顯示的是perm的內(nèi)存最大使用量，PGC是當(dāng)前新生成的perm內(nèi)存占用量，PC是但前perm內(nèi)存占用量。其他的可以根據(jù)這個(gè)類推， OC是old內(nèi)純的占用量。
jstat -gcnew pid:new對(duì)象的信息。
jstat -gcnewcapacity pid:new對(duì)象的信息及其占用量。
jstat -gcold pid:old對(duì)象的信息。
jstat -gcoldcapacity pid:old對(duì)象的信息及其占用量。
jstat -gcpermcapacity pid: perm對(duì)象的信息及其占用量。
jstat -util pid:統(tǒng)計(jì)gc信息統(tǒng)計(jì)。
jstat -printcompilation pid:當(dāng)前VM執(zhí)行的信息。
除了以上一個(gè)參數(shù)外，還可以同時(shí)加上 兩個(gè)數(shù)字，如：jstat -printcompilation 3024 250 6是每250毫秒打印一次，一共打印6次，還可以加上-h3每三行顯示一下標(biāo)題。
3、jmap 是一個(gè)可以輸出所有內(nèi)存中對(duì)象的工具，甚至可以將VM 中的heap，以二進(jìn)制輸出成文本。使用方法 jmap -histo pid。如果連用 SHELL jmap -histo pid>a.log可以將其保存到文本中去（windows下也可以使用），在一段時(shí)間后，使用文本對(duì)比工具，可以對(duì)比出GC回收了哪些對(duì)象。jmap -dump:format=b,file=f1 3024可以將3024進(jìn)程的內(nèi)存heap輸出出來(lái)到f1文件里。
4、jconsole 是一個(gè)用java寫的GUI程序，用來(lái)監(jiān)控VM，并可監(jiān)控遠(yuǎn)程的VM，非常易用，而且功能非常強(qiáng)。由于是GUI程序，這里就不詳細(xì)介紹了，不會(huì)的地方可以參考ＳＵＮ的官方文檔。
使用方法：命令行里打 jconsole，選則進(jìn)程就可以了。
友好提示：windows查看進(jìn)程號(hào)，由于任務(wù)管理器默認(rèn)的情況下是不顯示進(jìn)程id號(hào)的，所以可以通過(guò)如下方法加上。ctrl+alt+del打開(kāi)任務(wù)管理器，選擇‘進(jìn)程’選項(xiàng)卡，點(diǎn)‘查看’->''選擇列''->加上''PID''，就可以了。當(dāng)然還有其他很好的選項(xiàng)。
三、參考資料：
article:http://elf8848.javaeye.com/blog/442806
jps:http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jps.html
jstat:http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstat.html
jmap:http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jmap.html
jconsole:http://java.sun.com/j2se/1.5.0/docs/guide/management/jconsole.html
posted @
2011-05-29 23:08 [ 王志偉 ] 閱讀(7503) |
評(píng)論 (0) |
編輯 收藏
PermGen space這一部分用于存放Class和Meta的信息,Class在被 Load的時(shí)候被放入PermGen space區(qū)域，它和和存放Instance的Heap區(qū)域不同,GC(Garbage Collection)不會(huì)在主程序運(yùn)行期對(duì)PermGen space進(jìn)行清理，所以如果你的APP會(huì)LOAD很多CLASS的話,就很可能出現(xiàn)PermGen space錯(cuò)誤。
我在做
TMS的發(fā)布工具的時(shí)候，就遇到了問(wèn)題，這個(gè)工具的目的是把一個(gè)相同的系統(tǒng)，在tomcat下自動(dòng)的發(fā)布多份，但當(dāng)卸載，重新發(fā)布多次后， tomcat就掛了，整個(gè)電腦如同死機(jī)一般。后來(lái)使用文章里的set JAVA_OPTS=-server -Xms800m -Xmx800m -XX:PermSize=64M-XX:MaxNewSize=256m-XX:MaxPermSize=128m -Djava.awt.headless=true 解決了問(wèn)題，不過(guò)在2G的電腦上，我是把-XX:MaxPermSize=128m 調(diào)到了-XX:MaxPermSize=256m。另外我還嘗試了把所有的lib都放到tomcat的lib下，一些lib就不能在本項(xiàng)目中再出現(xiàn)了。
現(xiàn)在看，還是spring，hibernate之類的產(chǎn)生的類導(dǎo)致PermGen space空間不足造成的這些問(wèn)題。
http://www.javaeye.com/topic/80620?page=1 這個(gè)帖子里討論了這個(gè)問(wèn)題，有人做了些有益的分析可以看看。
我又繼續(xù)在我的筆記本上做了測(cè)試T42,1G內(nèi)存。tomcat版本6.0.14。
set JAVA_OPTS=-server -Xms256m -Xmx256m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=256m -Djava.awt.headless=true
這個(gè)配置反復(fù)發(fā)布是可以的，另外又一次測(cè)試了將項(xiàng)目下的jar包放到tomcat的lib下的對(duì)比。重新安裝一個(gè)lib下為空的程序是10秒，否則是30秒。
總結(jié)一下：
1、修改tomcat的啟動(dòng)參數(shù)，類似如下的樣子
set JAVA_OPTS=-server -Xms256m -Xmx256m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=256m
echo Using CATALINA_BASE: %CATALINA_BASE%
echo Using CATALINA_HOME: %CATALINA_HOME%
echo Using CATALINA_TMPDIR: %CATALINA_TMPDIR%
if ""%1"" == ""debug"" goto use_jdk
echo Using JRE_HOME: %JRE_HOME%
goto java_dir_displayed
:use_jdk
echo Using JAVA_HOME: %JAVA_HOME%
:java_dir_displayed
echo Using JAVA_OPTS: %JAVA_OPTS%
set JAVA_OPTS=-server -Xms256m -Xmx256m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=256m 2、將通用的lib文件放到tomcat的目錄下
posted @
2011-05-29 23:05 [ 王志偉 ] 閱讀(367) |
評(píng)論 (0) |
編輯 收藏
非侵入式系介紹DI用語(yǔ)，我得理解是兩個(gè)組件（類，接口）之間，比較獨(dú)立，不深入到另一個(gè)類內(nèi)部，哪位大蝦能點(diǎn)撥一二？
關(guān)于“侵入式”和“非侵入式”設(shè)計(jì)
有讀者講“侵入式”這一術(shù)語(yǔ)無(wú)法理解，這里給一個(gè)簡(jiǎn)單解釋，是我個(gè)人的看法。
在設(shè)計(jì)一個(gè)類時(shí)，按理說(shuō)，需要考慮的應(yīng)該只是該類所企圖表示的那個(gè)“概念”本身：為表示有關(guān)概念應(yīng)記錄哪些信息，該類的對(duì)象與外界交換信息的界面等等。但定義這個(gè)類并不是為了放在那里觀賞，而是為了使用。在考慮類對(duì)象的使用時(shí)，使用環(huán)境的一些要素就可能“侵入”這個(gè)類的設(shè)計(jì)之中。實(shí)際上，許多情況下我們常常可以在“侵入式”設(shè)計(jì)和“非侵入式”設(shè)計(jì)之間做一個(gè)選擇，不同選擇各有優(yōu)缺點(diǎn)。在考慮非類的程序部分時(shí)，這種問(wèn)題也同樣存在。
例如，我們可能需要對(duì)類A的對(duì)象做引用計(jì)數(shù)，這里有兩種基本可能性：將計(jì)數(shù)功能納入類A的設(shè)計(jì)內(nèi)（侵入式引用計(jì)數(shù)設(shè)計(jì)，此時(shí)類A的對(duì)象中包含了與引用計(jì)數(shù)有關(guān)的要素，這顯然是與類A所要表示的概念無(wú)關(guān)的東西），或者將計(jì)數(shù)功能放在類A之外（非侵入式引用計(jì)數(shù)）。
本書中討論容器時(shí)提出了“侵入式容器”設(shè)計(jì)和“非侵入式容器”設(shè)計(jì)的概念：當(dāng)我們希望將類A的對(duì)象放入一種容器時(shí)，是否需要將該容器的實(shí)現(xiàn)要素“侵入”類A的設(shè)計(jì)實(shí)現(xiàn)之中（這顯然是與類A本身并無(wú)必然關(guān)系的要素）。不同考慮導(dǎo)致不同的容器設(shè)計(jì)。
我基本上知道了，從夏大蝦得著作中得知。
比如struts，需要繼承一些struts得類，這就是侵入式，使得系統(tǒng)離不開(kāi)那個(gè)框架。
而spring中，業(yè)務(wù)類不需要繼承框架得類，將來(lái)拋棄spring也比較方便。
樓上大蝦（土豆塊）能否談下ejb與spring之間得關(guān)系。你用ejb嗎？如果用了，感覺(jué)如何？
非侵入式(non-intrusive)設(shè)計(jì)是目前非常熱門的話題。在一般的討論中，非侵入式設(shè)計(jì)總是和Spring這樣的IoC容器或者AOP技術(shù)聯(lián)系在一起。但是從思想上說(shuō)，non-intrusive并不等價(jià)于IoC或者AOP，它是一個(gè)比AOP更加寬泛的概念。
首先，我們考察一下何謂intrusive。典型的intrusive實(shí)現(xiàn)是繼承特定的基類, 或者實(shí)現(xiàn)特定的接口. 在抽象的意義上說(shuō), intrusive意味著在基礎(chǔ)結(jié)構(gòu)中預(yù)留了一些特殊的,專用的結(jié)構(gòu), 這些結(jié)構(gòu)對(duì)于基礎(chǔ)功能而言不僅僅是無(wú)用的, 甚至是有害的, 例如影響性能或者模糊了原有的概念結(jié)構(gòu), 而系統(tǒng)整體的后期擴(kuò)展能力也受到這些預(yù)設(shè)的結(jié)構(gòu)通道的限制.
non-intrusive設(shè)計(jì)的基本特點(diǎn)是盡量利用基礎(chǔ)結(jié)構(gòu)的元素, 而不是引入額外的特殊結(jié)構(gòu).例如, 在witrix平臺(tái)的tpl模板中
＜button tpl:tag="ui:FlatButton" value="xx" onclick="alert('ok')" /＞
如果后臺(tái)tpl引擎不解析＜ui:FlatButton＞標(biāo)簽, 那么該標(biāo)簽的表現(xiàn)就是普通的html button. 這里整個(gè)頁(yè)面的界面表現(xiàn)結(jié)構(gòu)沒(méi)有被tpl標(biāo)簽所破壞,而如果像jsp tag那樣強(qiáng)行規(guī)定必須采用節(jié)點(diǎn)語(yǔ)法, 即
＜ui:FlatButton value="xx" onclick="alert('ok')" /＞
則在沒(méi)有tpl引擎的情況下, 界面結(jié)構(gòu)被tpl標(biāo)簽所破壞,此時(shí)在dreamweaver這樣的可視化工具中我們無(wú)法再識(shí)別出有效的界面元素, 喪失了WYSIWYG編輯的能力.
tpl:tag屬性屬于html語(yǔ)法本身規(guī)定了的自定義屬性, 它在html中的存在是符合規(guī)范的, 而且它對(duì)于button來(lái)說(shuō)沒(méi)有造成什么限制或損害, 因而是一種無(wú)害的標(biāo)記. 在沒(méi)有tpl模板引擎的情況下, tpl:tag屬性與其他自定義屬性一樣處于同樣的地位, 沒(méi)有什么特殊的作用. 而一旦tpl模板引擎識(shí)別出該特殊標(biāo)記, 整個(gè)節(jié)點(diǎn)就被解釋成一個(gè)具有豐富表現(xiàn)形式的平面按鈕而不是系統(tǒng)缺省風(fēng)格的普通按鈕. 從級(jí)列設(shè)計(jì)的角度上說(shuō), button對(duì)應(yīng)于ui:FlatButton在沒(méi)有tpl解析能力情況時(shí)退化了的結(jié)果. 在EJB3的規(guī)范中, 普通的POJO(Plain Old Java Object)對(duì)象在經(jīng)過(guò)無(wú)害的標(biāo)記(annotation)之后通過(guò)Enhance過(guò)程獲得持久化等特性, POJO正對(duì)應(yīng)于EJB Object的退化形式. 在某種意義上我們可以說(shuō), 存在著多少種可退化方式，就對(duì)應(yīng)著多少種non-intrusive design。
與傳統(tǒng)設(shè)計(jì)中的結(jié)構(gòu)堆砌不同, 現(xiàn)代技術(shù)更加強(qiáng)調(diào)在原有結(jié)構(gòu)基礎(chǔ)上的同態(tài)變化, 關(guān)注原有結(jié)構(gòu)中的某些部分出現(xiàn)特殊意義后所產(chǎn)生的對(duì)稱破缺. 在non-intrusive設(shè)計(jì)中, 基礎(chǔ)的結(jié)構(gòu)中沒(méi)有為擴(kuò)展內(nèi)置什么特殊的結(jié)構(gòu), 一般僅僅是標(biāo)記而已, 這些標(biāo)記是無(wú)害的甚至本身在基礎(chǔ)結(jié)構(gòu)中是有用的, 例如某些javascript庫(kù)在前臺(tái)html頁(yè)面中利用html標(biāo)簽的class屬性作為標(biāo)記. 為了識(shí)別這些屬于結(jié)構(gòu)標(biāo)準(zhǔn)部分的標(biāo)記并對(duì)之進(jìn)行處理,我們需要一種可選擇的結(jié)構(gòu)透明性, 具體來(lái)說(shuō)我們需要能滲透到系統(tǒng)內(nèi)部,準(zhǔn)確的定位到標(biāo)記處. 這就類似于x光檢測(cè), x光只與某些特殊材料發(fā)生強(qiáng)烈作用而普通部分對(duì)于x光而言是透明的. 而當(dāng)外部引擎識(shí)別出這些特殊的標(biāo)記之后, 可能需要操縱該局部結(jié)構(gòu), 例如在基礎(chǔ)結(jié)構(gòu)中插入一些新的結(jié)構(gòu)以實(shí)現(xiàn)基礎(chǔ)結(jié)構(gòu)的增強(qiáng). 這些都可能需要應(yīng)用類似于AOP的技術(shù), 而在這一增強(qiáng)過(guò)程中關(guān)于擴(kuò)展結(jié)構(gòu)的具體知識(shí)存在于擴(kuò)展引擎中而不是基礎(chǔ)結(jié)構(gòu)中, 因而往往整體表現(xiàn)出一種IoC的特性.
轉(zhuǎn)自：http://hi.baidu.com/westsky/blog/item/46d452f0127cebaaa50f522f.html
posted @
2011-04-19 10:23 [ 王志偉 ] 閱讀(4595) |
評(píng)論 (0) |
編輯 收藏
<1> js或者jQuery訪問(wèn)頁(yè)面中的框架iframe.
注意:框架內(nèi)的頁(yè)面是不能跨域的! 假設(shè)有兩個(gè)頁(yè)面,在相同域下.
假設(shè)：父窗口 index.html ，有 id 為 subifrm 的 iframe
1. 在index.html執(zhí)行JS直接訪問(wèn)子窗口中某元素 :
document.getElementById('subifrm').contentWindow.document.getElementById('test').style.color='red'
2. 利用jquery 來(lái)訪問(wèn)子窗口
$("#subifrm").contents().find("#test").css('color','red');
====================================================================
====================================================================
<2> 用DOM方法與jquery方法結(jié)合的方式實(shí)現(xiàn)互動(dòng)操作
1.在父窗口中操作 選中IFRAME中的所有單選鈕
$(window.frames["iframe1"].document).find("input[@type='radio']").attr("checked","true");
2.在IFRAME中操作 選中父窗口中的所有單選鈕
$(window.parent.document).find("input[@type='radio']").attr("checked","true");
====================================================================
====================================================================
<3> 使用jquery操作iframe
1 頁(yè)面里有兩個(gè)ifame
<iframe id="leftiframe"></iframe>
<iframe id="mainiframe></iframe>
<iframe id="leftiframe"></iframe>
<iframe id="mainiframe></iframe>
leftiframe中jQuery改變mainiframe的src代碼：
$("#mainframe",parent.document.body).attr("src","http://www.baidu.com")
2、 如果內(nèi)容里面有一個(gè)ID為mainiframe的ifame
<iframe id="mainifame"></ifame>
<iframe id="mainifame"></ifame>
ifame包含一個(gè)someID
<div id="someID">you want to get this content</div>
<div id="someID">you want to get this content</div>
得到someID的內(nèi)容
$("#mainiframe").contents().find("someID").html();或者$("#mainiframe").contains().find("someID").text();
$("#mainiframe").contents().find("someID").html();或者$("#mainiframe").contains().find("someID").text();
$("#mainiframe").contents().find("someID").html();或者$("#mainiframe").contains().find("someID").text();
2 、如上面所示
leftiframe中的jQuery操作mainiframe的內(nèi)容someID的內(nèi)容
$("#mainframe",parent.document.body).contents().find("someID").html();或者 $("#mainframe",parent.document.body).contents().find("someID").val();
source:http://suan2046.javaeye.com/blog/575421
posted @
2011-03-07 14:14 [ 王志偉 ] 閱讀(897) |
評(píng)論 (0) |
編輯 收藏
一、
1、數(shù)據(jù)庫(kù)壓力問(wèn)題
所有的壓力最終都會(huì)反映到數(shù)據(jù)庫(kù)方面，一定要對(duì)數(shù)據(jù)庫(kù)有一個(gè)整體的規(guī)劃。
可以按照業(yè)務(wù)、區(qū)域等等特性對(duì)數(shù)據(jù)庫(kù)進(jìn)行配置，可以考慮分庫(kù)、使用rac、分區(qū)、分表等等策略，確保數(shù)據(jù)庫(kù)能正常的進(jìn)行交易。
2、事務(wù)問(wèn)題
你采用了兩種類型數(shù)據(jù)庫(kù)，一個(gè)SQL Server、一個(gè)oracle，如果一個(gè)交易需要在兩個(gè)數(shù)據(jù)庫(kù)中操作，那么必須考慮到分布式事務(wù)，你應(yīng)該仔細(xì)的設(shè)計(jì)你的系統(tǒng)，來(lái)避免使用分布式事務(wù)，以避免分布式事務(wù)帶來(lái)更多的數(shù)據(jù)庫(kù)壓力和其它問(wèn)題。推薦你采用延遲提交的策略(并不保證數(shù)據(jù)的完整)，來(lái)避免分布式事務(wù)的問(wèn)題，畢竟commit失敗的幾率很低。（某個(gè)超大型系統(tǒng)，有3套數(shù)據(jù)庫(kù)，也是采用的延遲提交策略，避免分布式事務(wù)帶來(lái)的對(duì)數(shù)據(jù)庫(kù)過(guò)大的壓力）。
看到了你在應(yīng)用前端 (weblogic EJB)采用了F5，我個(gè)人不是很贊同這個(gè)方案，雖然F5是一個(gè)好的L4產(chǎn)品，也能基于第7層做負(fù)載均衡和容災(zāi)。但是一個(gè)有事務(wù)交易的EJB，如果采用了這種方案，把不需要使用分布式事務(wù)的交易變成了分布式交易，試想，一個(gè)web如果在一個(gè)請(qǐng)求中，訪問(wèn)了后端兩個(gè)EJB，那么L4就會(huì)有可能把請(qǐng)求分發(fā)到不同的服務(wù)器上，沒(méi)有對(duì)事務(wù)維持在一個(gè)服務(wù)器中，就不能使用本地事務(wù)。同樣，一個(gè)web，訪問(wèn)后端一個(gè)請(qǐng)求，這個(gè)請(qǐng)求中需要3個(gè)EJB，那么極有可能把這3 個(gè)請(qǐng)求分發(fā)到不同的服務(wù)器，又造成了分布式事務(wù)。weblogic是一個(gè)好的J2EE產(chǎn)品，對(duì)這種有事務(wù)關(guān)聯(lián)的負(fù)載均衡，它會(huì)優(yōu)先考慮采用一個(gè)服務(wù)器里面的應(yīng)用，這樣就采用了本地事務(wù)，提高了響應(yīng)速度，減小了分布式事務(wù)對(duì)應(yīng)用和數(shù)據(jù)庫(kù)的壓力。
3、web的優(yōu)化
我個(gè)人認(rèn)為，一個(gè)商業(yè)的應(yīng)用，硬件的投資可能不是主要的瓶頸，往往可維護(hù)性，可擴(kuò)展性是最主要的問(wèn)題。
沒(méi)有必要采用不成熟的方案，要更多的使用成熟的方案，將靜態(tài)、圖片獨(dú)立使用不同的服務(wù)器，對(duì)于常態(tài)的靜態(tài)文件，采用E-TAG或者客戶端緩存，google 很多就是這樣干的。對(duì)于熱點(diǎn)的功能，考慮使用完全裝載到內(nèi)存，保證絕對(duì)的響應(yīng)速度，對(duì)于需要頻繁訪問(wèn)的熱點(diǎn)數(shù)據(jù)，采用集中緩存(多個(gè)可以采用負(fù)載均衡)，減輕數(shù)據(jù)庫(kù)的壓力，比如：很多配置信息，操作員信息等等。
對(duì)了，對(duì)于幾乎除二進(jìn)制文件，都應(yīng)該在L4上配置基于硬件的壓縮方案，減少網(wǎng)絡(luò)的流量。提高用戶使用的感知。
4、網(wǎng)絡(luò)問(wèn)題
你不可能要求所有的使用人員，都和你的服務(wù)器在一個(gè)運(yùn)營(yíng)商的網(wǎng)絡(luò)內(nèi)，可以考慮采用鏡像、多路網(wǎng)絡(luò)接入、基于DNS的負(fù)載均衡。如果有足夠的投資，可以采用CDN(內(nèi)容分發(fā)網(wǎng))，減輕你的服務(wù)器壓力。
二、F5的負(fù)載均衡 是必不可少的，他的每秒點(diǎn)擊量能達(dá)到將近30萬(wàn)，并且它有會(huì)話的粘性，只要是同一個(gè)ip發(fā)過(guò)來(lái)的請(qǐng)求，它就會(huì)把它分到同一臺(tái)機(jī)器的，不用擔(dān)心分發(fā)錯(cuò)誤的?，F(xiàn)在的問(wèn)題是apache和tomcat的能力不平衡，動(dòng)態(tài)的內(nèi)容壓力太大，不是數(shù)據(jù)庫(kù)的壓力，我們的數(shù)據(jù)庫(kù)
oracle是RAC群集。性能很好
三、tomcat為什么死掉？當(dāng)時(shí)CPU或者內(nèi)存的占用率是多少？看看其中JVM占用了多少？有沒(méi)有OOM的錯(cuò)誤？不可能20臺(tái)tomcat只能支撐5000的并發(fā)。。。以前做過(guò)單臺(tái)的resin峰值到3K都是綽綽有余的。。。把緩存做好，減少動(dòng)態(tài)查詢
四、
1、F5的使用
F5不光可以做web的負(fù)載均衡，也可以做基于第4層的負(fù)載均衡。
比如：銀行接口，大部分基于socket通訊的，就可以在前面架設(shè)一套F5設(shè)備，將請(qǐng)求分發(fā)到不同的服務(wù)器上。
大部分使用F5都是在web層次上，如果使用基于源IP地址的策略，有很多客戶端都是基于代理服務(wù)器，這個(gè)時(shí)候源IP地址是一樣的，其實(shí)并沒(méi)有把這些用戶給分發(fā)到不同的服務(wù)器上，建議采用基于cookie insert的方式，采用cookie的會(huì)話保持策略，loadbalance的算法，需要仔細(xì)的結(jié)合自己的應(yīng)用的實(shí)際情況來(lái)設(shè)置。
2、大并發(fā)的問(wèn)題
現(xiàn)在你得到了一個(gè)大概的系統(tǒng)能承受的并發(fā)，但是還達(dá)不到系統(tǒng)的設(shè)計(jì)目標(biāo)。
應(yīng)該從應(yīng)用的角度去分析這個(gè)問(wèn)題，web方面，通過(guò)工具(httplook)，檢查一下客戶端發(fā)起的請(qǐng)求都是什么響應(yīng)狀態(tài)，如果看到很多304請(qǐng)求狀態(tài)，你需要優(yōu)化你的url緩存，看一下每個(gè)url的耗費(fèi)時(shí)間，仔細(xì)針對(duì)比較慢的進(jìn)行調(diào)優(yōu)；對(duì)于tomcat或者weblogic，在高并發(fā)的情況下，用kill -3 <PID>，獲得ThreadDump(HeapDump需要特殊的設(shè)置)，看一下在高并發(fā)下，jvm的線程到底在干什么，仔細(xì)的分析可能對(duì)你有幫助。
如果在這些還沒(méi)有改善的情況下，應(yīng)當(dāng)去想一想，硬件是否足夠、配置是否合理等等系統(tǒng)級(jí)別的問(wèn)題。
五、似乎在說(shuō)瓶頸在于tomcat并發(fā)承載能力不夠，但為什么tomcat只能承擔(dān)單機(jī)200個(gè)并發(fā)？當(dāng)并發(fā)急劇上升的時(shí)候，tomcat在執(zhí)行動(dòng)態(tài)請(qǐng)求的時(shí)候，瓶頸在哪里？是哪部分程序，或者哪個(gè)環(huán)節(jié)首先導(dǎo)致tomcat失去響應(yīng)的？在davexin描述的刀片硬件上面，tomcat上面如果跑的僅僅是最簡(jiǎn)單的jsp頁(yè)面，在采用BEA JRockit JVM的情況下，500個(gè)并發(fā)也可以達(dá)到。
我的推測(cè)是瓶頸還是出在EJB遠(yuǎn)程方法調(diào)用上！
tomcat上面的java應(yīng)用要通過(guò)EJB遠(yuǎn)程方法調(diào)用，來(lái)訪問(wèn)weblogic上面的無(wú)狀態(tài)SessionBean，這樣的遠(yuǎn)程方法調(diào)用一般都在100ms~500ms級(jí)別，或者更多。而如果沒(méi)有遠(yuǎn)程方法調(diào)用，即使大量采用spring的動(dòng)態(tài)反射，一次完整的web請(qǐng)求處理在本地JVM內(nèi)部的完成時(shí)間一般也不過(guò)20ms而已。一次web請(qǐng)求需要過(guò)長(zhǎng)的執(zhí)行時(shí)間，就會(huì)導(dǎo)致servlet線程被占用更多的時(shí)間，從而無(wú)法及時(shí)響應(yīng)更多的后續(xù)請(qǐng)求。
如果這個(gè)推測(cè)是成立的話，那么我的建議就是既然你沒(méi)有用到分布式事務(wù)，那么就干脆去掉EJB。weblogic也可以全部撤掉，業(yè)務(wù)層使用spring取代EJB，不要搞分布式架構(gòu)，在每個(gè)tomcat實(shí)例上面部署一個(gè)完整的分層結(jié)構(gòu)。
另外在高并發(fā)情況下，apache處理靜態(tài)資源也很耗內(nèi)存和CPU，可以考慮用輕量級(jí)web server如lighttpd/litespeed/nginx取代之。
六、tomcat之所以并發(fā)低很可能是由于remote session bean造成的，remote session bean又一次被濫用了，在樓主的這種業(yè)務(wù)情況下，web層和service層根本不需要分開(kāi)，象樓主這樣分開(kāi)帶來(lái)就是一訪問(wèn)業(yè)務(wù)層就帶來(lái)長(zhǎng)時(shí)間的遠(yuǎn)程請(qǐng)求，確實(shí)導(dǎo)致tomcat上servlet資源釋放的問(wèn)題。那么remote session bean應(yīng)該被用在什么地方呢，without ejb上有寫到金融系統(tǒng)常用ejb。我把他的這句話延伸一下，也就是說(shuō)當(dāng)業(yè)務(wù)的運(yùn)行時(shí)間遠(yuǎn)超過(guò)遠(yuǎn)程調(diào)用的時(shí)間時(shí)，我們就可以用remote session bean來(lái)把這個(gè)業(yè)務(wù)分離出去。而樓主的系統(tǒng)中沒(méi)有這種業(yè)務(wù)情況。所以使用remote session bean應(yīng)該來(lái)說(shuō)是一個(gè)錯(cuò)誤的選擇，不過(guò)這個(gè)錯(cuò)誤的選擇帶來(lái)的危害被大量的硬件所掩蓋，帶來(lái)的是成本的提高。而性能上還不如slsb。
所以我覺(jué)得如果要改架構(gòu)最便捷的方法是使用slsb，把remote session bean去掉。這樣改造的成本比較低，如果換成spring+hibernate成本就高得多了。也就是說(shuō)可以 struts+Bean+DAO+helper，然后把weblogic作cluster，任意一個(gè)node上都部署相同的應(yīng)用。也就是水平擴(kuò)展，理論上來(lái)講當(dāng)性能不滿足要求時(shí)添加node就行了，如果能做成農(nóng)場(chǎng)就更加方便了。當(dāng)然即使非農(nóng)場(chǎng)也沒(méi)有關(guān)系，可以用現(xiàn)在在使用的stick分發(fā)。這樣的改造之所以方便是因?yàn)榘裷emote session bean改成slsb是很容易的，而且團(tuán)隊(duì)里的人估計(jì)對(duì)ejb都更加熟悉一點(diǎn)，成本會(huì)比較低一點(diǎn)
七、
近段時(shí)間正在做購(gòu)買新硬件和新軟件的預(yù)算，公司高層準(zhǔn)備買weblogic10和oracle 10g，所以請(qǐng)了bea公司的人員和我一塊做測(cè)試，經(jīng)過(guò)近幾天的測(cè)試，測(cè)試一下新的系統(tǒng)指標(biāo)1萬(wàn)個(gè)并發(fā)，需要多少軟件和多少硬件能夠支撐，已經(jīng)測(cè)試了不同的組合方式，有了不同的結(jié)果，分別如下：
1。1臺(tái)weblogic10 能支持900個(gè)用戶并發(fā)（沒(méi)有用ejb），平均響應(yīng)時(shí)間 10秒。
2。1臺(tái)weblogic10 Express（相當(dāng)于1臺(tái)tomcat，用于發(fā)布jsp應(yīng)用）加1臺(tái)weblogic10（發(fā)布ejb應(yīng)用），能支持1000個(gè)并發(fā)用戶，平均響應(yīng)時(shí)間 9秒，由于本人使用的loadRunner最多支持1000個(gè)web并發(fā)，雖然此時(shí)weblogic沒(méi)有任何錯(cuò)誤，但是沒(méi)辦法再向上壓用戶，所以不知道最高能支撐多少個(gè)并發(fā)用戶，很遺憾。
3。1臺(tái)weblogic8， 能支持900個(gè)用戶并發(fā)（沒(méi)有用ejb），平均響應(yīng)時(shí)間 11秒。但是沒(méi)有weblogic10在同樣時(shí)間內(nèi)處理的交易數(shù)量多?？梢耘卸ㄐ阅懿荒躻eblogic10。
4。1臺(tái)tomcat4.1加1臺(tái)weblogic8，只能支持350個(gè)并發(fā)用戶，tomcat就連結(jié)超時(shí)，說(shuō)明此種結(jié)構(gòu)瓶頸在tomcat。
5。1臺(tái)tomcat6.14加1臺(tái)weblogic8，還不如方案4，tomcat結(jié)超時(shí)更多，說(shuō)明此種結(jié)構(gòu)瓶頸在tomcat。由于還沒(méi)有看tomcat6.14的調(diào)優(yōu)資料。所以還請(qǐng)高手給建議。
6。1臺(tái)tomcat4.1加1臺(tái)weblogic10，性能同樣不佳，問(wèn)題出現(xiàn)在tomcat性能跟不上。
7。1臺(tái)tomcat6.14加1臺(tái)weblogic10，性能同樣不佳，問(wèn)題出現(xiàn)在tomcat性能跟不上。
明天還要做一個(gè)weblogic10 cluster測(cè)試，等有了測(cè)試結(jié)果，再根大家交流。
以上測(cè)試機(jī)器都為 linux as4 操作系統(tǒng)，2cpu + 2G內(nèi)存，發(fā)現(xiàn)cpu利用率最高占45%，一般就在10%左右，內(nèi)存可以用到1.5G。 loadRunner機(jī)器為2cpu + 2G內(nèi)存，window server 2003操作系統(tǒng)。
有以上的結(jié)果，bea公司人員建議購(gòu)買16-20cpu的licens。機(jī)器購(gòu)買4cpu + 8G內(nèi)存機(jī)器4-6臺(tái)。前端tomcat增加到50臺(tái)。
由于根據(jù)以前的宕機(jī)記錄，主要表現(xiàn)在tomcat層，個(gè)別高峰時(shí)候也出現(xiàn)在F5。故不敢輕易的舍棄無(wú)狀態(tài)session bean。由于tomcat做了大部分的業(yè)務(wù)，只有需要數(shù)據(jù)庫(kù)的時(shí)候才調(diào)用weblogic中間件，由于weblogic的價(jià)格還是比較昂貴的，公司以前購(gòu)買的weblogic licens數(shù)量限制。所以還不能把所有的tomcat換成weblogic。如果有20臺(tái)weblogic的licens，我也就不擔(dān)心1萬(wàn)個(gè)并發(fā)了。
八、
坦白說(shuō)我還從來(lái)沒(méi)有聽(tīng)說(shuō)過(guò)大規(guī)?；ヂ?lián)網(wǎng)應(yīng)用使用EJB的先例。為什么大規(guī)模互聯(lián)網(wǎng)應(yīng)用不能用EJB，其實(shí)就是因?yàn)镋JB性能太差，用了EJB幾乎必然出現(xiàn)性能障礙。阿里巴巴和淘寶網(wǎng)那是每天多少億PV的電子商務(wù)網(wǎng)站了，其實(shí)也就是用JBoss而已，而且也只是用其web容器(JBoss的web容器就是tomcat)，所以本質(zhì)上還是在用tomcat。
今年年初，RedHat在深圳的HW大客戶在內(nèi)部做過(guò)性能對(duì)比評(píng)測(cè)，JBoss4 vs WebLogic 9，在web容器一項(xiàng)的評(píng)測(cè)當(dāng)中，JBoss4勝出。這個(gè)結(jié)果并不令人感到意外，因?yàn)閣eb容器的性能說(shuō)到底無(wú)非就是Servlet線程調(diào)度能力而已，Tomcat不像WebLogic那樣附加n多管理功能，跑得快很正常。這一點(diǎn)你只要對(duì)比測(cè)試一下WebLogic的數(shù)據(jù)庫(kù)連接池和C3P0連接池的性能也會(huì)發(fā)現(xiàn)類似的結(jié)論，C3P0可要比WebLogic的連接池快好幾倍了。這不是說(shuō)WebLogic性能不好，只不過(guò)weblogic要實(shí)現(xiàn)更多的功能，所以在單一的速度方面就會(huì)犧牲很多東西。
以我的經(jīng)驗(yàn)來(lái)判斷，使用tomcat5.5以上的版本，配置apr支持，進(jìn)行必要的tuning，使用BEA JRockit JVM的話，在你們目前的刀片上面，支撐500個(gè)并發(fā)完全是可以做到的。結(jié)合你們目前20個(gè)刀片的硬件，那么達(dá)到1萬(wàn)并發(fā)是沒(méi)問(wèn)題的。當(dāng)然這樣做的前提是必須扔掉EJB，并置web層和業(yè)務(wù)層在同一個(gè)JVM內(nèi)部。
從你上面的發(fā)言來(lái)看，你們之所以采用EJB，無(wú)非是因?yàn)榻?jīng)費(fèi)有限，無(wú)法購(gòu)買充足的weblogic license。所以退而求其次，購(gòu)買少量的weblogic license，專門跑業(yè)務(wù)層服務(wù)器，用SLSB暴露遠(yuǎn)程接口給tomcat調(diào)用。然后部署n十多臺(tái)免費(fèi)的tomcat服務(wù)器跑web。為省錢而采用 EJB到是一個(gè)很新鮮的事，但實(shí)際上這就是一個(gè)很愚蠢的決定。
weblogic的優(yōu)秀更多的體現(xiàn)在他對(duì)于J2EE標(biāo)準(zhǔn)優(yōu)秀的支持，各種復(fù)雜的企業(yè)應(yīng)用場(chǎng)景以及傳統(tǒng)的中間件應(yīng)用的豐富而方便的集成手段上。簡(jiǎn)單的來(lái)說(shuō)，就是weblogic/websphere是企業(yè)應(yīng)用的首選，特別是強(qiáng)調(diào)事務(wù)的企業(yè)應(yīng)用，例如金融，電信計(jì)費(fèi)。但在互聯(lián)網(wǎng)應(yīng)用方面，weblogic/websphere根本就體現(xiàn)不出有什么能夠超過(guò)resin/tomcat的地方，誠(chéng)然weblogic express的web容器穩(wěn)定性要好于tomcat，但沒(méi)有互聯(lián)網(wǎng)企業(yè)在大規(guī)模部署tomcat水平群集的時(shí)候，還會(huì)為這一點(diǎn)而瘋狂買單購(gòu)買 weblogic license。
所以我個(gè)人很不理解，作為一個(gè)互聯(lián)網(wǎng)公司的CTO，怎么會(huì)如此迷信weblogic，因?yàn)槲艺J(rèn)識(shí)的互聯(lián)網(wǎng)公司高層，沒(méi)有什么人愿意用商業(yè)產(chǎn)品，絕大多數(shù)都是用開(kāi)源的，我不憚揣測(cè)他的背景可能來(lái)自傳統(tǒng)企業(yè)應(yīng)用出身的吧，呵呵。
九、
這說(shuō)明瓶頸還不在EJB遠(yuǎn)程調(diào)用上，但是問(wèn)題已經(jīng)逐漸清楚了。為什么weblogic充當(dāng)web容器發(fā)起遠(yuǎn)程EJB調(diào)用的時(shí)候可以支撐1000個(gè)并發(fā)，但是tomcat只能到350個(gè)？只有兩個(gè)可能的原因：
1、你的tomcat沒(méi)有配置好，嚴(yán)重影響了性能表現(xiàn)
2、tomcat和weblogic之間的接口出了問(wèn)題
上面的帖子其實(shí)我也介紹過(guò)了，如果只是單純的作為servlet容器來(lái)看，tomcat的性能不應(yīng)該比weblogic差，甚至還要更好，所以你可以這樣來(lái)擬定測(cè)試方案：
在同樣硬件環(huán)境下對(duì)比測(cè)試tomcat5.5和weblogic10的servlet容器性能，分別寫幾個(gè)訪問(wèn)數(shù)據(jù)庫(kù)，和不訪問(wèn)數(shù)據(jù)庫(kù)的JSP頁(yè)面測(cè)試就可以了，并發(fā)從500往上走，看看哪個(gè)throughput更高。記得要調(diào)優(yōu)tomcat5.5，配置apr支持要打開(kāi)。
如果測(cè)試結(jié)果表明tomcat并發(fā)響應(yīng)能力遠(yuǎn)遠(yuǎn)差于weblogic，那就說(shuō)明你的tomcat配置有很大的問(wèn)題，好好鉆研tomcat configuration && performance tuning吧；
如果測(cè)試結(jié)果表明tomcat并發(fā)響應(yīng)能力與weblogic相當(dāng)，或者差不多，那么很不幸，問(wèn)題不在tomcat本身，而是出在了tomcat到 weblogic的接口上。而tomcat是通過(guò)weblogic提供的EJB client jar去調(diào)用weblogic的EJB的，那你只好咨詢BEA去尋求解決方案了。
十、
1.基礎(chǔ)配置優(yōu)化
tomcat 6？ tomcat參數(shù)調(diào)優(yōu)?
JRockit JVM? JVM參數(shù)調(diào)優(yōu)？
Apache+Squid 處理靜態(tài)內(nèi)容？
2.業(yè)務(wù)層優(yōu)化
部分功能本地化，而不調(diào)remote session bean?
異步提交操作,JMS？
cache熱點(diǎn)數(shù)據(jù)？
3.展示層優(yōu)化
動(dòng)態(tài)頁(yè)面發(fā)布為靜態(tài)頁(yè)面？
Cache部分動(dòng)態(tài)頁(yè)面內(nèi)容？
十一、
對(duì)于樓主的問(wèn)題，以及公司的架構(gòu)方案，我認(rèn)為你們?nèi)匀辉诜稿e(cuò)！
誤區(qū)：遇到性能問(wèn)題的第一件事情就是找硬件和容器的事情!
性能問(wèn)題的基本上無(wú)一例外的都出在寫的程序有問(wèn)題，滿足不了伸縮性。
好好看看你們的程序吧，不要再給bea打電話了，你得到的建議，基本上都是用不到的。
robin的觀點(diǎn)是對(duì)的，我甚至懷疑你們的數(shù)據(jù)庫(kù)連接是否有釋放問(wèn)題的。
增加你們前端的內(nèi)存，多做緩存。hibernate的cache方案不差jdbc對(duì)數(shù)據(jù)庫(kù)的頻繁使用
html的書寫是否符合w3的規(guī)范
最好在一個(gè)服務(wù)器上部署整個(gè)應(yīng)用！
十二、
淘寶用的weblogic8,他們的web層使用的Turbine，且大量的使用velocity，由于對(duì)事務(wù)要求及其苛刻用到了ejb,也用到 spring很多其他服務(wù)，訪問(wèn)數(shù)據(jù)庫(kù)使用ibatis，他們對(duì)weblogic優(yōu)化到的極致加上外面也架了apache,，在如此高并發(fā)的情況，且高度復(fù)雜的搜索。。。，還能保持如此的響應(yīng)速度，確實(shí)很不錯(cuò)。
淘寶的搜索功能說(shuō)是在的非常強(qiáng)大，不曉得是不是yahoo中國(guó)來(lái)人做的，一直覺(jué)得很神奇
robbin大哥說(shuō)的還是很有道理，對(duì)于大多數(shù)門戶門戶網(wǎng)站，使用EJB確實(shí)浪費(fèi)，購(gòu)買weblogic的錢可以購(gòu)買很多硬件來(lái) apache,tomcat負(fù)載均衡遠(yuǎn)遠(yuǎn)勝過(guò)于ejb方案的性能。沒(méi)有絕對(duì)的性能好壞之分，主要還是看你的需求，weblogic永遠(yuǎn)是對(duì)于銀行，證券，電信的行業(yè)所準(zhǔn)備，他們所使用的硬件對(duì)象也絕對(duì)不是刀片，雙路至強(qiáng)的硬件這樣的東東。
十三、
經(jīng)過(guò)今天修改tomcat的參數(shù)，修改如下：
<Connector className="org.apache.coyote.tomcat4.CoyoteConnector"
port="8080" enableLookups="false" redirectPort="8443"
acceptCount="500" maxProcessors="500" minProcessors="500"
maxSpareProcessors="200"
connectionTimeout="20000"
useURIValidationHack="false" disableUploadTimeout="true" />
經(jīng)過(guò)測(cè)試，并發(fā)人數(shù)是可以達(dá)到像robbin所說(shuō)的一樣，能夠在600人左右，如果壓到并發(fā)700人，就有15%左右的失敗，雖然在調(diào)整上面參數(shù)之后，并發(fā)人數(shù)上去了，但是在同樣的時(shí)間內(nèi)所完成的事務(wù)數(shù)量下降了10%左右，并且響應(yīng)時(shí)間延遲了1秒左右，但從整體上來(lái)說(shuō)，犧牲一點(diǎn)事務(wù)吞吐量和響應(yīng)時(shí)間，并發(fā)人數(shù)能夠提高500，覺(jué)得還是值得的。謝謝robbin的建議。
由于本人使用的loadRunner 能支持的獨(dú)立client數(shù)量在100個(gè)，所以沒(méi)辦法對(duì)ejb進(jìn)行單獨(dú)的壓力測(cè)試。因?yàn)槲以趯?duì)前段應(yīng)用調(diào)用ejb時(shí)，最多并發(fā)用戶已經(jīng)達(dá)到1000個(gè)，但是通過(guò)監(jiān)控weblogic10中發(fā)布的ejb應(yīng)用和連接池，發(fā)現(xiàn)ejb應(yīng)用等待數(shù)量為0，但是連接池中最多有60個(gè)活動(dòng)連接，有7個(gè)連接在等待，因?yàn)榇藭r(shí)設(shè)置的weblogic連接池最大數(shù)量是60，后來(lái)對(duì)連接池?cái)?shù)量進(jìn)行增大到160個(gè)，再次進(jìn)行測(cè)試，發(fā)現(xiàn)性能反而不如把連接池?cái)?shù)量調(diào)為60個(gè)的時(shí)候。問(wèn)起bea的人，他們也說(shuō)不清楚原因。
同時(shí)對(duì)他們所提供的一種更好的jvm進(jìn)行測(cè)試，jvm的名字是 RealTime.發(fā)現(xiàn)性能并沒(méi)有太大改善。
我們現(xiàn)在的系統(tǒng)已經(jīng)作了很多的緩存，有全局的，有局部的，都是放到內(nèi)存中的HashMap，靜態(tài)的頁(yè)面都是放在apache上的，不過(guò)沒(méi)有使用 apr， 接下來(lái)如果有時(shí)間，會(huì)測(cè)試一下這個(gè)咚咚，。
che 前面是F5負(fù)載均衡器，在apache后面是tomcat，tomcat在公網(wǎng)上，然后通過(guò)內(nèi)網(wǎng)網(wǎng)卡訪問(wèn)weblogic，weblogic才能訪問(wèn)數(shù)據(jù)庫(kù)，tomcat不能直接訪問(wèn)數(shù)據(jù)庫(kù)的，由于以前的網(wǎng)絡(luò)結(jié)構(gòu)的原因，也有安全的原因，公司還有部分服務(wù)器在北京（無(wú)線事業(yè)部）和廣州（老系統(tǒng)，以后會(huì)逐漸遷移到上海），雖然現(xiàn)在也有其他的安全方案可以把tomcat放在內(nèi)網(wǎng)，去掉weblogic，但是這種改變是需要時(shí)間的，也要考慮平穩(wěn)過(guò)渡，所以還請(qǐng)各位理解。至于購(gòu)買weblogic，公司也是有自己的考慮的。因?yàn)橐郧熬褪沁\(yùn)行在weblogic上的，如果現(xiàn)在不用了，如果出了問(wèn)題，就很難辦了。
十四、是的，如果調(diào)整參數(shù)，可以達(dá)到并發(fā)人數(shù)達(dá)到1000以上，但是通過(guò)對(duì)比同樣壓力下的weblogic和tomcat，發(fā)現(xiàn)tomcat的響應(yīng)時(shí)間都比weblogic長(zhǎng)，并且tomcat的cpu的占用率達(dá)到45%-60%，而同樣的壓力下weblogic的cpu占用只有3%-5%。內(nèi)存都是2G都用了97%，說(shuō)明主要差別表現(xiàn)在cpu和相應(yīng)時(shí)間上，我沒(méi)有做tomcat 1000人并發(fā)測(cè)試，但是從以前600人并發(fā)的響應(yīng)時(shí)間判斷，我覺(jué)得響應(yīng)時(shí)間可能會(huì)超過(guò)15秒。所以從綜合各方面性能指標(biāo)考慮，我覺(jué)得要找出一個(gè)響應(yīng)時(shí)間，并發(fā)人數(shù)，完成交易數(shù)量3方面考慮折中，找出一個(gè)滿足應(yīng)用響應(yīng)時(shí)間和并發(fā)用戶的折中吧，如果是并發(fā)交易量比較大的應(yīng)用，我想應(yīng)該減少并發(fā)用戶，提高單位時(shí)間內(nèi)交易數(shù)量來(lái)滿足應(yīng)用需求吧。
十五、
又回到了realtime的定義，并不是很快的意思，而是響應(yīng)時(shí)間是可預(yù)計(jì)的。
而JVM對(duì)響應(yīng)時(shí)間可預(yù)計(jì)性的影響，主要表現(xiàn)在
1.線程調(diào)度受操作系統(tǒng)線程調(diào)度的影響
2.垃圾收集引起的暫停
所以jrockit選擇了動(dòng)態(tài)垃圾收集，以頻繁的收集來(lái)?yè)Q取每次中斷時(shí)間的減少，所以，對(duì)吞吐量來(lái)說(shuō)，是反而會(huì)下降的。大部分jvm都有吞吐量?jī)?yōu)先，短暫停時(shí)間兩種截然不同的垃圾收集算法。
http://www.javaeye.com/topic/117564?page=1
posted @
2011-02-24 15:17 [ 王志偉 ] 閱讀(219) |
評(píng)論 (0) |
編輯 收藏
轉(zhuǎn)自：http://blog.csdn.net/fanwenqiang666/archive/2010/01/15/5188961.aspx
問(wèn)題：
在Struts2中<jsp:forward page="xxx.action"></jsp:forward>失效了，不但調(diào)轉(zhuǎn)不過(guò)去還報(bào)404錯(cuò)誤。不知道是Struts2中不支持還是需要其他的配置。
原因：
因?yàn)閟truts2采用過(guò)濾器的方式處理請(qǐng)求，默認(rèn)情況時(shí)監(jiān)控url地址的變化
解決辦法
1、配置web.xml 解決
<filter-mapping>
<filter-name>struts2</filter-name>
<url-pattern >/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
2、用js近來(lái)做項(xiàng)目發(fā)現(xiàn)在Struts2中<jsp:forward page="xxx.action"></jsp:forward>失效了，不但調(diào)轉(zhuǎn)不過(guò)去還報(bào)404錯(cuò)誤。不知道是Struts2中不支持還是需要其他的配置。
解決
<script language="javascript">location.replace(URL)</script>
3、利用html meta
<meta http-equiv="refresh" content="0;URL=xxx.action">；
本文來(lái)自CSDN博客，轉(zhuǎn)載請(qǐng)標(biāo)明出處：http://blog.csdn.net/fanwenqiang666/archive/2010/01/15/5188961.aspx
posted @
2010-12-20 09:53 [ 王志偉 ] 閱讀(792) |
評(píng)論 (0) |
編輯 收藏