> (...) You don't really want all your > users using the same R session anyways.
Particularly is users are allowed to run their own code, as the original post suggested it. A sandboxing+quota mechanism would also be necessary. L. On Wednesday, April 24, 2013 7:52:19 PM UTC+2, Alex wrote: > > There is another large potential gotcha, R is very memory heavy. > I do think the route of using Celery or other job management tools makes > sense, especially if you can use R across multiple backend machines. > Would celery mean one rpy2 per celery? You don't really want all your > users using the same R session anyways. > > Thanks, > Alex > > On 04/23/2013 11:08 PM, Derek wrote: > > Thanks Per-Olof > > > > No, it has more to do with the issue raised here: > > > https://github.com/Sleepingwell/DjangoRpyDemo/blob/master/README.md#django-configuration > > > > > Possibly Celery could solve that (?) but I really would like to hear > from > > someone who actually has a production configuration set up and working. > > Perhaps there are less people in the sciences using Django than I > thought... > > > > Derek > > > > On Tuesday, 23 April 2013 21:32:12 UTC+2, Per-Olof �strand wrote: > >> > >> I am not sure I understand your question, but is it really related to > >> using specifically R? Could it be any kind of heavy number-crunching > that > >> needs to be done in the background by a scheduler/task manager? In that > >> case, django-celery may be an option: > >> http://docs.celeryproject.org/en/latest/index.html > >> > >> Per-Olof > >> > >> On Monday, April 22, 2013 9:26:05 PM UTC+2, Derek wrote: > >>> > >>> Based on googling around this topic, it seems that using RPy2 is the > most > >>> common way to interface with R from Python. However all the > discussions on > >>> this seem to centre around working in a desktop (single user) > environment. > >>> > >>> The one discussion I could find that deals with the issue of working > with > >>> R "at scale" is this one - > >>> > https://github.com/Sleepingwell/DjangoRpyDemo/blob/master/README.md#django-configuration > > >>> - which indicates problems with this approach; and suggests it might > be > >>> able to be overcome via creating distinct processes dedicated to run a > WSGI > >>> application (although this article does not give any steps on how to > do > >>> this, or whether it would work in practice). > >>> > >>> Another approach seems to be to use RPy2, with Twisted to enable > multiple > >>> sessions: > >>> > https://docs.google.com/presentation/d/11LJxej6jnbYKzJftpDudYFfVKjaB0BhOzrBSKaxJ2ME/edit#slide=id.p > > >>> . > >>> > >>> Yet another approach might be to use Rserve ( > >>> http://www.rforge.net/Rserve/) and PyRserve ( > >>> http://pythonhosted.org/pyRserve/manual.html), but the latter seems > to > >>> currently be in beta. > >>> > >>> Question is: does anyone have any practical experience actually using > >>> Django with R in a production environment (i.e dozens or hundreds of > users > >>> doing high volume number crunching)? > >>> > >>> Thanks > >>> Derek > >>> > >>> PS Yes, we do need R and not one of the Python-based alternatives, as > R > >>> offers many routines simply not available in those as yet (also, the > client > >>> needs to re-use, and create new, R scripts themselves) > >>> > >> > > > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
