Can extra processing threads help in this case?
in [MFC]
|
From: Hector Santos on 25 Mar 2010 08:29 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
From: Joseph M. Newcomer on 25 Mar 2010 09:11 See below... On Wed, 24 Mar 2010 23:14:32 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >message news:snnlq5lfv1a59n003k5gkk8a6plb41ruj1(a)4ax.com... >> 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! > >Can you think of any other portable way that this can be >done? **** EnqueueRequest() which takes a description of the request. And is implemented on each platform with platform-specific code that is optimized for that platform. Your concept of "Portable" is incorrect here. you want the FASTEST way that the platform supports, and that may be completely different from every other platform. But if you code has a single abstraction, you are free to implement it in the best way on each platform! Of course, this is so screamingly obvious that it is also clear that you wouldn't want to listen to any idea that doesn't fit your preconceived notion. *** >I would estimate that MySQL would actually keep the FIFO >queue resident in RAM cache. **** Oh, it's the guesswork-and-wishful-thinking approach ALL OVER AGAIN! DUH! And what part of "don't guess, measure" did you fail to understand from the last week of messages? WHY do you believe MySQL will behave this way? Cite the appropriate chapter from the MySQL manual, or, since it is open-source, show the subroutine that guarantees this! But feel free to live in your fantasy world! When the Real World accidentally matches your fantasies, you will win. joe **** > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 25 Mar 2010 09:19 I decided it was easier just to say "you are a complete twit" because he obviously doesn't understand reality. But we KNOW that MySQL is going to keep this queue "resident" because, well, because it sounds cool. I guess. You and I both know what is going to happen, but he has this unwavering faith in "resident in memory", not understanding what is meant by "transacted database" or that when that transactional update is comitted that data will be FORCED out to the disk. But why should reality be allowed to deter hiim from his treasured design? Particularly when the wishful-thinking approach to performance is running full-on? We should all chip in and buy him a pack of Tarot cards so he can use them for design and stop bothering us. Or maybe an I Ching set for doing performance measurement (so he can refer to a "world renowned" technique for deriving his information). joe On Thu, 25 Mar 2010 07:22:21 -0400, Hector Santos <sant9442(a)nospam.gmail.com> wrote: >Peter Olcott 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! >> >> Can you think of any other portable way that this can be >> done? >> I would estimate that MySQL would actually keep the FIFO >> queue resident in RAM cache. > >Huh? > >Will MySQL will keep a FIFO queue resident? > >WOW! This is unbelievable. > >Do you know what MySQL is? Or even a FIFO queue? > >Honestly, do you really understand what MySQL or any SQL engine is? > >And you are worry about performing? > >Here is you functions for a FIFO: > >AddFifo() >{ > 1 - connect to SQL server > 2 - prepare sql statement > > sql = "insert into table values (that, this, that, ...)" > > 3 - execute sql > 4 - close >} > >GetFifo() >{ > 1 - connect to SQL server > > 2 - prepare sql statement, get last one > > sql = "select * from table limit 1, -1" > > 3 - execute sql > > 4 - Fetch the Record, if any > > 5 - get id for record > 6 - prepare DELETE sql statement > > sql = "delete from table where id = whatever" > > 7 - execute sql > > 8 - close >} > >You are crazy out of this world and nuts if you expect this to be an >efficient "FIFO" concept. Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 25 Mar 2010 09:26 See below... On Wed, 24 Mar 2010 23:15:49 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >message news:snnlq5lfv1a59n003k5gkk8a6plb41ruj1(a)4ax.com... >> 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! > >This was suggested on the comp.programming,threads group >Cross Platform FIFO Queue **** Which apparently is inhabited by equally clueless people. Or by people who clearly have no interest in performance! Or maybe they decided to give you a facile answer so you would stop bothering them....one which was just pulling your chain. Or they were testing the limits of your credulity. Reminds me of the Calvin & Hobbs cartoon: The family is in the card. Calvin: "Dad, how do they determine the weight limit of a bridge?" Dad: "They run bigger and bigger trucks over it until it collapses, then they rebuild it exactly and post the weight limit" Can you explain why you would accept, without question, such a patently absurd suggestion from one newsgroup while ignoring all the good advice you've been getting in this one? joe Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 25 Mar 2010 09:30
See below... On Wed, 24 Mar 2010 23:10:47 -0500, "Peter Olcott" <NoSpam(a)OCR4Screen.com> wrote: > >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in >message news:dlnlq5pok9nbsc35uaedbot0m18btno5ti(a)4ax.com... >>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 ? As I told you a few days ago, read my essay on the use of I/O Completion Ports on my MVP Tips site. Of course, if I told you that GetQueuedCompletionStatus is the dequeue operation, PostQueuedCompletionStatus the enqueue operation, it should be completely obvious how to do it. Or you could have gone to I/O Completion Ports in the MSDN documentation and read about the API calls and derived this information because it is so triviial to see it. here's an enqueue operation, and a dequeue operation. What more do you need to see? joe **** Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |