Hi Gustav,
first of all, thank you for the work you've done on websockets branch!
I'm really looking forward to see some websocket examples and blogs.
> Incoming dataframes concurrently trigger the websocketcontext
> listener onMessage method.
> The incoming rate vs the listener consumption rate is limited to a
> total number of bytes including datastructure overhead per socket,
> reads are throttled if a configured limit is passed (read interest
> is disabled, leaving throttling to TCP, and TCP is good at it.
> its one of the hardest things to get right when writing IO framework
> over UDP).
>
> Reads are performed in selector thread too, further reducing the
> context switches etc.
Are you using Grizzly selector threads or websocket infrastructure
reregisters websocket channels to own selector-threads?
> Selectorthread then finishes the writes, that is highly efficient
> due to there is no worker thread context switch per write,
> and the natural time lag at high load is causing writes to be more
> in bulk increasing overall efficiency further and there is
> significant less load on threadpool.
> Roundrobin load balancing among multiple selector threads is keeping
> the not directly writable IO work where it naturally belongs.
> The threadpool is not over used and can handle its remaining work
> better.
The same here. As I understand you use own websocket selector-threads
both for reads and writes?
> Multiple design decisions allow me to safely use my poison based
> fixed pool (recently patched in trunk to remove unnecessary atomic
> statistics) with and the now stable and highly improved LTQ.
> The 1.12 LTQ in grizzly that i prematurely pulled from doug cvs
> early this year is slow in comparison, just like sun perf team
> verified.
> It was still a win vs the CLQ for object caching. its another matter
> that both CLQ and LTQ now are vastly improved and whats optimal
> has changed.
I remember you mentioned some logic, which detects the current JDK
version and uses appropriate collection. Is it still the case?
> The threadpool is only one of several factors but it alone is
> interesting to compare.
> The performance and scalability is lowered by 2 to rather high 3
> digit percent numbers for when i use grizzly syncedpool for
> 3+ minute load tests each using 64 to 1024 sockets and DataFrame
> sizes from 2 to 16384 byte on a core i7.
IMO, it's not fair to compare those 2. SyncThreadPool is mostly used
for GF, because it supports min/max threads and more predictable in
its behavior. Otherwise nobody forces people to use SyncThreadPool.
> In grizzly 1.9 or 2.0 there is per design just too much _enforced_
> overhead in form of
> 1. too many context switches,
Can you pls. provide details, which switches we can avoid?
> 2. 1. are extra costly due the syncedpool design.
syncthreadpool is not design, it's implementation of a ThreadPool and
ExecutorService interface. Using the same interfaces (which are part
of design), you can build async implementation. So I'd say *design* is
not correct word here.
> the cost for load adapted pool size etc is _extreme_ when comparing
> to recently available alternatives like LTQ. but inorder to be able
> to take advantage of that , old ways to think must be abounded.
> That requires people that dont react with fear but instead become
> inspired...
LTQ is available since 1.6, Grizzly 1.9.x is JDK 1.5 compatible.
Personally I'm very inspired with the new LTQ, but in practice
customers will use JDK 1.5 for 5+ more years and will be happy.
> 3. overall design is indirectly leading to more channel read and
> writes then needed. very roughly 30K+ cycles overhead per call plus
> we risk to fragment tcp packets more then needed.
Can you pls. provide more details. Will appreciate your help in
improvment of those areas.
> When i want to talk about the possibility to allow services like
> websocket in grizzly 2.0 to not be enforced
> with low scaling high context switching design the answer is short,
> its not possible to make changes.
You make such a statement even without looking into 2.0, where for
each I/O operation you can chose whether you want to process it in the
same or worker thread.
Regarding changes... when you were told, that it's not possible to
make changes? If I remember correctly I was talking, that we're not
planning *big* *design* changes, but all reasonable improvment are
welcome.
> Well there is a general feeling of dead horse, no weekly project
> meetings anymore etc.
Agree, this should be changed. Having finished our work on GFv3, we
will have more time to work on Grizzly, so we will have info to share
on meetings.
> How are people supposed to work together in a team and still produce
> good stuff ?.
We still have mailing list, where trying to answer the question as
quickly as possible.
> I would gladly change my design or anything when i'm proved to be
> wrong or with sound technical reasoning convinced,
Ok.
> Me or anyone else ,cant as a single person try to drive the project
> and make it into something that would be competitive and only
> only "working".
I really appreciate the work you do!
Thanks.
WBR,
Alexey.
>
>
> --
> regards
> gustav trede
>
>