doris-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [incubator-doris] infearOnTheWay opened a new issue #2602: Add nio support for mysql protocal implementation
Date Fri, 27 Dec 2019 09:41:27 GMT
infearOnTheWay opened a new issue #2602: Add nio support for mysql protocal implementation
URL: https://github.com/apache/incubator-doris/issues/2602
 
 
   ### Description
   The motivation to add this feature originated from our own project. In order to make our
service compatible with mysql protocal, we use related implementation in doris, which does
help a lot!
   
   At the same time, we found that,each connection in doris would be assign a thread just
for this connection, even if the connection is always idle. This make a centain amount of
resource waste, while the max count of connections would be also limited since of thread stack
size. We understand that the concurrency would expected to be not very high in doris currently,
so such implmentation is simple and enough. 
   
   On the other hand, we expect to support large amounts of connections in our condition.
So we optimize the IO architechture in our project and would be appreciate to feedback this
feature to doris, which would be a useful complementation in future.  
   
   ### Solution
   We add another mysql server implementation based on XNIO framework. The details about XNIO
could be get here [https://xnio.jboss.org/]. In shortly, XNIO
   can be treated as a very small but powerful io framework based on java nio. Underdow(a
kind of container like tomcat or jetty) is also based on XNIO.
   
   In our implmentation, there exist two thread group:**io-thread** and **task-thread** .The
io-thread focus on accepting all io-events.Since such handle is always fast, so the io-thread
count can be a little small(equal to cpu core count is appreciate). 
   
   On the other hand, we can add correspond callback to handle such events. For example, "accept
listener" would be callback while connection reaches and "read listener" would be callback
while any query on connection reaches. Such callback would be handled in task-thread asynchronously,
since it is always cost a lot of time. 
   
   All the connections would share these two thread groups, while there would be almost no
blocking in the connecting and query phrase. 
   
   ### Addtitional
   In our load test, max connection count could reach 100w+, while there still exist buffer
on resources like cpu and memory. But we also found doris would pre-allocate a 2M byte buffer
while every connection is established. Since this would occupy massive memory, we just changed
the buffer size to 2K for test. We also do optimization on how to dynamicly allocate such
part of buffer now.
     
   In fact, we do not refactor the core progress of connection and query logic in doris, and
just do encapsulation above it. It should be noted that any threadlocal object(such as **ConnectContext**)
should be deal with carefully since thread is not owned by each connection. Meanwhile, the
**ConnectScheduler** is still used for connection management such as registration and idle
check for new connect context. 
   
   ps.This feature would enabled if the 'nio-enabled' config is set true. 
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@doris.apache.org
For additional commands, e-mail: commits-help@doris.apache.org


Mime
View raw message