Proxy running slow on AIX

66 views
Skip to first unread message

dswee...@gmail.com

unread,
Jun 28, 2016, 2:26:05 AM6/28/16
to membrane-monitor
Hello, I am setting up membrane to run on an AIX server, but it's running about 5-10 times slower then a direct call, compared to the 10-15 ms slower on a windows box. Is this normal behavior or an untested configuration? 
I'm running membrane 4.1.1 via the command line (no gui monitor.) The slowdown seems to be coming from the read on the header of the request. i.e: "line = HttpUtil.readStartLine(in)" from core.http.Response.parseStartLine().

Thomas Bayer

unread,
Jun 28, 2016, 3:14:54 AM6/28/16
to membrane...@googlegroups.com

Hi,

Membrane is usually quite fast and you can have roundtrip times faster than 1ms. Maybe you can give me a bit more details:

 

-          How long does a direct call take?

-          How long does a proxied call take?

-          How big are the messages?

 

Cheers,

Thomas

--
You received this message because you are subscribed to the Google Groups "membrane-monitor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to membrane-monit...@googlegroups.com.
To post to this group, send email to membrane...@googlegroups.com.
Visit this group at https://groups.google.com/group/membrane-monitor.
For more options, visit https://groups.google.com/d/optout.

dswee...@gmail.com

unread,
Jul 7, 2016, 10:48:15 AM7/7/16
to membrane-monitor
Hi Thomas,

Sorry for the late reply, this got back burnered for a while. I'm making a few calls to a filenet p8 server. I'm uploading a file, getting it's content, moving it around, and deleting it. The upload and get content have roughly 750 KB transmissions (on the request for upload and the response for get content) and the rest have 5 KB - 15 KB (there are multiple calls for each function. mostly little stuff like getting properties of the server).

For the get contents, moves, and deletes I'm getting 40-50 ms direct and 250 -350 ms for the proxy. The upload varies a bit more with usually 1000 - 1200 ms direct to 2000 - 3000 ms proxy.

I should note I ran this code against another system on a windows box and got only 10-14 ms slowdown on all calls.

Thanks!
David

Thomas Bayer

unread,
Jul 8, 2016, 5:12:02 AM7/8/16
to membrane...@googlegroups.com

Hi,

thanks for the details. The delay is far to long. Can you log the request and response headers using:

 

http://www.membrane-soa.org/service-proxy-doc/4.1/configuration/reference/log.htm

 

together with information about the time an exchange took?

 

You can also try to run the proxy on a different computer and compare that with the times from AIX installation?

dswee...@gmail.com

unread,
Jul 8, 2016, 11:19:38 AM7/8/16
to membrane-monitor
Thomas,

Attached a txt file with the output. The exchanges that are mentioned above are marked with (UPLOAD), (DELETE), (MOVE LOCATION), and (GET CONTENT).

Thanks!
output.txt

dswee...@gmail.com

unread,
Jan 9, 2017, 3:19:11 PM1/9/17
to membrane-monitor, dswee...@gmail.com
Thomas,

I finally got back to this and in case anyone else ran into this problem, AIX has a setting to delay and batch up it's tcp ack requests. So before membrane read the response from the server it was waiting for an ack which was delayed by 150-200 ms by the server so it hung. I turned off the setting and it works fine now. To turn off the delay the command was "no -p -o tcp_nodelayack=1"

Thanks,
David

Thomas Bayer

unread,
Jan 11, 2017, 1:05:17 PM1/11/17
to membrane...@googlegroups.com

Hi David,

wow thanks! This was a hard to solve problem. We should add that to the FAQ.

Cheers,
Thomas


Am 09.01.17 um 21:19 schrieb dswee...@gmail.com:

dswee...@gmail.com

unread,
Jan 11, 2017, 1:13:42 PM1/11/17
to membrane-monitor
Also, I found a resource here that outlined the problem and suggested making only 1 big write instead of a bunch of little writes. I changed the write(OutputStream out) method in the core.http.Message class to write to a temp ByteArrayOutputStream first then wrote that to the real stream and it also fixed the delay.
Reply all
Reply to author
Forward
0 new messages