我正在尝试使用beanstalk设置可伸缩的背景图像处理 . 我的设置如下：
-
应用程序服务器（在Elastic Beanstalk上运行）接收文件，将其放在S3上并发送请求以通过SQS处理它 .
-
工作服务器（也在Elastic Beanstalk上运行）轮询SQS队列，接收请求，从S3加载原始图像，处理它，产生10种不同的变体并将它们存储回S3 .
-
这些上传事件的发生速度约为每天1-2批次，每批次20-40张，不可预测的时间 .
问题：我目前正在为 Worker 使用一个微实例 . 生成图片的一个变体可能需要3秒到25-30（似乎第一个在3中完成，但随后微实例减速，我认为这是通过其2秒突发性工作负载设计） . 无论如何，当我上传30张图片意味着工作需要：30张图片* 10个变种每个* 30秒= 2.5小时处理??！？！
显然这是不可接受的，我尝试使用“小”实例，那里的性能是一致的，但每个变体大约5秒，所以每批仍然30 * 10 * 5 = 26分钟 . 仍然不能接受 .
攻击这个问题的最佳方法是什么，它会获得最快的结果并且同时具有价格效率？
我能想到的解决方案：
-
依靠beanstalk自动缩放 . 我试过，根据CPU利用率设置自动缩放 . 这似乎很慢，反应和不可靠 . 我已经尝试将测量时间设置为1分钟，并且突破持续时间为1分钟，阈值为70％上升，30％下降为1增量 . 它需要系统一段时间才能向上扩展然后缩短一段时间，我可能会对它进行微调，但它仍然感觉很奇怪 . 理想情况下，我想获得一台比微型（小型，中型？）更快的机器用于这些工作峰值，但是使用beanstalk意味着我需要一直运行至少一次，因为大多数时候系统处于空闲状态价格没有任何意义 .
-
为工作者放弃beanstalk，实现我自己对微型计算机上运行的SQS队列的监视器，当队列中有足够的待处理消息时，让它启动更大的机器（或更大的机器组），在我们的那一刻终止它们检测队列空闲 . 这似乎是很多工作，除非有一个解决方案准备在那里 . 无论如何，我失去了通过git，管理环境等部署代码的beanstalk的好处 .
我不喜欢这两种解决方案中的任何一种解决方案我还缺少其他不错的方法吗？
谢谢
1 回答
在这种情况下，微实例上的CPU利用率可能不是用于自动缩放的最佳度量标准 .
SQS队列的长度可能是更好的度量标准，也是最自然的标准 .
毋庸置疑，如果你能为更大的基线机器预算，一切都会跑得更快 .