[JBoss Messaging] - I got some performance problem while sending a lot of messag
by gary.c.chen
Hi,
I am now attempting to use JBM as a JMS Server on my application.
I did a performance test on it using the JBossJMSNewPerformanceBenchmark framework,
but the result was so difference from the performance result that we saw on the development wiki.
My test environment and executors setup were as follow :
1. I was uesing two machines to achieve this test, one had a JBoss AS running on it (machine A),
another was deployed a MySql database server (machine B), I was using it as the JBM persistence store.
I deployed the PerformanceBenchmark framework JBM executor (the rmi-executor-scoped.sar file) as a MBean on JBoss AS (machine A).
And I runned the control & report tool (using 'ant run') on machine B.And all the executor and JBoss AS configurations were using
default parameters except the JVM option using for starting JBoss AS.I setted min and max VM memory to 1024m.
The two machines were all using Sun JDK 1.5_15.
2. My first test config was as follow :
| <default-executor-name>REMOTE</default-executor-name>
| <destination>/queue/testQueue</destination>
| <connection-factory>/ConnectionFactory</connection-factory>
| <acknowledgment-mode>AUTO_ACKNOWLEDGE</acknowledgment-mode>
| <delivery-mode>NON_PERSISTENT</delivery-mode>
| <message-factory-class>org.jboss.jms.perf.framework.factories.MessageMessageFactory</message-factory-class>
| <message-size>100</message-size>
|
| <!-- safeguard for receive jobs that block waiting messages will never arrive -->
| <duration>600000</duration>
|
| <providers>
| <provider name="JBossMessaging">
| <factory>org.jnp.interfaces.NamingContextFactory</factory>
| <url>jnp://150.236.80.206:1099</url>
| <pkg>org.jboss.naming:org.jnp.interfaces</pkg>
| <executor name="REMOTE" url="rmi://remote-messaging"/>
| <executor name="REMOTE2" url="rmi://remote-messaging2"/>
| <executor name="COLOCATED" url="rmi://local-messaging"/>
| <executor name="COLOCATED2" url="rmi://local-messaging2"/>
| <color>255,0,0</color>
| </provider>
| </providers>
|
| <performance-tests>
| <performance-test name="Throughput-INVM">
|
| <graph>
| <x job="send" result="yes" metric="rate" label="measured send rate (msg/s)"/>
| <y job="receive" result="yes" metric="rate" label="measured receive rate (msg/s)" />
| </graph>
|
| <destination>/queue/simpleQueue</destination>
| <delivery-mode>NON_PERSISTENT</delivery-mode>
| <message-size>200</message-size>
| <duration>3600000</duration>
|
| <drain/>
| <parallel>
| <send rate="1000" executor="COLOCATED"/>
| <receive executor="COLOCATED2"/>
| </parallel>
|
| <drain/>
|
| <parallel>
| <send rate="2000" executor="COLOCATED"/>
| <receive executor="COLOCATED2"/>
| </parallel>
|
| <drain/>
|
| <parallel>
| <send rate="3000" executor="COLOCATED"/>
| <receive executor="COLOCATED2"/>
| </parallel>
|
| <drain/>
|
| <parallel>
| <send rate="4000" executor="COLOCATED"/>
| <receive executor="COLOCATED2"/>
| </parallel>
|
| <drain/>
|
| <parallel>
| <send rate="5000" executor="COLOCATED"/>
| <receive executor="COLOCATED2"/>
| </parallel>
|
| <drain/>
|
| <parallel>
| <send rate="6000" executor="COLOCATED"/>
| <receive executor="COLOCATED2"/>
| </parallel>
|
|
| <drain/>
| <execution provider="JBossMessaging"/>
| <!--<execution provider="JBossMQ"/>-->
|
| </performance-test>
| </performance-tests>
|
|
The test runned an hour per SEND JOB so I thought I could see the performance after JBM went to
a steady status and the result was as follow :
|
| Execution 1 (provider JBossMessaging)
| 0. DRAIN JOB drained 0 messages
| 1. PARALLEL
| SEND JOB sent 3360753 messages in 3601210 ms with a target rate 1000 messages/sec, real rate 933.23 messages/sec
| RECEIVE JOB received 50753 messages in 3600007 ms with a target rate 0 messages/sec, real rate 14.1 messages/sec
| 2. DRAIN JOB drained 2000 messages
| 3. PARALLEL
| SEND JOB sent 1550066 messages in 3601180 ms with a target rate 2000 messages/sec, real rate 430.43 messages/sec
| RECEIVE JOB received 2276000 messages in 3600007 ms with a target rate 0 messages/sec, real rate 632.22 messages/sec
| 4. DRAIN JOB drained 2000 messages
| 5. PARALLEL
| SEND JOB sent 1556184 messages in 3603317 ms with a target rate 3000 messages/sec, real rate 431.88 messages/sec
| RECEIVE JOB received 2278000 messages in 3600001 ms with a target rate 0 messages/sec, real rate 632.78 messages/sec
| 6. DRAIN JOB drained 2000 messages
| 7. PARALLEL
| SEND JOB sent 1732609 messages in 3601484 ms with a target rate 4000 messages/sec, real rate 481.08 messages/sec
| RECEIVE JOB received 2026000 messages in 3600001 ms with a target rate 0 messages/sec, real rate 562.78 messages/sec
| 8. DRAIN JOB drained 2000 messages
| 9. PARALLEL
| SEND JOB sent 1601025 messages in 3600575 ms with a target rate 5000 messages/sec, real rate 444.66 messages/sec
| RECEIVE JOB received 2240000 messages in 3600010 ms with a target rate 0 messages/sec, real rate 622.22 messages/sec
| 10. DRAIN JOB drained 2000 messages
| 11. PARALLEL
| SEND JOB sent 1593108 messages in 3601466 ms with a target rate 6000 messages/sec, real rate 442.35 messages/sec
| RECEIVE JOB received 2282000 messages in 3600001 ms with a target rate 0 messages/sec, real rate 633.89 messages/sec
| 12. DRAIN JOB drained 2000 messages
|
|
So I think the performance under this case was so poor.
And then I run a couple of testes using a config as follow :
| <duration>30000</duration>
|
and the others parameter were the same as above.
But I got the results which send rate VS receive rate were so unsteady.
for example some time I got a value as follow :
|
| SEND JOB sent 119970 messages in 30002 ms with a target rate 4000 messages/sec, real rate 3998.73 messages/sec
| RECEIVE JOB received 322885 messages in 30014 ms with a target rate 0 messages/sec, real rate 10757.81 messages/sec
|
|
and some time I got a value as follow :
|
| SEND JOB sent 119978 messages in 30004 ms with a target rate 4000 messages/sec, real rate 3998.73 messages/sec
| RECEIVE JOB received 119978 messages in 30016 ms with a target rate 0 messages/sec, real rate 3997.13 messages/sec
|
|
and event the recevie rate change trend was so difference between testes,
some time the recevie rate got down at the point of send rate 3998.73 messages/sec, and went to 4998.43 messages/sec at the point of
send rate 4997.1 messages/sec and 5995.9 messages/sec at the point of send rate 5998.3 messages/sec,
some time it still went up and never got down.
So I have some question :
1. Why the performance was so poor in the first test, am I having any problem ?
2. If the duration parameter set to 30 sec, can I get a steady performance result ?
3. Why the receive rate was so unsteady in the second test ?
Thanks.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159179#4159179
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159179
17 years, 10 months
Delivery Failure
by Postmaster
---------------------------------------------------------------------------------
The message you sent to andplast.com/expo was rejected because the quota for the mailbox has been exceeded.
The subject of the message follows:
Subject: =?windows-1251?B?0fDu9+3u5SDI5+Pu8u7i6+Xt6OUg0eDr/O3o6u7i?=
---------------------------------------------------------------------------------
17 years, 10 months
[EJB 3.0] - Re: EntityManager Injection, Null Pointer Exception. (Sorry.
by repkin
I am so thankful for your helps, finally it worked.
This is the final situation:
I have changed ejb call part like that:
| Context context = new InitialContext();
| PrStaffInterface prstaff = (PrStaffInterface)context.lookup("surgeonfish/PrStaffHome/local");
| prstaff.findById(new Integer(username));
|
And I have changed little part of persistence.xml
| <persistence>
| <persistence-unit name="time_report_persistence_context">
| <provider>org.hibernate.ejb.HibernatePersistence</provider>
| <jta-data-source>java:/time_reporting_data_source</jta-data-source>
| <jar-file>/surgeonfish.jar</jar-file>-->this place changed
| <properties>
| <property name="hibernate.hbm2ddl.auto" value="create-drop"/>
| <property name="hibernate.show_sql" value="true"/>
| <property name="dialect">org.hibernate.dialect.MySQLDialect</property>
| <property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.JBossTransactionManagerLookup"/>
| </properties>
| </persistence-unit>
| </persistence>
|
I have thought, I dont need to lookup. The ejb container is injecting, or intercepting at the object initialization and giving already created ejb object.
Thanks again.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4159169#4159169
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4159169
17 years, 10 months
