需要仔細推敲的是內(nèi)存結(jié)構(gòu)的區(qū)別將如何影響服務(wù)器的性能水平。SPARC64 VI的芯片的L2高速緩存數(shù)量是UltraSPARC-IV+的三倍，但是UltraSPARC-IV+總的芯片高速緩存數(shù)目卻是UltraSPARC-IV+的5.6倍。眾所周知，諸如在線事務(wù)處理或者聯(lián)機事務(wù)處理這樣的工作負載很大程度上受UltraSPARC-IV+的附加L3高速緩沖存儲器影響。

對多線程的關(guān)注：SPARC VI 64處理器的雙線程不是將單核的吞吐量翻倍。其目的是將CPU核的等待時間最小化，并提高CPU核心的效率。一個關(guān)鍵信息是雙線程分享了兩個Translation Lookaside磁盤緩存。下面的數(shù)據(jù)就是在一個核心出現(xiàn)故障的情況下獲得的，以下是一些更為詳盡的數(shù)據(jù)。

當(dāng)然這僅僅是芯片的對比，以下信息可以讓我們了解更多M9000和E25000服務(wù)器的情況：

在這個表格中，我們對兩款服務(wù)器的大容量有了更清晰的認識，但是并不能幫助我們評估性能。當(dāng)前，我沒有能力對這兩款滿負荷的服務(wù)器進行測試，因此我只能進行如下測試。關(guān)鍵是在每個系統(tǒng)上采用相同數(shù)量的CPU。

以下是被測試的硬件

M值

從性能方面來說，我們能看到的第一個度量被稱作M值。我們的推測可以以這些值為基點。注意：下面的值是針對如上表所描述的四個主板的系統(tǒng)。

有意思的是CPU頻率因數(shù)很接近這一值：2280/1800 = 1.26

我們得出結(jié)論：如果讓現(xiàn)在的E25k升級為4-CMUs M9000, 速度就能加快1.33倍。

Java工作量

我們通過使用不同的100%Java(1.6)工作量來說明問題，這樣可以更精確。

1. iGenCPU v3

2. iGenRAM v3 – Lotto simulation (Memory allocation and search) （記憶分配及搜索）

3. iGenBATCH v2 – (Oracle 10g batch using partionning, triggers, stored procedures and sequences)

4. iGenOLTP v4 – (Heavy-weight OLTP) 在線處理程序

下表中這些數(shù)值都是峰值，是通過建立完全穩(wěn)定特性曲線得到的。提到的響應(yīng)時間是平均值、峰值和毫秒值。

為試圖比較因數(shù)M值1.33，如果E25k是1的話，看看能得出什么結(jié)果。

首先是吞吐量：

如下圖：

吞吐量性能方面的注意

1. 可以看到，就純CPU計算而言，M9000比 E25000強大2.4倍。

2. M9000的記憶分配和獲取時間使得吞吐量增大了1.7倍。

3.只有一個值低于M值：在線處理程序（OLTP）。似乎總的核緩存減少對這一工作負荷產(chǎn)生了很大影響。

下表是最高吞吐時的平均反應(yīng)時。（仍然以E25k為基數(shù)1）。

下面是圖表：

反應(yīng)時間：

1． CPU & RAM的微軟標(biāo)準(zhǔn)顯示出反應(yīng)時間方面獲得的巨大進步。M9000的E25k在最大輸貫量時能夠接收400ms。
2，憑借大量基準(zhǔn)和CPU集中數(shù)據(jù)庫管理系統(tǒng)存儲程序，我們得到0.69這一因數(shù)。

令人失望的是當(dāng)吞吐量達到峰值時，M9000數(shù)據(jù)庫管理系統(tǒng)的在線處理程序會增加反應(yīng)時間。希望新版Solaris 和數(shù)據(jù)庫管理系統(tǒng)Oracle 10g能夠?qū)Υ擞兴倪M。

多易