:( using web interface is inconvenient. Ignore last mail, resending: ------------- Wanted to attach test data as well but automatically clicked 'send' and oops... it gone. Here are couple of test runs: 1.63.5 44.572ms 1.63.5 44.898ms detected noise 0.326ms (136:1 signal-to-noise). full 'ab' output attached
On Tue, Jun 9, 2009 at 4:25 PM, Alexey Nezhdanov <snak...@gmail.com> wrote:
> Wanted to attach test data as well but automatically clicked 'send' and
> oops... it gone.
> Here are couple of test runs:
> 1.63.544.572
>
> On Tue, Jun 9, 2009 at 4:14 PM, Alexey Nezhdanov <snak...@gmail.com>wrote:
>
>> Finally, I started migration (before I was just slapping sql.py, checked
>> out of the trunk over my ancient 1.61.4 install).
>> Migration is not easy, I've been bending source for my needs so now I have
>> to port all this to 1.63.5. Massimo, do you have any objections to this
>> patch? I proposed it some time ago, but you were too busy at the time.
>> The purpose is - if we want custom forms instead of SQLFORM then we have
>> to write our own view.html. But on the other hand - that is double work in
>> the regard that we need to write down <input type='xxx' length='yyy'
>> id='zzz' name='nnn' /> each time while we already generated all this in
>> controller.
>> I'd really like to be able to write in my controller:
>> <table><tr>
>> <td>{{=form.custom.label.my_input}}</td>
>> <td>{{=form.custom.widget.my_input}}</td>
>> </tr></table>
>> See attached patch.
>>
>>
>> On Tue, Jun 9, 2009 at 3:14 PM, Alexey Nezhdanov <snak...@gmail.com>wrote:
>>
>>> Forgot about patches. Here they are.
>>> 'optimised inits v.2'
>>> 'lazy tables' (this one is modified to be applicable to trunk version of
>>> sql.py)
>>>
>>>
>>> On Tue, Jun 9, 2009 at 3:10 PM, Alexey Nezhdanov <snak...@gmail.com>wrote:
>>>
>>>> Results of second set of test runs:
>>>>
>>>> r875 45.523ms
>>>> r882 20.614ms
>>>> inits v.1 18.464ms
>>>> inits v.2 18.677ms
>>>> inits1+lazyT 15.377ms
>>>> inits2+lazyT 15.280ms
>>>>
>>>> Observed noise was 0.502ms for slowest execution (90:1
>>>> signal-to-noise) and 0.889ms for fastest execution (16:1
>>>> signal-to-noise).
>>>> Given than, I think it is safe enough to say that
>>>> "this particular application on this particular hardware/OS
>>>> combination was sped up 2.88...3.31 times".
>>>>
>>>> As in last case - for completeness I'm attaching full console output
>>>>
>>>> I think I know what I'll do. Currently I do not want to release my
>>>> project as any kind of open-source. But I can
>>>> 1) Strip out any code I do not use in this perfomance testing
>>>> 2) rename all sensitive fieldnames/variables to something like field1,
>>>> field2, var3, var4.
>>>> Release resulting package. It would be useless as it is, but it will
>>>> have same perfomance parameters so could be used for testing.
>>>>
>>>> On Tue, Jun 9, 2009 at 1:35 PM, Alexey Nezhdanov<snak...@gmail.com>
>>>> wrote:
>>>> > Wrote 'optimised inits v2' patch. Tested everything.
>>>> >
>>>> > Once again I changed my testing pattern a bit.
>>>> >
>>>> > 1) I dumped my own timing tool in favor of much more standard
>>>> > 'ab' (apache benchmark).
>>>> >
>>>> > 2) I decidedly will publish all these results in two main.
>>>> > I just finished first round of testing. Here are results (reported
>>>> > values are average request time in milliseconds. If anyone interested
>>>> > - I'm attaching a full output from my console).
>>>> > I will do all that testing again and publish same results again so
>>>> > that the amount of noise in all this will be public and clearly
>>>> > visible (here I'm fighting with my own temptation to rerun the tests
>>>> > if timings seem to be 'too away' to me).
>>>> >
>>>> > First four lines share my app's db.py. Last two require a modified
>>>> > db.py, but modification is cosmetical - each define_table is put into
>>>> > separate function and I do db.tablename=create_table_tablename after
>>>> > each function. Model init time was not measured.
>>>> >
>>>> > No more words. Dry figures only. Each line represents result of 10k
>>>> requests.
>>>> > r875 46.025ms
>>>> > r882 21.048ms
>>>> > inits v.1 18.918ms
>>>> > inits v.2 18.122ms
>>>> > inits1+lazyT 16.032ms
>>>> > inits2+lazyT 14.391ms
>>>> >
>>>> > P.S. I'm surprised about last line... Noise?
>>>> >
>>>> > On Tue, Jun 9, 2009 at 11:12 AM, Alexey Nezhdanov<snak...@gmail.com>
>>>> wrote:
>>>> >> new testing:
>>>> >>
>>>> >> ---- SERVER KERNEL ----
>>>> >> --prints
>>>> >> r875 0.04898
>>>> >> r822ini 0.03070 1.60x
>>>> >> --silent
>>>> >> r875 0.04914
>>>> >> r822ini 0.03049 1.61x
>>>> >>
>>>> >> So I get much more consistent results on this hardware.
>>>> >> While this is obviously not the best perfomance (my weaker box,
>>>> >> with less RAM, troubled with video output 1280x1024,
>>>> >> software 90deg rotation - performs BETTER), that does not matter.
>>>> >> What does - is that I can now be sure that these results are
>>>> >> noise-free so I can safely compare timings from various patches.
>>>> >> Proceeding with writing 'inits v2'.
>>>> >>
>>>> >>
>>>> >> On Tue, Jun 9, 2009 at 10:43 AM, Alexey Nezhdanov<snak...@gmail.com>
>>>> wrote:
>>>> >>> Ok. Now the confusion is resolved.
>>>> >>> 1) Speed improvements of 70% and up that I reported yesterday are
>>>> >>> really exist. I just reproduced a 3.47 times model speedup and 2.15
>>>> >>> overall speedup for my app (r875 vs r822+inits).
>>>> >>> BUT this app is atypical. I have added some time measuring code
>>>> there
>>>> >>> so it prints out two lines per each model init. So when I am testing
>>>> >>> perfomance - screen very quickly scrolls up
>>>> >>>
>>>> >>> 2) Simply commenting out two print statements gives me only 1.67
>>>> >>> overall speedup given equal other conditions. I think that processor
>>>> >>> receive additional interrupts from videocard that in turn results in
>>>> >>> more often checks of tasks queue.
>>>> >>>
>>>> >>> 3) I declare all my previous testing results spoiled by noise
>>>> >>> generated by print statement and inappropriate kernel scheduler
>>>> >>> setting.
>>>> >>> I've set up yet another test box with these parameters:
>>>> >>>
>>>> >>> Intel Core2 Duo 2.66GHz, 2G RAM, Ubuntu 9.04, 'server' flavour
>>>> kernel
>>>> >>> 2.6.28-11.42. Initially I considered to install a 'realtime' kernel,
>>>> >>> but it appeared to be unstable on that hardware (and afterall - it's
>>>> >>> for sound/video processing and 'server' type is more likely to be
>>>> >>> installed on servers).
>>>> >>>
>>>> >>> Will report new testing results (and finally I hope to write
>>>> >>> 'optimised inits ver.2' patch) later today.
>>>> >>>
>>>> >>> On Tue, Jun 9, 2009 at 5:14 AM, mdipierro<mdipie...@cs.depaul.edu>
>>>> wrote:
>>>> >>>>
>>>> >>>> Please try launchpad 893. I think it should be faster on GAE.
>>>> >>>> We can do better with lazy tables but at least the validators and
>>>> >>>> calls to getitem are eliminated.
>>>> >>>>
>>>> >>>> Massimo
>>>> >>>>
>>>> >>>> On Jun 8, 1:05 pm, Markus Gritsch <m.grit...@gmail.com> wrote:
>>>> >>>>> On Mon, Jun 8, 2009 at 5:54 PM, mdipierro<mdipie...@cs.depaul.edu>
>>>> wrote:
>>>> >>>>>
>>>> >>>>> > the web2py in trunk can execute models 2.5x faster than the
>>>> current
>>>> >>>>> > stable/production version (requires migrate=False and bytecode
>>>> >>>>> > compiled models).
>>>> >>>>>
>>>> >>>>> Will this speedup also has an effect on GAE? IMO one uploads no
>>>> .pyc files?
>>>> >>>>>
>>>> >>>>> Markus
>>>> >>>> >>>> >>>>
>>>> >>>>
>>>> >>>
>>>> >>
>>>> >
>>>>
>>>
>>>
>>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py Web Framework" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
ab-runs3.gz
Description: GNU Zip compressed data
