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