Performance tuning a client simulator?

[JayPoser]

I bet this is done all the time using jpos, such that a client
simulator is used for mimicking switch responses.
We're doing it too, but for whatever reason, the sim is hogging the
cpu at rather low tx throughput {20/s}. This could be because a rather
common utility bsh script is used for simulating responses, so we'll
simplify it for this purpose.
However, I was wondering what if any jpos cfg parms could be affected
to allow the simulator to do its thing as fast as possible, besides
the usual java jvm memory flags.

The setup:
[WL9 hosted jpos integration, running a QMUX fronted ISOSrv] <=> [jpos
client sim with qmux]

Tx msgs are originated from the WL side, simulator{really a BSH
script} does some churning and sends the response back to the isosrv.

Thanks,
Karl
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to jpos-users@...
To unsubscribe from this group, send email to jpos-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Alejandro Revilla]

Our goal while designing the simulator was to use it to test the
business logic of a server, so we didn't pay too much attention
into making it fast.

There's a lot of room for improvement, the first thing that comes to
mind would be to pre-generate a bunch of messages and then send them
over the socket at once, probably using java.nio.

We have support to use BSH at the field level, if you have say 10 fields
that has macros then we'd have to call 10 times the BSH interpreter
which is overkill.

You can use the client simulator to generate some traffic, catch the
traffic with a tool such as netcat and then re-play it against the
server at full speed using a set of netcat processes.

--Alejandro

On Wed, Jul 16, 2008 at 05:11:03PM -0700, JayPoser wrote:

>
> I bet this is done all the time using jpos, such that a client
> simulator is used for mimicking switch responses.
> We're doing it too, but for whatever reason, the sim is hogging the
> cpu at rather low tx throughput {20/s}. This could be because a rather
> common utility bsh script is used for simulating responses, so we'll
> simplify it for this purpose.
> However, I was wondering what if any jpos cfg parms could be affected
> to allow the simulator to do its thing as fast as possible, besides
> the usual java jvm memory flags.
>
> The setup:
> [WL9 hosted jpos integration, running a QMUX fronted ISOSrv] <=> [jpos
> client sim with qmux]
>
> Tx msgs are originated from the WL side, simulator{really a BSH
> script} does some churning and sends the response back to the isosrv.
>
> Thanks,
> Karl
> >

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to jpos-users@...
To unsubscribe from this group, send email to jpos-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---