Weblogic 9.xのSelf Tuning機能

SpingFramework 2.0を触り始め、例題にくっついているPetstoreのSpring Framework版である、jpetstoreをWLS 9.2で動かして見ました。

すぐにデプロイできたものの、負荷をかけるとOracleの一意制約エラーが多発。中を見て見ると、OrderIDを取得するとことがスレッドセーフではない。なんとまあ、すごい作り。でもOracleを使う人用に、OrderIDをOracleのsequenceを使って取り出す仕組みも用意されていたので、こちらに切り替えました。

それから、apache commonsのDBプールを使っていたので、こんな感じで書き換えてみました。

dataAccessContext-local.xml

<!-- <bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName" value="${jdbc.driverClassName}"/> <property name="url" value="${jdbc.url}"/> <property name="username" value="${jdbc.username}"/> <property name="password" value="${jdbc.password}"/> </bean> --> <!-- ここをWLSのConnection Poolを使えるように変更 --> <bean id="dsJndiTemplate" class="org.springframework.jndi.JndiTemplate"> <property name="environment"> <props> <prop key="java.naming.provider.url">t3://localhost:7001</prop> <prop key="java.naming.factory.initial">weblogic.jndi.WLInitialContextFactory</prop> <prop key="java.naming.security.principal">weblogic</prop> <prop key="java.naming.security.credentials">weblogic</prop> </props> </property> </bean> <bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean"> <property name="jndiName"><value>jpetstore</value></property> <property name="jndiTemplate"><ref local="dsJndiTemplate"/></property> </bean>

この、接続プールにCommonsを使った場合とWLSのプールを使った場合ではどのくらいパフォーマンスが違うのかを計測してみました。（仮想ユーザ数：30）

	Apache Commons DB Pool	WLS 9.2 DB Pool
スループット(page/sec)	715	675
レスポンスタイム(msec)	41	45

WLSの場合の方が接続プールのインプリメントがよいはずなので、パフォーマンスもよいはずなのに、思ったような数字が出なかったのは興味深い。このときのWLSサーバ側のCPU使用率はどちらも90%前後でした。(Xeon 2.8GHz x 2CPU, Hyperthread, -Xmx1g)

ちなみに、Azul Compute Applianceをつけたサーバで同じパフォーマンス計測を行ってみました。

	Apache Commons DB Pool	WLS 9.2 DB Pool
スループット(page/sec)	967	1900
レスポンスタイム(msec)	30	16

Azulを使った場合には、WLSのJDBC接続プールでは圧倒的なスループットを達成できました。ちなみにこのときのWLSサーバのCPU使用率はどちらの場合でも、わずか12%程度でした。

この1900tpsというスループットは実はWLS 9.2のSelf Tuning機能をOffにして、従来の実行スレッドを設定する方法に変更して達成できたのだが、Self Tuningをonにしていると、1200tpsぐらいで止まってしまい、WLSのモニタを見ると、スレッドのキューに溜まっている状態になっていました。これでは都合が悪いので、WLSのconfig.xmlに

<server> <name>AdminServer</name> <ssl> <enabled>false</enabled> </ssl> <execute-queue> <name>default</name> <thread-count>40</thread-count> <threads-minimum>40</threads-minimum> </execute-queue> <use81-style-execute-queues>true</use81-style-execute-queues> <listen-address></listen-address> </serverv>

というようにして、defaultの実行キューを設定しました。
マルチコアのAzulの場合には、これはOffにしたほうが多くの場合はパフォーマンスが良いようです。それにしても、とあるお客様のアプリケーションがSpring Frameworkで書かれていて、スレッドコンテンションだらけだったので、Springのbeanのデフォルトのスコープがsingletonなのが悪いのかと思っていたのだが、どうやらアプリケーションのインプリメントの方法が根本から間違っていたのだとわかってきました。こういうフレームワークを使うアプリケーションのチューニングは、中身を知らないと触りようがないし、開発者も説得できないので、日々勉強だということを身にしみさせられました。痛い・・・