Questions about throughput
sjtai, eingfoan,
I made some small tests to check the dependency of the message size and the message preparation time (encrypting, signing), here are the values (just a single test to get an idea):
size: 10kB, preparation time 31ms
size: 50kB, preparation time 31ms
size: 100kB, preparation time 31ms
size: 200kB, preparation time 156ms
size: 300kB, preparation time 100ms
size: 500kB, preparation time 141ms
size: 1MB, preparation time 235ms
That means that the processing time to create (encrypt, sign, build MIME structure) an AS2 message from a file seems not to differ very much if the message size is < 200KB.
I sent 100 messages of 100 kB to the mendelson as2 test server. It took 2 minutes to finish the transactions (0.83 msg/s) (The transfer time depends also on the bandwidth). And you are right, there is a behavior that influences the throughput in a negative way:
m-e-c as2 contains a send queue. Building the as2 messages and sending them to the send queue works really fast (about 30ms per message, see above). But at the moment there are only 3 processes in the as2 server that listen to the send queue and send the data parallel via HTTP/S. And this seems to be a bottle neck if you would like to send a big amount of messages per time.
We will modify this for the next version.
Edit: We modified the codebase and got now 1.1 msg/s as throughput (100kB each).
Regards
Heller
heller,
Thanks for sharing the test results. Is the code available from sourceforge, or is it available for commercial license user only? How can I get the changes you've made?
BTW, in your posting earlier, you mentioned about "send queue". Were you referring to JMS? I didn't use JMS for my tests. I did the tests by copying files to the recipient's outbox folder.
Regards,
Tai
sjtai,
We are uploading the code for every new version of m-e-c as2 the the cvs of sourceforge, a dev snapshot is not available. That means that the changes are available on the next release of m-e-c as2.
The send queue I mentioned earlier is based on JMS and is part of m-e-c as2. Even if you are polling a directory the files are enqueued and not send immediatly (else there would be a problem if you have 1000 files in your directory and m-e-c as2 tries to open 1000 http connections simutanously). There are listeners/receiver on this queue, they care for the HTTP send mechanism to your TP. Please have a look at http://mec-as2.org/images/mec_as2_architecture.jpg for the architecture.
Regards
Heller
When using sockets, POSIX limitation is up to maxi 5 simultaneous opened socket on a port.
The caching is done by IP stacks in low level.
TCP/IP packets are treated when less than 5 simultaneous sockets are opened on a port, and a new socket is created.
That is the limitation on Unices, I guess it is the same on Windows. The reason is for obvious questions of load of system, if not it would be easy to do a deny of service, by sending millions of simultaneous connections on a port.
Don't be confused : you can do 1000 HTTP connection simultaneously, the packets will be stored in IP stack and treated. If the server is too slow or overloaded, some request will fail in timeout.
© 1999-2008 mendelson-e-commerce GmbH. All right reserved.
Hi there,
I did some internal testing last week between two PCs running mec. I use the dir polling approach to send the test files. The hardware configurations were as follow:
Both PCs were connected to the LAN via cables.
The results:
Question: there seems to be no difference in throughput in the above tests although the average message size is different. Is this expected?
I'd appreciate it if anyone can shed some light on the results.
Regards,
Tai