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 Heenan <[email protected]> wrote: > 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. > > 1) Put the read function in a thread, wait for the thread to unblock > and continue servicing any other threads that are no longer blocked. > This is what web2py does using a Python file read. The OS > automatically provides thread scheduling. > > 2) Tell the OS to pass a message to an event callback when the OS is > ready. A separate thread is not required if the application chooses to > process its own message queue as the thread in effect simply relays > the message on. > > There is of course other blocks: file writing, database access and > network read and write (including from/to the http request PC) > > It is tempting to say it is not rocket science. > > Anyway the main message is being aware of the plumbing and avoiding > blind religious type fixations is important for long term planning and > scalability issues. > > We really need to face up to realities that seeing Python as a black > box type total solution is not healthy. > > John Heenan > > On Aug 26, 2:27 am, mdipierro <[email protected]> wrote: > > > On Aug 25, 11:00 am, Phyo Arkar <[email protected]> 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 can request different pages > > which open the same file unless the file is explicitly locked by your > > code. > > > > 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 .. > > > Tell us more or I cannot help. > > > > 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
