Can extra processing threads help in this case?
in [MFC]
|
From: Hector Santos on 25 Mar 2010 10:17 Peter Olcott wrote: > It continues to work (in practice) the way that I need it to > work, and I have never seen it work according to Joe's > theories. Whenever there is plenty of excess RAM (such as 4 > GB more than anything needs) there are no page-faults in my > process. I even stressed this out a lot and had four > processes taking 1.5 GB each (of my 8 GB) and still zero > page faults in any of the four processes. Geez, ok, fine, you got no faults. What we are telling you is that OK to get faults so that you can scale even more instances. But its a really a moot point now since you can't have more than one socket service[r] bound to the same port. You have no choice but to use a multi-threaded design. If you don't want to do threads, and you want to keep four OCR processors running, then at the very least, as I said very EARLY in the post, you need to sit down and get your OCR (interface) protocol worked out. Now your design could be: WEB SERVER <--> OCR.PROTOCOL.PROXY.DLL <--> X number of OCE.EXE The OCR Protocol proxy dll is now your FIFO based Load Balancer. Thats the best I see you can do with your peter-made design limitations and peter-based programming limitations. -- HLS
From: Peter Olcott on 25 Mar 2010 10:18 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:OOcyQDBzKHA.5288(a)TK2MSFTNGP05.phx.gbl... > Peter Olcott wrote: > >> "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in > >>> A multithreaded FIFO queue would make more sense; less >>> chance of priority inversion >>> effects. An I/O Completion Port makes a wonderful >>> multithreaded FIFO queue with >>> practically no effort! >>> joe >> >> How ? > > Well, there will be programming effort with IOCP, his main > point is that you don't understand enough programming > ideas under Windows that you behaving here like a new kid > who just discovered the toaster oven and you don't want > follow others cooks or read a cook book in the many ways > to use the toaster oven. > > Look, your SOCKET is a FIFO. Its inherent. So when > connects come in, they are queued, designed for > multi-threaded worker pool concepts to handle the incoming > request. > > So what you do? > > You don't use threads, and you slow it down by adding > ANOTHER FIFO queue to run the OCR per request one at a > time. > > But now you think, I got a MONSTER machine. Its easier for > me to use create a EXE with MONGOOSE+OCR and run it 4 > times, assuming it will be 1 EXE per multi-core processor. No you have this wrong. For proving that multiple threads would work multiple processes sufficed. In practice I will use multiple threads. > > Now you screwed up MONGOOSE, now you have 4 competition > SOCKET servers on PORT 80 and thats not possible on a > single machine. You can only have 1 PORT 80 HTTP > SERVICE - NOT FOUR!! > > So you automatically BLOCKED three of the EXE running in > memory, they will NEVER see a socket connection. > > But you say ok, "then I have no choice but to use FOUR > machines or even TWO for now." > > Now you need a LOAD BALANCER or just use simple round > robin logic in DNS records by adding two A records into > your ZONE for the same domain. > > myservice.com > 1.2.3.4 // machine 1 > 1.2.3.5 // machine 2 > > > Under DNS, it will round robin the IP to connect to. No > real concept for load balancing. > > The only load balancing concept you have is a FIFO at the > OCR part. > > So it all goes back to the Toaster Oven. You don't know > how to use the simply toaster oven and you don't want to > listen to anyone that what YOU are doing is freaking crazy > and you don't even realize that YOU can't do what you want > anyway with EXE per request when a socket is involved > without going into the need to add a LOAD BALANCING for > multiple machines. > > Really Peter, it skipped my mind that YOU can't run > multiple EXE when you have a socket service embedded into > it. But I said it in so many other ways, you are trying > to add a multi-threaded web server into 1 single thread > OCR process, when you should be adding a multi-thread OCR > process into a multi-thread service. > > It just dawned on me, that YOU can not do multiple > MONGOOSE+OCR EXE processors - mongoose is restricted to a > SINGLE PORT and you can't not have multiple services on > the same port on the same machine. > > -- > HLS I will have some sort of web server that communicates with my OCR process using some sort of inter process communication. The web server will have multiple threads (probably pthreads) and the OCR process will have one thread per CPU core, probably also pthreads. These threads will share a single block of memory, one way or another.
From: Peter Olcott on 25 Mar 2010 10:23 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:e5udsXBzKHA.2552(a)TK2MSFTNGP04.phx.gbl... > Joseph M. Newcomer wrote: > >> See below... >> >> On Tue, 23 Mar 2010 14:11:28 -0500, "Peter Olcott" >> <NoSpam(a)OCR4Screen.com> wrote: >> >>> Ah so this is the code that you were suggesting? >>> I won't be able to implement multi-threading until >>> volume grows out of what a single core processor can >>> accomplish. >>> I was simply going to use MySQL for the inter-process >>> communication, building and maintaining my FIFO queue. >> **** >> Well, I can think of worse ways. For example, writing >> the data to a floppy disk. Or >> punching it to paper tape and asking the user to >> re-insert the paper tape. MySQL for >> interprocess communication? Get serious! > > Crazy huh? :) And all this talk about performance, > worrying about chip caches, and throws in this elephant? > > Even though, given his limitations by his own design, he > picked the wrong software - he wants SQLITE3! It fits in > perfectly with a single ACCESSOR queuing concept. :) > > -- > HLS You got any other idea for a 100% portable FIFO queue that has maximum fault tolerance? (By fault tolerance I mean yank the power plug from the wall and when the machine is re-started it (as much as possible) picks up right where it left off)
From: Hector Santos on 25 Mar 2010 10:24 Peter Olcott wrote: >> Will MySQL will keep a FIFO queue resident? >> >> WOW! This is unbelievable. >> >> Do you know what MySQL is? Or even a FIFO queue? > > Do you know what file caching is? Do you want to compete with me? > I know that a SQL provider > would not be required to always hit disk for a 100K table > when multiple GB of RAM are available. Under idle times there is a penalty for MYSQL to re-awake. Your connects will be slow to start at first. For 100K file? Just use an plan old text file for that or KILL it in memory for god sake. If you want SQL, MySQL is an overkill for your peter-made design limitations and primitive application. You will be better off with a single accessor SQLITE3 which by its very design is meant for SINGLE access only - probably fit your crazy FIFO ideas which I see you totally IGNORE the example pseudo code that you Have no choice to do. -- HLS
From: Peter Olcott on 25 Mar 2010 10:28
"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:O4QeObBzKHA.5868(a)TK2MSFTNGP06.phx.gbl... > Peter Olcott wrote: > >>>> >>> **** >>> If you use multiple threads in a single process, or >>> multiple processes with a shared >>> memory segment implemented by a Memory Mapped File, you >>> will reduce the footprint since >>> either all threads (in one process) share the same >>> memory footprint, or the multiple >>> processes share largely the same memory footprint. >> >> Yup. so if its fast enough with multiple processes it >> will sure be fast enough as multiple threads, wouldn't it >> be? > > > Its a moot point now. You can't run multiple socket > servers on the same port 80 Peter. Oh, they will start > up, but you won't get any secondary processors trying to > bind on port 80 to listen on it. That is still among one > of #1 support questions when a new customer purchases our > service products, installs it and runs it and he test it > with his browser and it doesn't connect - he has IIS > running in the background. So either he turns it off or > he uses a different port. > > You have no choice but to follow the proper multi-thread > design server models. :) > > -- > HLS That should not be any issue because data processing time will always be a large multiple of HTTP processing time. Web server listens at port 80, and creates a separate thread (possibly from a thread pool) to handle each HTTP request. It places each request in some sort of FIFO queue. OCR process has one or more threads that pull requests from this FIFO queue. |