On Mon, Nov 26, 2012 at 10:30 PM, Craig Small <[email protected]> wrote:
> On Mon, Nov 26, 2012 at 08:25:47PM +0100, Alessandro Molina wrote: > > Just keep in mind that asyncjob is meant for short term tasks and on > > production you will probably start more that one process of your > > application. > > Starting more than one process will result in having multiple > execution > > queues (one for each process) which greatly reduces the side effects > of > > having the GIL in place. > Just to calrify that, are you suggesting something like. > $ python myjob.py & > $ python myotherjob.py & > > No, no :D I was just saying that on production your probably have more than one worker and the asyncjob queue is for each worker. So you already have multiple processes running async jobs. > ie two different python interpreters for different functions? I've got > a lot of back-end work going on and while most (all?) is asynchronous > calls (with the associated extra madness that entails) I'm stil worried > about processing times, mainly around the database access speeds though > of course I'm testing on sqlite so that might be the problem. > DB slowness is usually related to the time the data you created inside the controller takes to propagate to the real database, that is the reason why asyncjob provided the asyncjob_timed_query helper. You might want to give a try to a tasks queue like celery and see if you have better results. I'm also open to any patch to asyncjob, feel free to send them if you end up implementing changes. -- You received this message because you are subscribed to the Google Groups "TurboGears" 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/turbogears?hl=en.
