We recently setup communication with a new partner, who I knew would be sending small XML files (looks like they're only about 50KB each). What I didn't know until today (because my Java heap was exhausted) is that they could routinely be transferring 10K or more of these files per day. I increased the Java heap max to 512MB and the initial to 128MB, but I was wondering if anyone had any other recommendations for streamlining things? Nothing is completely out of bounds. For instance, I considered, if necessary, running multiple instances of MEC on one or more hosts, symlinking or NFSing the configuration and/or installation, and fronting them with a load balancer. I'm sure other people have more elegant Java/MEC tweaks to suggest ; )
Thanks,
Chaz
Chaz,
we worked a lot on optimizing the resource consumption in the actual codebase of the mendelson AS2 server. For a high load in productive environment I would recommend to switch to the commercial version.
Regards
Heller
Point taken. I can see that the Commercial+SP license is E1999, but how much is the yearly SP?
Thanks,
Chaz
Chaz,
This is a package price for the license (1490 EUR) and 2 years of maintenance. The yearly maintenance is 18% of the base license price.
Regards
Heller
OK, so the free version is failing miserably...falling over after 1342 files today, which were spread over about 8 hours. It's now got 2GB of RAM, with a Java heap of 1024M, and 2 virtual CPUs.
I also don't understand how we can use more than 1 CPU for 8 hours and only receive 1342 files.
Is there a way I can test the commercial product to see if it solves our problem?
Thanks,
Chaz
My server shows that it stopped receiving files at 2:37 AM (after about 1992 of them), but the Java process is still taking up an entire CPU. I've also got 80948 files in _rawincoming, so I would expect the Java process to be working on decrypting those, but the file count in _rawincoming isn't dropping, the count in inbox\tradingpartner doesn't seem to be rising, and as20.log has these messages with current timestamps:
[Jul 14, 2010 5:29:25 PM] 20408221.1279031322694.JavaMail.rptib@turner2.bas.them.com: AS2 message is encrypted.
[Jul 14, 2010 5:29:25 PM] 20408221.1279031322694.JavaMail.rptib@turner2.bas.them.com: The data has been decrypted using the key "transfertest".
[Jul 14, 2010 5:29:25 PM] 20408221.1279031322694.JavaMail.rptib@turner2.bas.them.com: AS2 message is signed.
[Jul 14, 2010 5:30:03 PM] 20408221.1279031322694.JavaMail.rptib@turner2.bas.them.com: The sender used the algorithm SHA1 to sign the message.
[Jul 14, 2010 5:30:03 PM] 20408221.1279031322694.JavaMail.rptib@turner2.bas.them.com: Using certificate "elytis2.bas.them.com (them enterprise ca 1)" to verify signature.
[Jul 14, 2010 5:30:03 PM] 20408221.1279031322694.JavaMail.rptib@turner2.bas.them.com: Digital signature verified successful.
[Jul 14, 2010 5:30:03 PM] 20408221.1279031322694.JavaMail.rptib@turner2.bas.them.com: Found 1 payload attachments in the message.
[Jul 14, 2010 5:30:03 PM] 1235691.1279031322733.JavaMail.rptib@turner2.bas.them.com: Incoming transmission is a AS2 message, raw message size: 8.99 KB.
Can someone clue me into what this machine is working so hard on?
Thanks,
Chaz
I was just informed that, sometime next week, our partner will be looking to dry run 158K messages. I'm going to rebuild this test box on 64-bit hardware with 12 cores and 32GB RAM and rerun my own tests internally. In the meantime, any hints regarding improving performance, would be greatly appreciated, as would a trial of the commercial version.
Thanks,
Chaz
Chaz,
I experienced heap memory problems earlier when sending messages. Heller confirmed some "serialization problems" related to the encryption/signing process in the current open source release. It is a problem mec working together with the third party encryption library. Heller confirmed he corrected that for the commercial version and new release. Maybe your problem is related?
Tobias
Tobias,
Thanks for the input. We're going to try the commercial version. Fingers crossed.
Thanks,
Chaz