Return-Path: Delivered-To: apmail-perl-modperl-archive@www.apache.org Received: (qmail 45555 invoked from network); 1 Sep 2010 11:51:33 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 1 Sep 2010 11:51:33 -0000 Received: (qmail 97837 invoked by uid 500); 1 Sep 2010 11:51:32 -0000 Delivered-To: apmail-perl-modperl-archive@perl.apache.org Received: (qmail 97728 invoked by uid 500); 1 Sep 2010 11:51:31 -0000 Mailing-List: contact modperl-help@perl.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list modperl@perl.apache.org Received: (qmail 97720 invoked by uid 99); 1 Sep 2010 11:51:30 -0000 Received: from Unknown (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Sep 2010 11:51:30 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of neessen@cleverbridge.com designates 87.79.27.101 as permitted sender) Received: from [87.79.27.101] (HELO mail.cleverbridge.com) (87.79.27.101) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 01 Sep 2010 11:51:07 +0000 Received: from zimbra.cgn.cleverbridge.com (homer.cgn.cleverbridge.com [10.0.5.150]) by mail.cleverbridge.com (Postfix) with ESMTP id EFDC69C545B for ; Wed, 1 Sep 2010 13:50:46 +0200 (CEST) From: "Winfried Neessen" To: Subject: Strange behaviour with Pseudo-Proxy script Date: Wed, 1 Sep 2010 13:50:46 +0200 (CEST) Message-ID: <004901cb49cb$ea688c20$bf39a460$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01CB49DC.ADF15C20" X-Mailer: Microsoft Office Outlook 12.0 X-Mailer: Zimbra 6.0.7_GA_2476.RHEL4 (ZimbraConnectorForOutlook/6.0.5902.6) Content-Language: de Thread-Index: ActJy+oh/6egmGL8SHuycJvkC2kBnQ== X-Originating-IP: [10.0.38.10] X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. ------=_NextPart_000_004A_01CB49DC.ADF15C20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am having a strange issue with a mod_perl handler which I've written lately. A little background. we are using a mod_perl script for our self-developed MS .NET application. The application connects to the frontend server, where the mod_perl "proxy" is running. The script does some kind of load_balancing and then proxies the request to the backend and providest the answer from the backend back to the application. This concept is working fine, but the initial version of the proxy script is poorly written. It first collects all data from the client in memory (which might be a pretty high amount of data (up to 100MB)), then send the stuff to the backend and then provides the answer. This causes bad memory consumption- especially if there are more than 100 concurrent users. Also the script is no real mod_perl script, but uses ModPerl::Registry instead. So I've re-written the whole script from scratch. I've written it as "real" mod_perl handler module. It's now working with chunks of data to be sent and received. Everything seems to working fine- except of one thing. The .NET app has the ability to upload a file to the backend. With the original script the upload usually has at least about 1-2MB/sec bandwidth. but with the new script that I've written, it only provides a throughput of about 300kb/sec. I did couple of profiling already, but wasn't able to find the cause of this. So I am wondering if someone of the mod_perl community has some advices or hints, how to resolve this issue. Every help or thought-provoking impulse is highly appreciated. Thanks Winni ------=_NextPart_000_004A_01CB49DC.ADF15C20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am having a strange issue with = a mod_perl handler which I’ve written lately.

 

A little background… we = are using a mod_perl script for our self-developed MS .NET = application.

The application connects to the = frontend server, where the mod_perl “proxy” is running. The = script

does some kind of load_balancing = and then proxies the request to the backend and providest the

answer from the backend back to = the application. This concept is working fine, but the initial = version

of the proxy script is poorly = written. It first collects all data from the client in memory (which might = be

a pretty high amount of data (up = to 100MB)), then send the stuff to the backend and then provides =

the answer… This causes = bad memory consumption- especially if there are more than 100 = concurrent

users. Also the script is no = real mod_perl script, but uses ModPerl::Registry instead.

 

So I’ve re-written the = whole script from scratch. I’ve written it as “real” mod_perl = handler module.

It’s now working with = chunks of data to be sent and received. Everything seems to working fine- =

except of one thing… The = .NET app has the ability to upload a file to the backend. With the original =

script the upload usually has at = least about 1-2MB/sec bandwidth… but with the new script that =

I’ve written, it only = provides a throughput of about 300kb/sec. I did couple of profiling = already,

but wasn’t able to find = the cause of this.

 

So I am wondering if someone of = the mod_perl community has some advices or hints, how to = resolve

this issue. Every help or = thought-provoking impulse is highly appreciated.

 


Thanks

Winni

------=_NextPart_000_004A_01CB49DC.ADF15C20--