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 little coverage in the book's deployment chapter, but it could use a systematic discussion. What are the implication for web2py apps of http server policies, database locks (sqlite especially), session locking, the GIL, etc? With a section on best practices. > > > > On 8/25/10, pierreth <[email protected]> wrote: >> 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 <[email protected]> wrote: >>> 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 services is going to OS block on >>> file reading (and writing) and on database access. Using threads is a >>> classic and easy way out that carries a lot of baggage. Windows has >>> had a way out of this for years with its asynch (or event) >>> notification set up through an OVERLAPPED structure. >>> >>> Lightttpd makes use of efficient event notification schemes like >>> kqueue and epoll. Apache only uses such schemes for listening and Keep- >>> Alives. >>> >>> No matter how careful one is with threads and processes there always >>> appears to be unexpected gotchas. Python has a notorious example, the >>> now fixed 'Beazly Effect' that affected the GIL. Also I don't think >>> there is a single experienced Python user that trusts the GIL. >>> >>> John Heenan >>> >>
