Proxy implementation

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Proxy implementation

Karsten Ohme
Hi,

The main problem of implementation was the usage of Context. I thought
Context can be used to store global attributes, but this seem not to be
true, everything is setup again for each SelectionKey event. I have
attached teh implementation. It get sometimes a
ClosedConnectionException, don't know who closed it, but the most time
it works.
The performance of my implementation is quite poor.
Using Callbacks and TCPConnector seems to be cumbersome and not working.
I don't believe this can boost the performance.
Can have used a blocking connect method and write the dat in blocking
mode. Can this cause problems? As far as I see the Pipiline is executed
eahc time a SelectionKey event happens but by defualt 20 threads are
only executed. Can this be a limit? Can the performance be improved?

I have also attached test results from JMeter compared to a blocking
solution and a direct conenction to a Tomcat server.

Ragards,
Karsten

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

MyPerformantProxy(grizzly).zip (7K) Download Attachment
grizzlyPerformance.png (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proxy implementation

Oleksiy Stashok
Hmm, I see you refused to use Grizzly client side interfaces. For simple
case maybe it makes sense, but it's possible to easy enable caching if
you use it.
In your implementation one thing is not clear to me. It's your Map. May
be I missed something, but seems it's just one-direction map. In other
words what will be if request will come to proxy in several parts? How
it will be processed?

And from chart you sent, not sure I understand the description of each
bar. Where is "grizzly code" bar there? :)

WBR,
Alexey.

Karsten Ohme wrote:

> Hi,
>
> The main problem of implementation was the usage of Context. I thought
> Context can be used to store global attributes, but this seem not to be
> true, everything is setup again for each SelectionKey event. I have
> attached teh implementation. It get sometimes a
> ClosedConnectionException, don't know who closed it, but the most time
> it works.
> The performance of my implementation is quite poor.
> Using Callbacks and TCPConnector seems to be cumbersome and not working.
> I don't believe this can boost the performance.
> Can have used a blocking connect method and write the dat in blocking
> mode. Can this cause problems? As far as I see the Pipiline is executed
> eahc time a SelectionKey event happens but by defualt 20 threads are
> only executed. Can this be a limit? Can the performance be improved?
>
> I have also attached test results from JMeter compared to a blocking
> solution and a direct conenction to a Tomcat server.
>
> Ragards,
> Karsten
>  
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proxy implementation

Karsten Ohme
On Tue, Jun 05, 2007 at 03:05:50PM +0200, Oleksiy Stashok wrote:
> Hmm, I see you refused to use Grizzly client side interfaces. For simple
> case maybe it makes sense, but it's possible to easy enable caching if
> you use it.

What interfaces you mean? TCPConnector... Well, the conenct method is
not blocking, I have to use a callback and I have to remember the whole
time to byteBuffer I want to write and must care if in the meanwhile new
read request are coming in and keep the correct order. This sounds
painful. I have tried your tunnel implementation but it lasts more or
the same time than mine.

> In your implementation one thing is not clear to me. It's your Map. May
> be I missed something, but seems it's just one-direction map. In other
> words what will be if request will come to proxy in several parts? How
> it will be processed?

No, the map contains the SocketConnections from the client to the proxy
as key and proxy to server as value and also the other direction.

>
> And from chart you sent, not sure I understand the description of each
> bar. Where is "grizzly code" bar there? :)

The largest one, everything which is non blocking. non blocking large
file and non blocking small page.

Best Regards,
Karsten

>
> WBR,
> Alexey.
>
> Karsten Ohme wrote:
> >Hi,
> >
> >The main problem of implementation was the usage of Context. I thought
> >Context can be used to store global attributes, but this seem not to be
> >true, everything is setup again for each SelectionKey event. I have
> >attached teh implementation. It get sometimes a
> >ClosedConnectionException, don't know who closed it, but the most time
> >it works.
> >The performance of my implementation is quite poor.
> >Using Callbacks and TCPConnector seems to be cumbersome and not working.
> >I don't believe this can boost the performance.
> >Can have used a blocking connect method and write the dat in blocking
> >mode. Can this cause problems? As far as I see the Pipiline is executed
> >eahc time a SelectionKey event happens but by defualt 20 threads are
> >only executed. Can this be a limit? Can the performance be improved?
> >
> >I have also attached test results from JMeter compared to a blocking
> >solution and a direct conenction to a Tomcat server.
> >
> >Ragards,
> >Karsten
> >  
> >
> >------------------------------------------------------------------------
> >
> >------------------------------------------------------------------------
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [hidden email]
> >For additional commands, e-mail: [hidden email]
> >  
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proxy implementation

Oleksiy Stashok

>> In your implementation one thing is not clear to me. It's your Map. May
>> be I missed something, but seems it's just one-direction map. In other
>> words what will be if request will come to proxy in several parts? How
>> it will be processed?
>>    
>
> No, the map contains the SocketConnections from the client to the proxy
> as key and proxy to server as value and also the other direction.
>  
Right, didn't notice that :)

>>> Can have used a blocking connect method and write the dat in blocking
>>> mode. Can this cause problems? As far as I see the Pipiline is executed
>>> eahc time a SelectionKey event happens but by defualt 20 threads are
>>> only executed. Can this be a limit? Can the performance be improved?
>>>      
It depends from specific configuration, but think 20 threads should be
ok. Think the main reason of bad results - is that in our
implementations we reregister keys all the time on main selector.
Think using ByteBufferInputStream for reading will get implementation
speed much better.

WBR,
Alexey.

>>> I have also attached test results from JMeter compared to a blocking
>>> solution and a direct conenction to a Tomcat server.
>>>
>>> Ragards,
>>> Karsten
>>>  
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>  
>>>      
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Proxy implementation

Oleksiy Stashok
Karsten, please try this version.
I tried to avoid frequent registering of OP_READ on main selector.

WBR,
Alexey.

Oleksiy Stashok wrote:

>
>>> In your implementation one thing is not clear to me. It's your Map.
>>> May be I missed something, but seems it's just one-direction map. In
>>> other words what will be if request will come to proxy in several
>>> parts? How it will be processed?
>>>    
>>
>> No, the map contains the SocketConnections from the client to the
>> proxy as key and proxy to server as value and also the other direction.
>>  
> Right, didn't notice that :)
>
>>>> Can have used a blocking connect method and write the dat in
>>>> blocking mode. Can this cause problems? As far as I see the
>>>> Pipiline is executed eahc time a SelectionKey event happens but by
>>>> defualt 20 threads are only executed. Can this be a limit? Can the
>>>> performance be improved?
>>>>      
> It depends from specific configuration, but think 20 threads should be
> ok. Think the main reason of bad results - is that in our
> implementations we reregister keys all the time on main selector.
> Think using ByteBufferInputStream for reading will get implementation
> speed much better.
>
> WBR,
> Alexey.
>
>>>> I have also attached test results from JMeter compared to a
>>>> blocking solution and a direct conenction to a Tomcat server.
>>>>
>>>> Ragards,
>>>> Karsten
>>>>  
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>  
>>>>      
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>    
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>  
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

GrizzlyTunnel.zip (29K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proxy implementation

Karsten Ohme
On Tue, Jun 05, 2007 at 05:52:31PM +0200, Oleksiy Stashok wrote:
> Karsten, please try this version.
> I tried to avoid frequent registering of OP_READ on main selector.

No, something strange must be happening. JMeter is finishing fast the first threads but at the end the average time raises above 6 seconds.

Test conditions:

I use a Tomcat server, another server web server should also suffice, Tomcat is fast enough, see the picture I attached in a previous mail. I use a big file, e.g.
a
picture and a small web page. The proxy runs on 8081, the Tomcat on 8080. I also have a dirty blockign implementation whcih runs on port 8082. Everything on the
localhost. The blocking implementation is attached (SocketTunnel.zip).My test scenario is attached (TestAjax.war). There is a war can
can deploy or the complete Eclipse WTP project. The war might be easier to deploy.

I also attach the Test scenario for JMeter (TestPlan 2.jmx).

Best Regards,
Karsten


>
> WBR,
> Alexey.
>
> Oleksiy Stashok wrote:
> >
> >>>In your implementation one thing is not clear to me. It's your Map.
> >>>May be I missed something, but seems it's just one-direction map. In
> >>>other words what will be if request will come to proxy in several
> >>>parts? How it will be processed?
> >>>    
> >>
> >>No, the map contains the SocketConnections from the client to the
> >>proxy as key and proxy to server as value and also the other direction.
> >>  
> >Right, didn't notice that :)
> >
> >>>>Can have used a blocking connect method and write the dat in
> >>>>blocking mode. Can this cause problems? As far as I see the
> >>>>Pipiline is executed eahc time a SelectionKey event happens but by
> >>>>defualt 20 threads are only executed. Can this be a limit? Can the
> >>>>performance be improved?
> >>>>      
> >It depends from specific configuration, but think 20 threads should be
> >ok. Think the main reason of bad results - is that in our
> >implementations we reregister keys all the time on main selector.
> >Think using ByteBufferInputStream for reading will get implementation
> >speed much better.
> >
> >WBR,
> >Alexey.
> >
> >>>>I have also attached test results from JMeter compared to a
> >>>>blocking solution and a direct conenction to a Tomcat server.
> >>>>
> >>>>Ragards,
> >>>>Karsten
> >>>>
> >>>>
> >>>>------------------------------------------------------------------------
> >>>>
> >>>>
> >>>>------------------------------------------------------------------------
> >>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: [hidden email]
> >>>>For additional commands, e-mail: [hidden email]
> >>>>
> >>>>      
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: [hidden email]
> >>>For additional commands, e-mail: [hidden email]
> >>>
> >>>    
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [hidden email]
> >>For additional commands, e-mail: [hidden email]
> >>
> >>  
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: [hidden email]
> >For additional commands, e-mail: [hidden email]
> >

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

SocketTunnel.zip (4K) Download Attachment
Test Plan2.jmx (20K) Download Attachment
TestAjax.war (3M) Download Attachment
TestAjax.zip (2M) Download Attachment