django中的view.py,如果一个方法中有一个比较耗时的操作，比如分析一个网页，这样的操作适合放在view.py中吗？不过不适合，大家怎么处理的？

启动至少两个 instance，在不同的端口。绑定 80 的那个用于所有读操作，另外一个用于这样的耗时操作。

通过 queue 去 call 另外一个。

@Livid 请求在等待这个长操作的结果。有时候比较长的时候30s，下一个请求被block住了。

@yaotian 这就是为什么要在两个端口启动 _至少_ 两个 instance 的原因。

我的某个项目中，Tornado 框架，12 个读 instance，12 个写 instance，通过 least connection 方式做 load balance。

@Livid 之前没考虑过起多个instance的方法。django支持这样的least connection方式吗？你的这个项目架构有分享吗？想读一读

@yaotian 我是这样做的：

1. 通过 supervisord 管理启动的 instances，每个一个端口，比如 30000-30009 是前段端口，30010-30019 是后端端口。

2. 在 nginx 里把 30000-30009 做成前端的 upstream，30010-30019 是后端的 upstream。nginx 支持 least_conn 方式的负载均衡。

3. 然后通过 nginx 的 allow/deny 规则让后端 upstream 只能通过 127.0.0.1 访问。

4. 在 Tornado 里通过 rq 去 call 后端的那个域名。

也许你可以试试celery
反正这种东西还是扔到队列里比较好吧

@adamwen 和主站放到一起的好处就是尽量复用代码，比如 data models 操作相关的那些。

如果单独为 rq/celery 写 tasks，那么很多 HTTP 环境里的上下文可能都没法用。

@Livid 是个不错的主意
通过nginx的load balance的request队列 避免了自己再去写队列

PS:
你那个前端接口和后端接口只是为了做load balance么
如果是楼主的问题的话 可以分出一个instance就行
把不断的去call 后端域名

@Livid 感谢。写的非常清楚。已经了解大体思路。
多说几句为长操作起的10个instance:
起那么多instance的原因是当其中一个instance还在执行那个长操作的时候， nginx的upstream可以将后来的request分配到其它的instance, 举个例子同时来了十个request， 他们会被分配到不同的instance上， 第11个就得等待了。

我的理解对吧？

@yaotian
应该是为了能够并发的处理request
多于instance个数的未处理的request会被阻塞到nginx的队列里直到有一个instance处理完

分成两个请求，view.py用于展示页面，较慢的计算过程用ajax返回数据更新页面，

老老实实的用队列放后端吧，一切不用队列的说法都是异端

原来Supervisor可以这样用，太精彩了。学习

Tornado的话搞成异步操作最好了

1.5中新增了一个关于这个的，可以看下。