WebLogic Server中CMP實(shí)體bean的性能調(diào)優(yōu)10

第第頁(yè)WebLogicServer中CMP實(shí)體bean的性能調(diào)優(yōu)[10]WebLogicServer中CMP實(shí)體bean的性能調(diào)優(yōu)[10]

發(fā)表于：2023-03-11來(lái)源：：點(diǎn)擊數(shù)：標(biāo)簽：CMPBeanWeblogic實(shí)體SERVER

WebLogicServer中CMP實(shí)體bean的性能調(diào)優(yōu)[10]軟件測(cè)試Read-mostly數(shù)據(jù)也許最常見(jiàn)的情形是，數(shù)據(jù)被讀取的頻率大于其被更改的頻率。這正是緩存可成功應(yīng)用的場(chǎng)合。我建議使用啟用了事務(wù)間緩存的樂(lè)觀鎖定。如果數(shù)據(jù)庫(kù)模式可更改，我通常指定一個(gè)verify-colu

WebLogicServer中CMP實(shí)體bean的性能調(diào)優(yōu)[10]軟件測(cè)試

Read-mostly數(shù)據(jù)

也許最常見(jiàn)的情形是，數(shù)據(jù)被讀取的頻率大于其被更改的頻率。這正是緩存可成功應(yīng)用的場(chǎng)合。我建議使用啟用了事務(wù)間緩存的樂(lè)觀鎖定。如果數(shù)據(jù)庫(kù)模式可更改，我通常指定一個(gè)verify-columns的整型值，如果數(shù)據(jù)庫(kù)模式不可更改，就指定一個(gè)Modified值。如果您決定使用一個(gè)版本列，那么要保證外部進(jìn)程(如果有的話)在數(shù)據(jù)發(fā)生變更時(shí)遵守版本列更新的協(xié)定;否則，面臨更新丟失的風(fēng)險(xiǎn)。

從選擇適當(dāng)?shù)木彺娲笮》矫鎭?lái)看，應(yīng)該考慮多版本化，以及從finder方法返回的最大bean數(shù)目。一個(gè)不錯(cuò)的上限估計(jì)方法是將應(yīng)用程序需要同時(shí)處理的最大事務(wù)數(shù)乘以單個(gè)事務(wù)可以處理的最大bean數(shù)。我通常建議使用更加靈活的應(yīng)用程序級(jí)緩存，因?yàn)橥ǔ２惶赡芩械腃MP都同時(shí)被使用。應(yīng)用程序緩存對(duì)于所有CMP來(lái)說(shuō)是全局的，會(huì)自適應(yīng)不同bean的活動(dòng)。如果您定義了一個(gè)過(guò)大的應(yīng)用程序級(jí)緩存，可能會(huì)損害性能，因?yàn)樗惺聞?wù)都會(huì)串行訪問(wèn)這個(gè)唯一的緩存。對(duì)于大小適當(dāng)?shù)木彺鎭?lái)說(shuō)極少出現(xiàn)這個(gè)問(wèn)題，但是同樣，在您不確定緩存大小如何影響性能時(shí)應(yīng)該進(jìn)行性能測(cè)試。順便說(shuō)一下，良好的設(shè)計(jì)實(shí)踐是，避免創(chuàng)建返回任意多實(shí)體bean的finder方法(比如，大型表上的findAll())，因?yàn)檫@使得估計(jì)出適當(dāng)?shù)木彺娲笮∽兊脦缀醪豢赡堋?/p>

帶有事務(wù)間緩存的樂(lè)觀并發(fā)最適合有緩存碰撞“保護(hù)”的用例。比如，在一個(gè)項(xiàng)目用例中，應(yīng)用程序需要處理傳入消息(來(lái)自JMS)。每個(gè)消息記錄需要在數(shù)據(jù)庫(kù)表中創(chuàng)建，然后必須發(fā)送另一個(gè)消息作為響應(yīng);對(duì)于第二個(gè)消息來(lái)說(shuō)，應(yīng)用程序希望在一分鐘內(nèi)收到響應(yīng)，并且在收到該響應(yīng)時(shí)，同一條數(shù)據(jù)庫(kù)記錄得到更新。這時(shí)在該場(chǎng)景中應(yīng)用緩存會(huì)帶來(lái)巨大和直接的性能收益。我們“保證”每個(gè)被緩存的項(xiàng)目至少有一個(gè)碰撞，如果緩存對(duì)于保存CMP實(shí)例來(lái)說(shuō)過(guò)大的話。

另一個(gè)極端是目標(biāo)表太大，以至于不可能對(duì)同一數(shù)據(jù)作出重復(fù)請(qǐng)求。從實(shí)踐角度來(lái)看，這是不可行的，并且緩存這樣的數(shù)據(jù)不能提高性能。

在上述的read-mostly模式中，樂(lè)觀并發(fā)模式應(yīng)該是更好的選擇。read-mostly模式不能用于集群中，不能防止出現(xiàn)更新丟失，并且一般來(lái)說(shuō)不便于使用。本文講述它是為了提供關(guān)于所有可用策略的整體情況，但是我不鼓勵(lì)在現(xiàn)代應(yīng)用程序中使用它。

Read-mostly數(shù)據(jù)

如果您的應(yīng)用程序主要是插入或更新記錄，那么緩存數(shù)據(jù)意義不大，因?yàn)閹缀醪粫?huì)再次訪問(wèn)它們。在只進(jìn)行插入操作(OLTP)的極端情況下，緩存反而會(huì)減慢處理速度。非重復(fù)性更新(對(duì)表中遠(yuǎn)超過(guò)緩存大小的隨機(jī)行的更新)也很少?gòu)腃MP緩存中受益。此外，隨著更新數(shù)目相對(duì)于讀取次數(shù)的增加，樂(lè)觀并發(fā)策略的表現(xiàn)越來(lái)越差，因?yàn)闀?huì)出現(xiàn)大量的樂(lè)觀并發(fā)異常。實(shí)際上，如果您的應(yīng)用程序只在數(shù)據(jù)庫(kù)中更新和插入記錄，就根本沒(méi)有必要使用實(shí)體bean。

結(jié)束語(yǔ)

從本文的長(zhǎng)度就可以看出，調(diào)整CMP2.0EJB有很多內(nèi)容。我首先講述了可用的各種并發(fā)策略。然后討論了一些重要的性能策略：read