How may cores do you have? Are all the cores being used when you run the tests? What webserver are you testing against?
Keep in mind that one core can only process one instruction (machine code, not python instruction) at a time. Ricardo On Tue, Nov 26, 2013 at 2:32 PM, Saurabh Kumar <[email protected]>wrote: > > On Tue, Nov 26, 2013 at 7:27 PM, Anthony <[email protected]> wrote: > >> *Case 1:* >>> Number of Tables in db.py: ~100 (all with migrate=False) >>> No. of concurrent requests: 1 >>> Time taken per request: 900 ms >>> >>> *Case 2:* >>> Number of Tables in db.py: ~100 (all with migrate=False) >>> No. of concurrent requests: 25 >>> Time taken per request: 4440 ms >>> >> >> For apples to apples comparison, you should look at the "(mean, across >> all concurrent requests)" value. In case #2, that is only 177.6 ms. With >> multiple concurrent requests, of course each request is going to take >> longer to complete from start to finish (each thread is sharing system >> resources, so can't run as fast as when only a single thread is processing >> a request). However, because the requests are being processed in parallel, >> you have to divide the overall average time per request by the concurrency >> level to get the true time spent on each request (i.e., if 50 requests take >> an average of 4.4 seconds per request processed 25 at a time, then the true >> time spent on each request is 4.4 seconds / 25 = 177.6 ms). This is the >> number that should be compared to the single request case. Alternatively, >> you can just compare the total test time in both cases (assuming you ran >> the same number of total requests in each case). >> > > I am still unclear. > > Have a look at the longest response time which is 5.8 s as compared to <1 > s. This would mean that as soon as the website is faced with 25 odd users, > the response time goes up six times, which is certainly not a good thing. I > am sure CPU/memory/Bandwidth are not bottleneck here. > > Comparing total time taken in both the cases wont be a fair comparison. > One of them is doing things concurrently and other one sequentially. If > both were expected to be the same, then why do things in parallel in the > first place? > > I understand that expected time for 25 concurrent requests ~= 1*[time for > a single request] is wrong because of sharing of resources. But it should > be considerably less than 25*[time for a single request]. And as 25 is a > very small number I'd expect it to be close to 1*[time for a single > request]. The CPU time taken in processing a light request should be close > to zero and it should not be a bottleneck while processing 25 such requests > in parallel. If CPU is turning out to be the bottleneck here, there must be > something wrong in what are are doing. A lot of table definitions is one > such things. And, just curious, why is table definition expensive in the > first place if migrate is set to False and these is no need for database > interaction while defining tables. > > Regarding the optimization of table definitions suggestion, yes it > definitely makes sense and answers my doubts. I will do the needful and > post how it turns out. > > >> >> Anthony >> >> -- >> Resources: >> - http://web2py.com >> - http://web2py.com/book (Documentation) >> - http://github.com/web2py/web2py (Source code) >> - https://code.google.com/p/web2py/issues/list (Report Issues) >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "web2py-users" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/web2py/rH1C7iXMPNA/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- > Resources: > - http://web2py.com > - http://web2py.com/book (Documentation) > - http://github.com/web2py/web2py (Source code) > - https://code.google.com/p/web2py/issues/list (Report Issues) > --- > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
