Can extra processing threads help in this case?
in [MFC]
|
From: Hector Santos on 11 Apr 2010 08:50 Peter Olcott wrote: > Since I only need to be able to process 100 transactions per > second the speed of these overhead sort of things should not > be too critical. I am guessing that the sum total of these > overhead sort of things will only take about 10 ms per > transaction most of this being drive head seek time. No, 10 ms is a ONLY CONVENIENT # that can be calculated for 100 transactions per second. It was not based on any real results you did. You want 100 tps, the work load must be 10ms. You want 1000 TPS, the work load is 100 ms - period: TPS = 1000/ WORK LOAD Period, period, period. There is no way on earth you can: receive a HTTP request parse it authorize it via a database set some status points delete it to some queue wait for a respons <----> OCR process wait up set status points do image processing set status points send response send HTTP response all in 10 ms - you are SICK if you think you can do this in 10 ms. And thats just for 1 single request. Throw in 99 more per second, and you are are completely whacked to now realize the build up our your queuing where each subsequent request will be delayed by a factor of of magical 10 ms number. Until you realize this, nothing else you saw matters. -- HLS
From: Peter Olcott on 11 Apr 2010 09:15 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:%23psrlWX2KHA.5660(a)TK2MSFTNGP04.phx.gbl... > Peter Olcott wrote: > >> Since I only need to be able to process 100 transactions >> per second the speed of these overhead sort of things >> should not be too critical. I am guessing that the sum >> total of these overhead sort of things will only take >> about 10 ms per transaction most of this being drive head >> seek time. > > > No, 10 ms is a ONLY CONVENIENT # that can be calculated > for 100 transactions per second. It was not based on any > real results you did. You want 100 tps, the work load > must be 10ms. You want 1000 TPS, the work load is 100 > ms - period: > > TPS = 1000/ WORK LOAD > > Period, period, period. > > There is no way on earth you can: > > receive a HTTP request > parse it > authorize it via a database > set some status points > delete it to some queue > wait for a respons <----> OCR process > wait up > set status points > do image processing > set status points > send response > > send HTTP response > > all in 10 ms - you are SICK if you think you can do this > in 10 ms. And thats just for 1 single request. Throw in > 99 more per second, and you are are completely whacked to > now realize the build up our your queuing where each > subsequent request will be delayed by a factor of of > magical 10 ms number. > > Until you realize this, nothing else you saw matters. > > -- > HLS It looks like you are wrong http://www.kegel.com/c10k.html#top
From: Hector Santos on 11 Apr 2010 10:15 Peter Olcott wrote: > "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message > news:%23psrlWX2KHA.5660(a)TK2MSFTNGP04.phx.gbl... >> Peter Olcott wrote: >> >>> Since I only need to be able to process 100 transactions >>> per second the speed of these overhead sort of things >>> should not be too critical. I am guessing that the sum >>> total of these overhead sort of things will only take >>> about 10 ms per transaction most of this being drive head >>> seek time. >> >> No, 10 ms is a ONLY CONVENIENT # that can be calculated >> for 100 transactions per second. It was not based on any >> real results you did. You want 100 tps, the work load >> must be 10ms. You want 1000 TPS, the work load is 100 >> ms - period: >> >> TPS = 1000/ WORK LOAD >> >> Period, period, period. >> >> There is no way on earth you can: >> >> receive a HTTP request >> parse it >> authorize it via a database >> set some status points >> delete it to some queue >> wait for a respons <----> OCR process >> wait up >> set status points >> do image processing >> set status points >> send response >> >> send HTTP response >> >> all in 10 ms - you are SICK if you think you can do this >> in 10 ms. And thats just for 1 single request. Throw in >> 99 more per second, and you are are completely whacked to >> now realize the build up our your queuing where each >> subsequent request will be delayed by a factor of of >> magical 10 ms number. >> >> Until you realize this, nothing else you saw matters. >> >> -- >> HLS > > It looks like you are wrong > http://www.kegel.com/c10k.html#top You can't read and that DOCUMENT is a blab of illusions. Tell me how *YOUR PRODJECT* can SQUEEZE more time that is not available to you? 100 TPS === 1000/10ms If you go 1 ms above, you are HOSED. Lets imagine that your great Linux will do every step in its 1 ms clock tick and it is the only process in the OS. In fact, there is no other OS process kernel logic or other anything else to interrupt you. 1ms receive a HTTP request 1ms log http header 1ms save posted data on disk 1ms read HTTP and authenticate via a database 1ms set some status point 1ms delegate it to some queue 1ms wait for a respons <----> OCR process wake up 1ms set status points 1ms read posted file 1ms do image processing 1ms set status points 1ms send response 1ms send HTTP response Thats 13 ms CLOCK TICKS on Linux and I'm sure we missed some. I'm sure the image processing itself is not going to be 1 ms. Add up your OP CODES BUDDY! Where in that document does it say you can do EVERYTHING you need in 10 ms? Come on! You are SICK to think you can do all this at 10ms. Throw in kernel code, other OS processes, hardware interrupts and lose even more precious work time. And you are ASSUMING a serialized transaction, meaning, you have 100 TPS, each coming every 10 ms and you have ZERO pressure. You are not engineering for the high possibility of concurrency or a distribution of your load, 30 comes in in the first 10 seconds. None for the next 30, and the next 70 in the final 20 seconds! You are DREAMING - and LEARN HOW TO READ! If you thought Ed's 1000 connect/second is your answer, well, where is the WORK LOAD? All he indicated he can get 1000 CPS. He was probably not doing any sort of work at all but how much a listening server can accept connections with a immediate drop. Add some REAL WORK and LEARN! You are in complete DENIAL and DREAMING of the fact YOU won't be able to do this WORK in 10 ms. No way in HELL you can do this in 10 ms and you said it yourself that is your calculated BEST speed. Your WORST was 100 ms. That means right there, you need 10 handlers: 1 handler can process 10 transactions per second. Multiply by 10 handlers gives you your 100 TPS. You can't squeeze PHANTOM TIME out of the computer! -- HLS
From: Peter Olcott on 11 Apr 2010 10:38 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:eHBz1FY2KHA.4332(a)TK2MSFTNGP02.phx.gbl... > Peter Olcott wrote: > >> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >> message news:%23psrlWX2KHA.5660(a)TK2MSFTNGP04.phx.gbl... >>> Peter Olcott wrote: >>> >>>> Since I only need to be able to process 100 >>>> transactions per second the speed of these overhead >>>> sort of things should not be too critical. I am >>>> guessing that the sum total of these overhead sort of >>>> things will only take about 10 ms per transaction most >>>> of this being drive head seek time. >>> >>> No, 10 ms is a ONLY CONVENIENT # that can be calculated >>> for 100 transactions per second. It was not based on >>> any real results you did. You want 100 tps, the work >>> load must be 10ms. You want 1000 TPS, the work load is >>> 100 ms - period: >>> >>> TPS = 1000/ WORK LOAD >>> >>> Period, period, period. >>> >>> There is no way on earth you can: >>> >>> receive a HTTP request >>> parse it >>> authorize it via a database >>> set some status points >>> delete it to some queue >>> wait for a respons <----> OCR process >>> wait up >>> set status points >>> do image processing >>> set status points >>> send response >>> >>> send HTTP response >>> >>> all in 10 ms - you are SICK if you think you can do this >>> in 10 ms. And thats just for 1 single request. Throw in >>> 99 more per second, and you are are completely whacked >>> to now realize the build up our your queuing where each >>> subsequent request will be delayed by a factor of of >>> magical 10 ms number. >>> >>> Until you realize this, nothing else you saw matters. >>> >>> -- >>> HLS >> >> It looks like you are wrong >> http://www.kegel.com/c10k.html#top > > > You can't read and that DOCUMENT is a blab of illusions. > Tell me how *YOUR PRODJECT* can SQUEEZE more time that is > not available to you? > > 100 TPS === 1000/10ms > > If you go 1 ms above, you are HOSED. Yet another respondent that fails to pay attention. (1) The total processing time for the OCR is estimated at 10 ms. >>>> I am guessing that the sum total of these overhead >>>> sort of things will only take about 10 ms per >>>> transaction See the word [overhead]? You missed that (2) The total processing time for the overhead associated with this OCR processing is estimated at no more than an additional 10 ms. This provides at least 50 transactions per second and possibly the whole 100 will remain because of hyperthreading allowing aspects of a single transaction to be performance concurrently. > > Lets imagine that your great Linux will do every step in > its 1 ms clock tick and it is the only process in the OS. > In fact, there is no other OS process kernel logic or > other anything else to interrupt you. > > 1ms receive a HTTP request > 1ms log http header > 1ms save posted data on disk > 1ms read HTTP and authenticate via a database > 1ms set some status point > 1ms delegate it to some queue > 1ms wait for a respons <----> OCR process wake up > 1ms set status points > 1ms read posted file > 1ms do image processing > 1ms set status points > 1ms send response > 1ms send HTTP response > > Thats 13 ms CLOCK TICKS on Linux and I'm sure we missed > some. I'm sure the image processing itself is not going > to be 1 ms. Add up your OP CODES BUDDY! > > Where in that document does it say you can do EVERYTHING > you need in 10 ms? > > Come on! You are SICK to think you can do all this at > 10ms. > > Throw in kernel code, other OS processes, hardware > interrupts and lose even more precious work time. > > And you are ASSUMING a serialized transaction, meaning, > you have 100 TPS, each coming every 10 ms and you have > ZERO pressure. You are not engineering for the high > possibility of concurrency or a distribution of your load, > 30 comes in in the first 10 seconds. None for the next 30, > and the next 70 in the final 20 seconds! > > You are DREAMING - and LEARN HOW TO READ! > > If you thought Ed's 1000 connect/second is your answer, > well, where is the WORK LOAD? All he indicated he can get > 1000 CPS. He was probably not doing any sort of work at > all but how much a listening server can accept connections > with a immediate drop. > > Add some REAL WORK and LEARN! > > You are in complete DENIAL and DREAMING of the fact YOU > won't be able to do this WORK in 10 ms. No way in HELL > you can do this in 10 ms and you said it yourself that is > your calculated BEST speed. Your WORST was 100 ms. That > means right there, you need 10 handlers: > > 1 handler can process 10 transactions per second. > > Multiply by 10 handlers gives you your 100 TPS. > > You can't squeeze PHANTOM TIME out of the computer! > > -- > HLS
From: Peter Olcott on 11 Apr 2010 10:47
"Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:eHBz1FY2KHA.4332(a)TK2MSFTNGP02.phx.gbl... > Peter Olcott wrote: > >> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in >> message news:%23psrlWX2KHA.5660(a)TK2MSFTNGP04.phx.gbl... >>> Peter Olcott wrote: >>> >>>> Since I only need to be able to process 100 >>>> transactions per second the speed of these overhead >>>> sort of things should not be too critical. I am >>>> guessing that the sum total of these overhead sort of >>>> things will only take about 10 ms per transaction most >>>> of this being drive head seek time. >>> >>> No, 10 ms is a ONLY CONVENIENT # that can be calculated >>> for 100 transactions per second. It was not based on >>> any real results you did. You want 100 tps, the work >>> load must be 10ms. You want 1000 TPS, the work load is >>> 100 ms - period: >>> >>> TPS = 1000/ WORK LOAD >>> >>> Period, period, period. >>> >>> There is no way on earth you can: >>> >>> receive a HTTP request >>> parse it >>> authorize it via a database >>> set some status points >>> delete it to some queue >>> wait for a respons <----> OCR process >>> wait up >>> set status points >>> do image processing >>> set status points >>> send response >>> >>> send HTTP response >>> >>> all in 10 ms - you are SICK if you think you can do this >>> in 10 ms. And thats just for 1 single request. Throw in >>> 99 more per second, and you are are completely whacked >>> to now realize the build up our your queuing where each >>> subsequent request will be delayed by a factor of of >>> magical 10 ms number. >>> >>> Until you realize this, nothing else you saw matters. >>> >>> -- >>> HLS >> >> It looks like you are wrong >> http://www.kegel.com/c10k.html#top > > > You can't read and that DOCUMENT is a blab of illusions. > Tell me how *YOUR PRODJECT* can SQUEEZE more time that is > not available to you? > > 100 TPS === 1000/10ms > > If you go 1 ms above, you are HOSED. > > Lets imagine that your great Linux will do every step in > its 1 ms clock tick and it is the only process in the OS. > In fact, there is no other OS process kernel logic or > other anything else to interrupt you. > > 1ms receive a HTTP request > 1ms log http header > 1ms save posted data on disk > 1ms read HTTP and authenticate via a database > 1ms set some status point > 1ms delegate it to some queue > 1ms wait for a respons <----> OCR process wake up > 1ms set status points > 1ms read posted file > 1ms do image processing > 1ms set status points > 1ms send response > 1ms send HTTP response I you wouldn't be so rude with me I would tone down my criticism of you, but, the above sequence does show a enormous degree of ignorance. > > Thats 13 ms CLOCK TICKS on Linux and I'm sure we missed > some. I'm sure the image processing itself is not going > to be 1 ms. Add up your OP CODES BUDDY! > > Where in that document does it say you can do EVERYTHING > you need in 10 ms? > > Come on! You are SICK to think you can do all this at > 10ms. > > Throw in kernel code, other OS processes, hardware > interrupts and lose even more precious work time. > > And you are ASSUMING a serialized transaction, meaning, > you have 100 TPS, each coming every 10 ms and you have > ZERO pressure. You are not engineering for the high > possibility of concurrency or a distribution of your load, > 30 comes in in the first 10 seconds. None for the next 30, > and the next 70 in the final 20 seconds! > > You are DREAMING - and LEARN HOW TO READ! > > If you thought Ed's 1000 connect/second is your answer, > well, where is the WORK LOAD? All he indicated he can get > 1000 CPS. He was probably not doing any sort of work at > all but how much a listening server can accept connections > with a immediate drop. > > Add some REAL WORK and LEARN! > > You are in complete DENIAL and DREAMING of the fact YOU > won't be able to do this WORK in 10 ms. No way in HELL > you can do this in 10 ms and you said it yourself that is > your calculated BEST speed. Your WORST was 100 ms. That > means right there, you need 10 handlers: > > 1 handler can process 10 transactions per second. > > Multiply by 10 handlers gives you your 100 TPS. > > You can't squeeze PHANTOM TIME out of the computer! > > -- > HLS |