我有一个小的RoR应用程序，使用RMagick生成图像，性能不是在我认为会的地方。 服务器configuration是运行Rails 3.1RC4 / Ruby 1.9.2 / Nginx / Passenger的EC2上的64位Ubuntu 11.04映像。 我已经尝试了几个不同的Amazon实例types，从小（32位图像）到c1.xlarge，结果非常相似。
激发ApacheBench（ab -n 10 -c 1）给我一个可接受的300ms的平均响应时间，testing在大约2秒钟内完成，但是增加到5个并发甚至2个并发请求将性能降低到1500ms，并且testing需要更长的时间。 即使在大型实例types中，ab运行（ab -n 10 -c 10）也会使系统降低到5000ms。 我预计响应时间将保持非常一致，但总时间会下降。 这是不正确的假设吗？ 在每次testing中，内存永远都不会很高（<1GB），但是CPU运行在100％。 我的MacBook Pro运行开发模式可以匹配这些数字。
它几乎看起来像什么东西是单线程的地方。 该应用程序几乎是你可以得到的简单，唯一复杂的是RMagick调用。 是否有RMagick导致线程问题？ 是否有更好的RoR应用程序服务器（Unicorn，Mongrel群集等）？ 我是否正确使用ApacheBench？
UPDATE
我添加了一些新的纯文本路由到configuration，他们performance非常好。 纯文本返回32K几乎没有导致CPU任何问题，我可以达到72瑞奇/秒（这可能受限于我的互联网连接，而不是EC2服务器）。 返回5字节超过250 req /秒。
有这么多的可能性…有一个明显缺乏并发性的事实将指出缺乏适当的乘客configuration（ passenger_max_pool_size是关键variables），但与rmagick在组合中，问题可能是磁盘I / O（ EBS数量可怕 – 性能可变）。 另一方面，你的系统统计数据表明CPU已经最大化的事实将指向rmagick嚼CPU像疯了（做什么 ？），或者在你的代码中的一些其他效率低下，导致CPU挂钩（虽然如果你pipe理拉一个c1.xlarge，我留下了深刻的印象）。
增加您的乘客人数，并收集更好的按stream程和系统范围统计到实际发生的事情，答案应呈现。
我们只是在EC2 微型实例上debuggingRails 3 + Nginx + Passenger + PostgreSQL堆栈的性能问题的原因。 他们做一些所谓的CPU节stream，这是很好的解释这个博客文章： http : //gregsramblings.com/2011/02/07/amazon-ec2-micro-instance-cpu-steal/
我们进行了一系列的压力testing，我们无法find瓶颈，但是整个系统正在放缓。 那么当我们看到CPU以100％的速度偷取的时候。
解决方法是更改为小实例types，这似乎不会进行限制或尝试其他托pipe服务，如Rackspace。
这个谜题的答案是重新编译ImageMagick并closuresOpenMP。 显然，这些线程都在争夺控制权，而进程切换完全是为了杀死性能。 重新编译后，一个ECU可以处理比打开OpenMP的16个ECU更多的请求。 惊人！