[Ilugc] Hi

  • From: meendar@xxxxxxxxx (meendar)
  • Date: Mon Aug 11 18:22:56 2008


I used unix sockets since there is no single point server in the 
architecture. So all the client must know complete information about 
the nodes in the cluster. And more over there is not much sync between 
the nodes in the cluster. The communication is always between the 
client (which requests for the data) and not among the data instances.
No problem with using unix sockets, since we don't have any other way. 
But the wait for socket connection can done with select/poll, this can 
cost on performance. so i suggested for libevent. It is event 
notifiction system. This Api will watch for the events occured and 
notify you, this supports epoll, kqueue in unix systems which is almost 
faster than normal select/poll.

However if your systems don't create much socket descriptors , you can 
go for select/poll. I didn't walkthrough all of your code, may be you 
don't sync often.  I guess distributed systems might use of large number 
of sockets for synchronizing itself with the master/slave, or send send 
to the client. So i suggested this one.


Since the data is sharded we can not have joins on the data and if we 
require join support we will have to sync with other nodes in the 
cluster and then i think the event/poll will be of great use.

At present i classify the requests into node-level and cluster-level. 
In node-level queries only one data instance is pinged and requested 
for data and in the cluster-level queries all the nodes are pinged and 
the aggregation of results is done at the client end.

Let me know if my reason is correct.
However if your systems don't create much socket descriptors , you can 
go for select/poll. I didn't walkthrough all of your code, may be you 
don't sync often.  I guess distributed systems might use of large number 
of sockets for synchronizing itself with the master/slave, or send send 
to the client. So i suggested this one.


Other related posts: