Thanks. I'd like to rewrite nltk processing and move them from django. That could be very easy, and if that works, I coud work on more caching and others later.
On Wed, Oct 17, 2012 at 12:50 AM, Guido Notari <[email protected]> wrote: > Il giorno 16/ott/2012, alle ore 18.33, Samuel ha scritto: > > > And I have more info around nltk package I used for language processing. > > Wow, interesting. That's possibly explains a lot.. > > > nltk is heavily used in my app, which takes long time to import at the > development environment at the first time. Since the server is very busy, > so can it be a headache besides db and caches issues? > > Of course I don't know about the inner workings of your app but, given the > (heavy) use of this "computational intensive" components, could you > consider moving them to a queue? > > I mean, if you're doing elaboration in many of your requests, why not > offloading that core to some workers, doing them in background and freeing > the web workers to answer people? > We've done that many times, using the most useful uwsgi's Spooler feature. > That way, you could handle the load in a controlled fashion (how many > processes dedicated to ntlk elaboration) and let users wait "offline", > serving them intermediate pages with a message to "wait" and a reload meta. > > regards > Guido > > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi > -- *吴焱红(Samuel)* 博客: blog.shanbay.com 微博: 扇贝网 <http://www.weibo.com/shanbay> 人人网： 一起背单词公共主页 <http://page.renren.com/699128841?ref=lnkprofile>
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
