Re: About massive-persistent-connection and service priority

Priority is complicated. You will never have enough levels. I don't think
there is a generic way to do it right.

Concerning the thread pool. We have created a worker pool and written a
Server in Python. Clients connect to the server using PyRO, worker pool is
connected to the server via PyRO. This solves the problems with MAXTHREAD
and performance issues.


I like PyRO, because it is kept simple. This allows building death-solid
software on top of it. I would prefer it to stay this way. A new
dispatching mode makes it more complicated and introduces new bugs that are
hard to track down.

Thorsten.

Sent from my mobile phone

Am 28.12.2012 um 10:31 schrieb Guozhe <[email protected]>:

  Hi,

   Glad to see V4.17 released. I have two question:



The first is that both Mulitplex and Thread type of server have
disadvantages:



   Multiplex: cannot deal with circular-request. For example, Client->
A->B->C->A, unless use One-way-call, it would block. If we want get return
value, multiplex with one-way cannot resolve it.



   ThreadPool: for the limit of THREADPOOL_MAXTHREADS, if there are many
persistent-connection(persistent : one proxy connected to the server may
last long time before close), more than THREADPOOL_MAXTHREADS , the server
cannot response to new connected proxy(all thread is assigned already and
no proxy released yet). Yes you can make larger THREADPOOL_MAXTHREADS, but
if the number of thread more than 1000, it increases system overhead
greatly.



   Think about this scene: one proxy connected to the server and make a
remote call every 5 mins, the thread assigned to it will spend almost the
time in recv() [it block here if no request come] but cannot process other
proxy’s request. However, if we use Multiplex type, we will be blocked in
circular-request as mentioned before.



So, I have some suggestion about this problem—merge the Multiplex and
Thread type. That is: a Server works like Multiplex but not handle request
itself. It has a threadpool which contain many worker thread. When the
server select a client socket that ready to read, put the socket to the
threadpool to handle and delete it from current socket list. Every worker
thread do handleRequest() once(should modify the job class, when do job(),
it not entry a endless-loop but do once handleRequest) and wait to get
another job.



By doing this, it can deal with many proxy using 10 or more threads,
depending on the number of request arriving at the same time.



There is another issue: services may have priority(high, medium or low)
when they registered. A high-level service request may be processed before
a low-level request if they all in job-queue. We can use priority-queue.
But the problem is: if there are many high-level request and a little
medium or low-level request, the low level request may hang until all the
high-level request are processed. So how to assign a little time to the
lower-level request? My suggestion is make three type of worker thread,
control the number of each type.



Would you have better idea about these questions? Wait for your reply.

Best regards!





Zhe Guo

------------------------------------------------------------------------------
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812

_______________________________________________
Pyro-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyro-core

------------------------------------------------------------------------------
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122812

_______________________________________________
Pyro-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyro-core