小编Ash*_*sta的帖子

我的Rails应用程序必须进行大量的外部http调用.有时,冗余的http调用来处理请求.所以,我正在寻找一种缓存外部http调用的方法.应该使用内存来保存缓存数据的方式.请帮忙.

我正在尝试使用httperf加载测试我的Rails(3.2.13)应用程序.它对于不需要cookie的页面非常有效.但是,我无法使它适用于需要cookie的页面.我正在使用Gregg Pollack的httperf(https://github.com/Gregg/httperf_big_cookies),因为正式版不支持大cookie.

这是我使用的命令:

httperf --session-cookie --wsesslog=1,5,path.txt --rate=1 --timeout=15 --server=localhost --port=3000

而且,这是path.txt文件:

    /log_in
    /sessions method=POST contents='utf8=?&remember_me=1&commit=Login&email=john@widgetsco.com&password=password'

该cookies方法始终返回nil控制器内部.

所以,请建议我如何克服问题或更好的工具(基于控制台)来测试铁路应用的负载.

我使用 Puma 作为 MRI 2.1.0 上的 Rails 4 项目的应用程序服务器。我正在使用 Capistrano 3 来处理部署。一切都像魅力一样运转。但是，我最近注意到我的部署过程存在问题。如果我更改 Gemfile，puma 将无法完成分阶段重启，最终所有工作人员都会被杀死。我在集群模式下运行 Puma 并且preload_app!设置为 true。

这是我处理分阶段重启的 Capistrano 配方。

desc "Restart the application (phased restart)"
task :phased_restart do
  on roles(:app) do |h|
    execute "cd #{fetch(:current_path)} && bundle exec pumactl -S #{fetch(:puma_state)}     phased-restart", :pty => true
  end
end

这是 Capistrano 日志的截断输出。

DEBUG [4790766f] Command: cd /home/app/current && bundle exec pumactl -S /home/app/shared/tmp/pids/puma.state phased-restart
DEBUG [de00176a]    Command phased-restart sent success
 INFO [de00176a] Finished in 0.909 seconds with exit status …

我正在从具有 300GB 根卷的数据库服务器烘焙 AMI。80% 的容量正在使用中。烘焙 AMI 背后的原因是我们每天需要多个具有完全相同数据的新实例。AMI 是合适的解决方案，因为恢复过程非常缓慢。因此创建实例后无法启动数据恢复过程。我们希望实例在 7-8 分钟内准备好所有数据。

但是，新实例中的性能非常差。其背后的原因是实例使用 EBS 并且需要按照本文档中的描述进行初始化。

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-initialize.html

不幸的是，初始化过程需要 5-6 小时，这对我们来说不是一个解决方案。

那么，当 AMI 中需要的底层数据非常大时，烘焙 AMI 的最佳实践是什么？