Thanks!
Looks to be nice feature/fix :)
At this time we do not yet have a way to switch off models. What you
can do is move the controller that does not need dal to another app
that does define models and share their sessions (if you need
sessions). I agree we need a better solution.
On Apr 6, 8:40 am, Jay wrote:
> Thanks Jonathan and
Thanks Jonathan and Massimo. This makes web2py EVEN more attractive
for high end apps.
I have one further request:
A little history, I use web2py for all heavier lifting (forms and db
processing etc.) but use Tornado for serving pages (see http://fon.st
) with links and redirecting links. I want
On Mar 17, 2011, at 10:44 AM, Anthony wrote:
> Thanks. This is helpful.
>
> On Thursday, March 17, 2011 1:14:22 PM UTC-4, Jonathan Lundell wrote:
> On Mar 17, 2011, at 9:45 AM, Anthony wrote:
>> On Thursday, March 17, 2011 11:17:17 AM UTC-4, Jonathan Lundell wrote:
>> On Mar 17, 2011, at 7:40 AM,
Thanks. This is helpful.
On Thursday, March 17, 2011 1:14:22 PM UTC-4, Jonathan Lundell wrote:
> On Mar 17, 2011, at 9:45 AM, Anthony wrote:
>
> On Thursday, March 17, 2011 11:17:17 AM UTC-4, Jonathan Lundell wrote:
>>
>> On Mar 17, 2011, at 7:40 AM, Anthony wrote:
>>
>> In the book under "Eff
On Mar 17, 2011, at 9:45 AM, Anthony wrote:
> On Thursday, March 17, 2011 11:17:17 AM UTC-4, Jonathan Lundell wrote:
> On Mar 17, 2011, at 7:40 AM, Anthony wrote:
>> In the book under "Efficiency Tricks" it says:
>>
>> Set session.forget() in all controllers and/or functions that do not change
>
On Thursday, March 17, 2011 11:17:17 AM UTC-4, Jonathan Lundell wrote:
>
> On Mar 17, 2011, at 7:40 AM, Anthony wrote:
>
> In the book under "Efficiency Tricks" it says:
>
> Set session.forget() in all controllers and/or functions that do not
> change the session.
>
> Does this new change m
On Mar 17, 2011, at 7:40 AM, Anthony wrote:
> In the book under "Efficiency Tricks" it says:
>
> Set session.forget() in all controllers and/or functions that do not change
> the session.
>
> Does this new change make it unnecessary to bother calling session.forget()
> in most cases because s
In the book under "Efficiency Tricks" it says:
Set session.forget() in all controllers and/or functions that do not change
the session.
Does this new change make it unnecessary to bother calling session.forget()
in most cases because sessions are no longer saved when empty or not
modified?
Correct. If one only needs to track ip of visitors it is best to use
the server logs (apache logs or rocket logs)
On Mar 16, 4:26 pm, Ross Peoples wrote:
> From my understanding, sessions are only forgotten if not changed, so
> if you add something to the session, it gets saved. This speedup
> pr
>From my understanding, sessions are only forgotten if not changed, so
if you add something to the session, it gets saved. This speedup
prevents saving the session when there is nothing to save.
And you could always use cache or db for analytics if that's what you
are looking for.
Ross Peoples
O
If we *do* want to track non-logged-in visitors, will we need to restore
these sessions?
Great update. I know for a reason the thousands of session files
web2py is creating for Radbox are slowing us down, and I wasn't sure I
wanted to store sessions in the db. Good improvement!
On Mar 16, 2:02 pm, Ross Peoples wrote:
> In that case, great job to you both!
>
> On Mar 16, 2011, at 1:57
In that case, great job to you both!
On Mar 16, 2011, at 1:57 PM, Massimo Di Pierro wrote:
> You should also thank Jonathan, we have been working together on this.
>
> Massimo
>
> On Mar 16, 11:40 am, Ross Peoples wrote:
>> Ok, here are the results from testing the welcome app:
>>
>> BEFORE T
You should also thank Jonathan, we have been working together on this.
Massimo
On Mar 16, 11:40 am, Ross Peoples wrote:
> Ok, here are the results from testing the welcome app:
>
> BEFORE TRUNK UPDATE
> =
> Time taken for tests: 91.843 seconds
> Requests p
Ok, here are the results from testing the welcome app:
BEFORE TRUNK UPDATE
=
Time taken for tests: 91.843 seconds
Requests per second: 10.89
Time per request: 91.843 ms
BEFORE TRUNK UPDATE WITH MIGRATE=FALSE AND BYTECODE COMPILED
==
I'm running a bunch of tests now. I'll report back in a few with my results.
Works for me now - and certainly feels very snappy! No sessions files being
created unless user logs in.
On 16 March 2011 16:01, Massimo Di Pierro wrote:
> I found out that auth was causing session to be saved even if unused.
> I changed it.
>
> With the latest trunk, auth.define_table(migrate=F
I found out that auth was causing session to be saved even if unused.
I changed it.
With the latest trunk, auth.define_table(migrate=False) and bytecode
compilation, the welcome index page runs at 17ms on my laptop.
Massimo
On Mar 15, 7:51 am, Ross Peoples wrote:
> I did some testing on my app,
On Mar 15, 2011, at 6:00 AM, Ross Peoples wrote:
> I just noticed that the sessions are still being saved, which may be why I
> didn't see any performance improvement. I deleted all of the sessions inside
> the sessions folder, stopped and restarted the server, then visited the
> /default/index
Ok, that makes sense. My app connects to a MSSQL database on another
machine, so that explains the response times > 100 ms for me. So would
setting pool_size to 1 on the DAL keep at least one database connection open
for future page views and speed things up?
The speedup mentioned applies to do-nothing apps. In particular to
apps that do not use database.
The welcome app does lots of stuff even if you do not use. To start
with it opens the sqlite database. Although queries are fast it takes
just 30ms to open the db and lock it in my tests.
Anyway, you
No form, I have customized the layout.html file, but nothing that uses
session or forms.
Here is the controller:
def index():
"""
example action using the internationalization operator T and flash
rendered by views/default/index.html or views/generic.html
"""
response.flash =
You must find the logic in your code that is changing the session
object. There must be something. Do you have a form in the page?
On Mar 15, 8:00 am, Ross Peoples wrote:
> I just noticed that the sessions are still being saved, which may be why I
> didn't see any performance improvement. I delet
I just noticed that the sessions are still being saved, which may be why I
didn't see any performance improvement. I deleted all of the sessions inside
the sessions folder, stopped and restarted the server, then visited the
/default/index page that flashes 'You are successfully running web2py.'
I did some testing on my app, which still implements the welcome app's
default/index function that shows Hello World. Here are my results:
BEFORE TRUNK UPDATE - CONCURRENCY 1
===
Time taken for tests: 108 seconds
Requests per second: 9.25
Time per request: 108.138
I think when I speak of scalability we shouldn't make the assumption
that "requests [are coming from] only a few users". That said, it's
great to know session handling is being optimized. I think smart
session handling and smart cache handling will greatly improve
performance.
On Mar 14, 11:1
What I mean is ferwer requests than all requests actually change the
session.
On Mar 14, 11:58 pm, VP wrote:
> I think when I speak of scalability we shouldn't make the assumption
> that "requests [are coming from] only a few users". That said, it's
> great to know session handling is being opt
This also explains why the problem occurred with Apache ab but not for
(usually) people using web2py in production. In production you do not
have thousand of session files because many of the requests from from
the same few users.
There are exceptions. Apps that have many semi-static pages or are
I think also address the scalability problem that has occasionally
been reported using ab tests.
Apache ab sends many uncorrelated requests and each of them results
(resulted) in a new session file saved. Eventually the more tests you
run the more files you have. The more files in the same folder
30 matches
Mail list logo
