On Tue, Nov 26, 2013 at 8:42 PM, Ricardo Pedroso <[email protected]>wrote:
> How may cores do you have?
> Are all the cores being used when you run the tests?
> What webserver are you testing against?
>
>
I have 4 cores, 16 GB RAM running Apache. But I think, this is irrelevant.
Apache easily serves 1000 static file requests (which are not processed
through web2y) with 100 concurrent connections on the same machine, with
the largest response time being <133 ms.
Concurrency Level: 100
Time taken for tests: 0.884 seconds
Complete requests: 1000
Failed requests: 0
Write errors: 0
Total transferred: 54234000 bytes
HTML transferred: 53846000 bytes
Requests per second: 1130.96 [#/sec] (mean)
Time per request: 88.421 [ms] (mean)
Time per request: 0.884 [ms] (mean, across all concurrent requests)
Transfer rate: 59898.81 [Kbytes/sec] received
Connection Times (ms)
min mean[+/-sd] median max
Connect: 3 19 6.5 19 34
Processing: 36 67 16.4 64 117
Waiting: 11 25 8.4 23 64
Total: 40 86 17.2 84 133
Percentage of the requests served within a certain time (ms)
50% 84
66% 94
75% 98
80% 101
90% 107
95% 115
98% 125
99% 128
100% 133 (longest request)
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 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.
