In Java a serverlet, as far as I understand, is a class which conforms
to some API that allows it to serve one http request. Each instance is
executed in its own thread. The Python equivalent of the serverlet API
is a WSGI application and web2py is based on WSGI, therefore the
parallelization mecha
P.S. In the end the bottle neck is ALWAYS database access.
On Aug 24, 12:20 am, mdipierro wrote:
> In Java a serverlet, as far as I understand, is a class which conforms
> to some API that allows it to serve one http request. Each instance is
> executed in its own thread. The Python equivalent of
Somebody here did. They found it works but there was a proliferation
of open files. We never got to the bottom of this.
On Aug 24, 4:55 am, Michele Comitini
wrote:
> 2010/8/24 mdipierro :> P.S. In the end the bottle
> neck is ALWAYS database access.
>
> true! many driver implementations do not r
There is absolutely no need to serve up static web pages of a pure
Python web app or a WGSI app with a separate thread. It is
inefficient to use an inbuilt web server (of a Python web app) or
Apache (if WGSI used) to serve up static web pages using separate
threads. Both Lighttpd and Nginx are wel
On 24 août, 01:20, mdipierro wrote:
> In Java a serverlet, as far as I understand, is a class which conforms
> to some API that allows it to serve one http request. Each instance is
> executed in its own thread.
Yes, but one instance can be executed by multiple threads at the same
time. It is one
On Aug 24, 10:36 am, pierreth wrote:
> On 24 août, 01:20, mdipierro wrote:
>
> > In Java a serverlet, as far as I understand, is a class which conforms
> > to some API that allows it to serve one http request. Each instance is
> > executed in its own thread.
>
> Yes, but one instance can be execu
Can't we at least have an acknowledgement that it is not necessary for
web2py to use a thread per request model and that web2py could instead
use an event model?
WSGI can be viewed as an evil conspiracy to force Python web apps to
follow the Apache thread per request model! Also with Apace mod_wsg
Lee's 'The Problem with Threads' link is at
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
There is in Lee at http://ptolemy.eecs.berkeley.edu/%7Eeal/
John Heenan
On Aug 25, 5:00 am, John Heenan wrote:
> Can't we at least have an acknowledgement that it is not necessary for
> w
On Aug 24, 9:00 pm, John Heenan wrote:
> Can't we at least have an acknowledgement that it is not necessary for
> web2py to use a thread per request model and that web2py could instead
> use an event model?
Acknowledged.
I agree with you. web2py does not care. It is the web server that
decides. The question that started this thread was about the built-in
web server and it does follow the thread model.
On Aug 24, 2:00 pm, John Heenan wrote:
> Can't we at least have an acknowledgement that it is not necessary for
>
On 24 août, 13:04, mdipierro wrote:
> when you do "python web2py.py" you do not start the wsgi app. You
> start the rocket web server which makes a number of threads. When a
> new http request arrives it is assigned to a free thread (or a new
> thread is created) and the wsgi is run in that thread
I don't understand. The link is broken at the moment.
Do you mean using only on thread and dispatching using the observer
pattern? Doing only one request at a time? It does not makes sense to
me. But I guess there is something I don't understand... Can someone
guide me?
On 24 août, 20:04, mdipier
The model is executed at every http request, new thread or not new
thread.
On Aug 24, 9:36 pm, pierreth wrote:
> On 24 août, 13:04, mdipierro wrote:
>
> > when you do "python web2py.py" you do not start the wsgi app. You
> > start the rocket web server which makes a number of threads. When a
> >
No, nothing that abstract. Using WSGI forces a new thread for each
request. This is is a simple and inefficient brute force approach that
really only suits the simplest Python applications and where only a
small number of concurrent connection might be expected.
Any application that provides web s
I would appreciate a good reference to understand the concepts you are
talking about. It is something new to me and I don't understand.
On 25 août, 11:22, John Heenan wrote:
> No, nothing that abstract. Using WSGI forces a new thread for each
> request. This is is a simple and inefficient brute f
On Aug 25, 11:00 am, Phyo Arkar wrote:
> Did I Read that reading files inside controller will block web2py , Does it?
No web2py does not block. web2py only locks sessions that means one
user cannot request two concurrent pages because there would be a race
condition in saving sessions. Two user
Even with file reading there is no way the disk drive, its controllers
and various buses can keep up with the CPU.
Hence reading any file from disk will cause the OS to intervene and
block (reading a template view file, controller file or otherwise),
albeit a 'short' time.
Here are two choices.
call
session._unlock()
if you do not need session locking
On Aug 25, 11:38 am, Phyo Arkar wrote:
> Yes may be session was locked , thats why
> session.current=processing_path not working
>
> But then again , while processing files i try opening separate page ,
> to other controller , it was wai
the time to execute a typical web2py action my server is 10-20ms. The
time to open a file or write a small file is so small that is not
measurable. I am not sure I believe there is any issue here or perhaps
I do not understand the problem. Can you provide a test case?
On Aug 25, 2:11 pm, John Heen
Linux lost a PR war over the exact same issue that I am addressing
now.
The point is being aware of issues surrounding the scalability of
services associated with using far more OS resources than required and
at more risk.
The tiny amount of time a single thread, thread A, may be blocked
during a
The problem is only if have two http request from the same client in
the same session
A arrives loads session and unlocks
B arrives loads session and unlocks
A change session and saves it
B changes session and saves it
Nothing breaks but B never sees changes made by A and they are
overwritten by
This is a bug. I fixed it in trunk. Thanks Jonathan.
On Aug 25, 9:30 pm, Jonathan Lundell wrote:
> On Aug 25, 2010, at 6:37 PM, mdipierro wrote:
>
>
>
> > The problem is only if have two http request from the same client in
> > the same session
>
> Thanks for that; I was wondering under which con
You are right. Please check trunk again.
Massimo
On Aug 27, 10:25 am, Jonathan Lundell wrote:
> On Aug 25, 2010, at 8:12 PM, Jonathan Lundell wrote:
>
>
>
> > On Aug 25, 2010, at 7:56 PM, mdipierro wrote:
>
> >> This is a bug. I fixed it in trunk. Thanks Jonathan.
>
> > It's fixed in the sense t
2010/8/24 mdipierro :
> P.S. In the end the bottle neck is ALWAYS database access.
true! many driver implementations do not release the GIL properly on a
blocking call.
Anyway a well designed db would avoid the problem entirely.
Do you know if anyone tried web2py on pypy [http://pypy.org] ?
CPython threading is not useful for (real) parallel processing
1) thread (with GIL) is good for *cpu bound processes* that do not
stop the main process while blocked by a system call (the intent is
similar to select/poll)
2) for really using multiple cores/cpus use something more
appropriated or ma
2010/8/24 pierreth :
> Yes but a web2py server is running with only one process and using
> more web2py processes for serving the same web2py app will lead to
> synchronization problems. With processors having more and more cores,
> having a web server that cannot use them is not very fun. It is a
John,
Tnx ... I'll keep this under my pillow ;-)
2010/8/24 John Heenan :
> Lee's 'The Problem with Threads' link is at
> http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf
>
> There is in Lee at http://ptolemy.eecs.berkeley.edu/%7Eeal/
>
> John Heenan
>
> On Aug 25, 5:00 am, John Heen
Did I Read that reading files inside controller will block web2py , Does it?
Thats a bad news.. i am doing a file crawler and while crawling ,
web2py is blocked even tho the process talke only 25% of 1 out of 4
CPUs ..
On 8/25/10, pierreth wrote:
> I would appreciate a good reference to unders
On Aug 25, 2010, at 9:00 AM, Phyo Arkar wrote:
> Did I Read that reading files inside controller will block web2py , Does it?
>
> Thats a bad news.. i am doing a file crawler and while crawling ,
> web2py is blocked even tho the process talke only 25% of 1 out of 4
> CPUs ..
This stuff gets a li
Yes may be session was locked , thats why
session.current=processing_path not working
But then again , while processing files i try opening separate page ,
to other controller , it was waited till the first (file Crawler) page
finished parsing.
ok i will make a separate thread about this.
On 8
On Aug 25, 2010, at 1:41 PM, mdipierro wrote:
>
> call
>
> session._unlock()
>
> if you do not need session locking
If you do that (without calling session.forget), what will happen in
_try_store_on_disk when cPickle.dump(dict(self), response.session_file) is
called with a None file argument?
On Aug 25, 2010, at 6:37 PM, mdipierro wrote:
>
> The problem is only if have two http request from the same client in
> the same session
Thanks for that; I was wondering under which conditions unlocking might be
permissible (and I'm still not entirely clear, but never mind for now).
My concern
On Aug 25, 2010, at 7:56 PM, mdipierro wrote:
>
> This is a bug. I fixed it in trunk. Thanks Jonathan.
It's fixed in the sense that it won't raise an exception. But now how is
calling _unlock different from calling forget?
>
> On Aug 25, 9:30 pm, Jonathan Lundell wrote:
>> On Aug 25, 2010, at
On Aug 25, 2010, at 8:12 PM, Jonathan Lundell wrote:
>
> On Aug 25, 2010, at 7:56 PM, mdipierro wrote:
>>
>> This is a bug. I fixed it in trunk. Thanks Jonathan.
>
> It's fixed in the sense that it won't raise an exception. But now how is
> calling _unlock different from calling forget?
Nag.
34 matches
Mail list logo
