Re: Can extra processing threads help in this case?
"Hector Santos" <sant9442@nospam.gmail.com> wrote in message
news:epsZzaryKHA.5360@TK2MSFTNGP06.phx.gbl...
Peter Olcott wrote:
I still think that the FIFO queue is a good idea. Now I
will have multiple requests and on multi-core machines
multiple servers.
IMO, it just that its an odd approach to load balancing.
You are integrating software components, like a web server
with an multi-thread ready listening server and you are
hampering it with a single thread only FIFO queuing. It
introduces other design considerations. Namely, you will
need to consider a store and forward concept for your
request and delayed responses. But if your request
processing is very fast, maybe you don't need to worry
about it.
I will probably be implementing the FIFO queue using MySQL.
I want customers to have a strict first in first out,
priority the only thing that will change this is that
multiple servers are now feasible. If it costs me an extra
1/2 % of amortized response rate, then this is OK.
Because multiple servers are now available, I will drop the
idea of more than one queue priority. I know that database
access is slow, but this will be amortized over much longer
processing time. This solution should be simple and
portable. Also the database probably has a lot of caching
going on so it probably won't even cost me the typical disk
access time of 5 ms.
In practice the "FIFO" would be at the socket level or
listening level with concepts dealing with load balancing
by restricting and balancing your connection with worker
pools or simply letting it to wait knowing that processing
won't be too long. Some servers have guidelines for
waiting limits. For the WEB, I am not recall coming
across any specific guideline other than a practical one
per implementation. The point is you don't want the
customers waiting too long - but what is "too long."
This sounds like a more efficient approach, but, it may lack
portability, and it may take longer to get operational. I
will already have some sort of SQL learning curve to
implement my authentication database. This sounds like an
extra leaning curve over and above everything else. There
are only so many 1000 page books that I can read in a finite
amount of time.
What is your best suggestion for how I can implement the
FIFO queue?
(1) I want it to be very fast
(2) I want it to be portable across Unix / Linux /
Windows, and maybe even Mac OS X
(3) I want it to be as robust and fault tolerant as
possible.
Any good collection class will do as long as you wrap it
with synchronization. Example:
typedef struct _tagTSlaveData {
... data per request.........
} TSlaveData;
class CBucket : public std::list<TSlaveData>
{
public:
CBucket() { InitializeCriticalSection(&cs); }
~CBucket() { DeleteCriticalSection(&cs); }
void Add( const TSlaveData &o )
{
EnterCriticalSection(&cs);
insert(end(), o );
LeaveCriticalSection(&cs);
}
BOOL Fetch(TSlaveData &o)
{
EnterCriticalSection(&cs);
BOOL res = !empty();
if (res) {
o = front();
pop_front();
}
LeaveCriticalSection(&cs);
return res;
}
private:
CRITICAL_SECTION cs;
} Bucket;
--
HLS