Another option I recently stumbled upon: http://memcached.org/
I haven't tried it yet though. On Feb 16, 8:41 am, Rishi Ramraj <[email protected]> wrote: > It sounds like this is what you're trying to do:http://www.ape-project.org/ > > My understanding is limited, but I'll try to explain it. The basic > structure is: > * A normal web server for synchronous content (ie apache). > * An asynchronous web server (like Tornado or Ape) to push events. > * A state management system (like a database, separate daemon, or a > file) to handle the inter-process communication. > > Events happen on your system (like someone posting a message or > uploading a file) that have to be communicated back to the user. As > the events occur they create entries in the database. The asynchronous > server will keep a request open for a long duration to the client. > While the request is open, the server is constantly checking the > database for events. When an event occurs, the asynchronous server > responds to the request with the event data. If no event occurs during > the duration for the request, the request times out. After a request > is completed, another request is made ad infinitum. > > Using this mechanism, it seems to the user that events are happening > in real time (which is almost true). However, your client doesn't have > to constantly poll the server to make that happen; actual traffic only > occurs when you start a request and when a request terminates (which > is an interval you control). > > On Feb 13, 6:27 am, Graham Dumpleton <[email protected]> > wrote: > > > On 13 February 2010 07:28, till amon <[email protected]> wrote: > > > > Thanks for your interest and of course i don't mind. > > > > Atm i'm doing something like a chatroom-on-steroids, mainly to get a > > > grasp on the various web technologies around. > > > > So if i have one process that propagates update information around > > > ( people join, leave , post ... ) > > > there is basicaly one thread for each user, that accepts an incoming > > > ajaxy request and then sleeps until there is any state change to send > > > back. > > > > So if i had a second process handling file uploads i would like to > > > notify the first process upon completion of the upload with as little > > > overhead as possible, which would then trigger all those sleeping > > > threads to send the update information. > > > May be too heavy, but use an XML-RPC call to call back from one > > process to the other. > > > BTW, having one thread per user itself may not be a good idea as it > > will not scale very well. You should look at event driven systems > > instead. There are various Python web servers designed specifically > > for asynchronous model which can handle high concurrency without > > threads. Have a look at Tornado as the current poster child. > > > Graham > > > > ( don't know. can databases send out asynchronus events these > > > days ? ) > > > > ... erm its not really about whether it makes a lot of sense. more > > > about testing how much responsiveness can be squeezed out of this > > > xmlhttprequest everyone seems so crazy about these days, and which > > > design to use for that. > > > > Therefor the rather aimless question for direction. > > > I'm not that firm with the web yet, any hint would be appreciated. > > > > cheers > > > > On Feb 12, 8:35 pm, Rishi Ramraj <[email protected]> wrote: > > >> From what I understand, state information for web apps is usually > > >> stored in databases. What are you trying to do, if you don't mind me > > >> asking? > > > >> On Feb 12, 10:09 am, till amon <[email protected]> wrote: > > > >> > Hello all, > > >> > and apologies upfront for going to be vague. > > > >> > i'm toying with mod_wsgi for a couple of days now and still am > > >> > somewhat struck when it comes to threading semantics - especially how > > >> > to share state between processes. > > > >> > the current setup is like this : > > >> > WSGIDaemonProcess daemon_group processes=1 threads=15 > > > >> > Which is working fine as long as there is only one process. > > >> > now to the vague part : if one wants to have other processes serving > > >> > different scripts , what would be the cleanest way to share state > > >> > among them if responsiveness was the main concern ? > > > >> > (starting a 16th thread to wait for a unix pipe or socket does not > > >> > seem to work - by design i guess ? ) > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "modwsgi" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]. > > > For more options, visit this group > > > athttp://groups.google.com/group/modwsgi?hl=en. -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
