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: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>