类似于空间图像数据的平铺服务器,我想在我的基于Django的Web应用程序中查看许多动态生成的图像(合并图像,颜色变化等).由于一个客户端可以在短时间内轻松地请求许多(> 100个)图像,因此很容易将Web服务器(Apache mod_wsgi)关闭.

因此,我正在寻找替代方法.由于我们已经使用了Celery,因此异步执行此图像处理并将生成的数据推送到客户端可能是个好主意.为了开始这一点,我将WSGI服务器切换为gevent,Apache用作代理.但是,我还没有设法推动推动工作,但我不确定这是否是正确的方向.基于此,我有三个问题：

>您认为这(Celery,gevent,Socket.IO)是一种明智的方式,允许许多客户使用该应用程序而无需关闭Web服务器吗？你看到替代品吗？
>如果我将图像处理交给Celery并让它在完成后将图像数据推送到浏览器,那么连接将不会通过Apache,是吗？
>如果使用某种推送到客户端,最好是为每个图像使用一个连接或一个连接(并在完成后关闭它)？

背景：

我正在处理的Django应用程序允许用户显示非常大的图像.这是通过在之前平铺大图像并且仅向用户显示网格中的当前相关图块来完成的.据我所知,这是在地图和空间图像数据领域(例如OpenStreetMap)中提供数据的标准方法.但是与地图数据不同,我们在Z中也有许多切片,用户可以滚动(生物图像).

当静态服务瓷砖时,所有这些都可以正常工作.现在我添加了选项来动态生成这些图块 – 合并不同的图像,校正颜色,….这是有效的,但是对于Web服务器来说是一些重负荷,因为一个图像需要大约0.1秒才能生成.目前我们将Apache与mod_wsgi(WSGIRestrictedEmbedded On)一起使用,很容易将服务器关闭.只是浏览图像堆栈将导致挂起的Web服务器.我已经尝试调整MaxClients等,并关闭了KeepAlive.我还为mod_wsgi尝试了不同的线程/进程组合.但是,没有任何帮助足以允许多个用户使用.因此,我认为Comet / WebSocket方式可以在这里提供帮助.

解决方法:

All this works fine when the tiles are statically served. Now I added
the option to generate those tiles on the fly — different images are
merged, color corrected, …. This works, but is some heavy load for the
web server as one image takes about 0.1s to be generated.

您需要一个负载均衡器,将图像请求发送到前端服务器(例如NginX),该服务器将根据需要多路复用(并缓存！)多个请求,前提是您提供足够的后端服务器来完成繁重的工作.

这看起来像是亚马逊分布式计算的经典案例：您可以将磁贴存储在S3存储中(或者通过EBS存储NFS).所有图像处理服务器都从单个图像存储库中获取数据.

开始时,您可以在同一台计算机上同时拥有Web应用程序和图像处理服务器的一个实例.但基本上你的流程是三个：

>计算图像URL的Web服务(您需要某种方式将操作编码为URL中的参数,否则您将不得不使用cookie和会话存储,这更ickier)
>图像服务器接收“图像公式”并提供JPEG图块
>文件服务器,允许访问大图像或单个原始图块

我曾在几个这样的架构中工作,其中我们的图像层存储在单个图像文件中(例如,五个缩放级别,每个十五个通道从FIR到UV,总共75个“图像”一侧高达100K像素,以及客户可以请求’缩放级别2,红色通道加上UV-1通道和绿色之间的差异的两倍,来自X = 157,Y = 195到X = 167,Y = 205’的区块).