Hi Anthony!,
Indeed, the ajax call was the issue, after reading this:
http://web2py.com/books/default/chapter/29/04#session
I realised that storing sessions in database solved my problem(there's no
more blocking calls issue).
Thanks a lot for your help!!!!
Cheers.
On Thu, Oct 23, 2014 at 1:01 AM, Anthony <abasta...@gmail.com> wrote:
> Instead of checking the timings in the console, check the timings during
> the actual Ajax request (maybe return the timings in some HTML and display
> it in the browser instead of just returning "OK"; or print the timings to
> the console).
>
> Are there any other Ajax requests that get fired before this one that
> could be causing a delay? If you are using file based sessions, a prior
> Ajax request would block a new request while waiting for the session file
> to be unlocked (unless you call session.forget(response)).
>
> Anthony
>
>
> On Wednesday, October 22, 2014 9:30:50 PM UTC-4, Luciano Laporta Podazza
> wrote:
>>
>> Hi Niphlod,
>>
>> I did what you say and if I try doing the query through console it works
>> perfectly and fast:
>>
>> >>> db._timings
>>
>> [('SET FOREIGN_KEY_CHECKS=1;', 0.0002541542053222656), ("SET
>> sql_mode='NO_BACKSLASH_ESCAPES';", 0.0002338886260986328)]
>>
>> >>> db((db.alerts.alerts_id==1)&(db.alerts.archived != True)).update(
>> archived=True, crime="Robo", operator_id=1)
>>
>> 23
>>
>> >>> db._timings
>>
>> [('SET FOREIGN_KEY_CHECKS=1;', 0.0002541542053222656), ("SET
>> sql_mode='NO_BACKSLASH_ESCAPES';", 0.0002338886260986328), ("UPDATE
>> alerts SET archived='T',operator_id=1,crime='Robo' WHERE
>> ((alerts.alerts_id = 1) AND (alerts.archived <> 'T'));",
>> 0.010937213897705078)]
>>
>> >>> db.commit()
>>
>> >>> db._timings
>>
>> [('SET FOREIGN_KEY_CHECKS=1;', 0.0002541542053222656), ("SET
>> sql_mode='NO_BACKSLASH_ESCAPES';", 0.0002338886260986328), ("UPDATE
>> alerts SET archived='T',operator_id=1,crime='Robo' WHERE
>> ((alerts.alerts_id = 1) AND (alerts.archived <> 'T'));",
>> 0.010937213897705078)]
>>
>> But again, if I try sending the ajax request(a simple one, really), it
>> gets stucked as I mentioned before, then after 20-30seconds the record gets
>> updated.
>>
>> I'm using MySQL 5.5 with less than 50 records on the affected table.
>>
>> Any help will be appreciated. Thanks
>>
>> On Wednesday, September 10, 2014 6:20:47 AM UTC-3, Niphlod wrote:
>>>
>>> BTW, log somewhere db._timings before returning and try to replay the
>>> query in mysql to see what's going on.
>>>
>>> On Wednesday, September 10, 2014 12:54:03 AM UTC+2, Leonel Câmara wrote:
>>>>
>>>> Well that's true, but web2py automatically calls db.commit for you
>>>> after running the controller. That would not cause the slowdown anyway.
>>>>
>>> --
> 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/6z13PTcZ5io/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> web2py+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
Atte
Luciano Laporta Podazza
--
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 web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
