Article delegate-en/2558 of [1-4096] on the server localhost:7119
  upper oldest olders older1 this newer1 newers latest
search
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
[Reference:<_A2557@delegate-en.ML_>]
Newsgroups: mail-lists.delegate-en

[DeleGate-En] Re: strange performance problem
06 Mar 2004 08:30:31 GMT Gong Su <p7qeqbdyi.ml@delegate.org>
Computer Science Department, Columbia University

Hi Yutaka, thank you very much for the patch! I just tried it and
yes it did improve the performance quite a bit! I now get around
250 transactions per second. Although it's still on the low side
comparing to a couple of other very simple TCP relay that I tried
(balance, portfw, both are also userspace applications), which got
around 400-500 transactions per second, as you said, delegate is
much more versatile and sophisticated as a general purpose proxy.
But I'm curious as to where the performance lost happens since I
suppose in the case of "tcprelay" you simply pass on the connection
without having to be "smart", right?

-- 
/Gong

On Saturday, March 6, 2004, 3:04:56 AM, you wrote:

> On 03/06/04(15:14) you Gong Su <gongsu@columbia..> wrote
> in <_A2556@delegate-en.ML_>
>  |Hi, I just downloaded 8.9.2 and am trying to do some performance testing.
>  |I have a setup:
>  |
>  |client - proxy - server
>  |
>  |which are all the same machines (1GHz Intel running Redhat 9 with
>  |2.4.20 kernel) and are connected with GigaE connections.
>  |
>  |I'm using a program called netperf (http://www.netperf.org/) which has
>  |a measurement that mimics http request/response and measures the number
>  |of such "transactions" per second. This is basically to measure the
>  |connection setup performance since each transaction uses a new connection.

> As an application level gateway, the purpose of DeleGate is to do some
> meaningful interpretation on application protocol.  So I've seldom
> cared about such performance of which cost and delay can be far smaller
> than that in protocol interpretation.  DeleGate does not cover the field
> which should be achieved far more simply and effectively in circuit level
> proxies or in lower protocol layers.

> But in this case of "tcprelay", I suppose the most part of the delay is
> from the cost of fork() of DeleGate for each connection, which should
> be suppressed.  It will be done as the enclosed patch.

> Cheers,
> Yutaka
> --
>   D G   Yutaka Sato <pfqcabdyi.ml@delegate.org> http://delegate.org/y.sato/
>  ( - )  National Institute of Advanced Industrial Science and Technology
> _<   >_ 1-1-4 Umezono, Tsukuba, Ibaraki, 305-8568 Japan
> Do the more with the less -- B. Fuller

> *** dist/delegate8.9.2/src/delegated.c	Thu Jan 15 19:37:09 2004
> --- src/delegated.c	Sat Mar  6 16:41:23 2004
> ***************
> *** 5058,5061 ****
> --- 5058,5062 ----
>   	proto = DFLT_PROTO;
>   	if( strcaseeq(iSERVER_PROTO,"socks") )  return 1;
> + 	if( strcaseeq(proto,"tcprelay") )  return 1;
>   	if( strcaseeq(proto,"vsap") )  return 1;
>   	if( strcaseeq(proto,"http") )	return 1;
> ***************
> *** 5083,5086 ****
> --- 5084,5088 ----
>   	 || streq(proto,"vsap")
>   	 || streq(proto,"socks")
> + 	 || streq(proto,"tcprelay")
>   	 || streq(proto,DGAUTHpro)
>   	 || BORN_SPECIALIST == 0 ){


  admin search upper oldest olders older1 this newer1 newers latest
[Top/Up] [oldest] - [Older+chunk] - [Newer+chunk] - [newest + Check]
@_@V