似乎理所当然地认为你不能将Webrick用作生产服务器,但我无法真正找到任何提及原因的地方.共识似乎是:"Webrick可以用于开发,但Thin或Unicorn是生产的选择,期限."
我确实查找了瘦服务器的主页,它讨论了请求/秒,但由于没有注释,我不太了解图形.
任何人都可以让我知道为什么我应该使用Thin或Unicorn与Webrick相比？使用Webrick进行开发也有什么好处？我一直在使用Webrick,因为它带有rails,我认为它应该是默认的原因.
顺便说一下,我正在使用Heroku.
一个Rails 3.2.0应用程序,可与本地和Heroku雪松堆栈上的瘦Web服务器一起使用.
后:
$ git branch work
$ git checkout work
$ rails server
我明白了:
=> Booting Thin
=> Rails 3.2.0 application starting in development on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
>> Thin web server (v1.3.1 codename Triple Espresso)
>> Maximum connections set to 1024
>> Listening on 0.0.0.0:3000, CTRL+C to stop
Exiting
/Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/eventmachine-0.12.10/lib/eventmachine.rb:572:in `start_tcp_server': no acceptor (RuntimeError)
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/eventmachine-0.12.10/lib/eventmachine.rb:572:in `start_server'
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/thin-1.3.1/lib/thin/backends/tcp_server.rb:16:in `connect'
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/thin-1.3.1/lib/thin/backends/base.rb:53:in `block in start'
from /Users/peter/.rvm/gems/ruby-1.9.3-p125/gems/eventmachine-0.12.10/lib/eventmachine.rb:256:in `call'
from …我试图使用Thin app服务器并遇到一个问题.
当nginx 代理使用proxy_pass http://my_app_upstream;应用程序对Thin(或Unicorn)的请求接收由nginx(http://my_app_upstream)发送的修改后的URL .
我想要的是从客户端传递原始URL和原始请求而不进行任何修改,因为应用程序非常依赖它.
nginx的" DOC说:
如果需要以未处理的形式传输URI,则应使用指令proxy_pass而不使用URI部分.
但我不明白如何配置,因为相关的示例实际上使用URI:
location /some/path/ {
proxy_pass http://127.0.0.1;
}
那么请你帮我弄清楚如何保留客户端的原始请求URL？
我无法在Windows上安装薄宝石.在构建本机扩展时会发生一些事情.
有人面临同样的问题吗？
这是堆栈跟踪:
>gem install thin --no-ri --no-rdoc
Temporarily enhancing PATH to include DevKit...
Building native extensions. This could take a while...
ERROR: Error installing thin:
ERROR: Failed to build gem native extension.
C:/Ruby/bin/ruby.exe extconf.rb
checking for rb_trap_immediate in ruby.h,rubysig.h... no
checking for rb_thread_blocking_region()... yes
checking for inotify_init() in sys/inotify.h... no
checking for __NR_inotify_init in sys/syscall.h... no
checking for writev() in sys/uio.h... no
checking for rb_thread_check_ints()... yes
checking for rb_time_new()... yes
checking for windows.h... yes
checking for winsock.h... yes
checking …我最近将我的应用程序'升级'到了heroku上的雪松平台.默认情况下,我thin用作Web服务器.但我总是试图unicorn用于并发和让我的dyno美元成为父亲.但是我担心使用Thin以外的东西会有一些问题.
有没有人有这个决定的真实生活经历？
谢谢!
乔纳森
笔记:
我想知道为什么每个人都不应该这样做
我最近发现有些人更喜欢使用unicorn_rails默认的WEBrick作为Web服务器来开发Rails应用程序.
我知道如果我想在生产中使用独角兽,那么在开发中尝试它是有道理的,但由于配置在生产中是不同的,它甚至是相关的吗？
使用thin或unicorn代替WEBrick开发Rails应用程序(例如速度或其他一些功能),是否有任何真正的,有形的优势？或者这仅仅是个人偏好的问题？
我们正在开发一个需要利用html5 websockets的Ruby on Rails应用程序.目前,我们有两个单独的"服务器"可以这么说:我们主要应用上的nginx +客运运行,并使用PRATIK奈克的一个单独的服务器抽筋框架(这是上运行薄)来处理WebSocket连接.
理想的情况是,当谈到时间进行部署,我们不得不对nginx的+乘客运行Rails应用程序,和WebSocket的服务器将背后nginx的被代理,所以我们不会需要有一个不同的端口上运行的WebSocket伺服器.
问题是,在这种设置中,似乎nginx过早地关闭了与Thin的连接.已成功建立与瘦服务器的连接,然后立即关闭200响应代码.我们的猜测是nginx没有意识到客户端正试图为websocket流量建立一个长期运行的连接.
不可否认,我对nginx配置并不是那么精明,所以,甚至可以配置nginx作为websocket服务器的反向代理吗？或者我是否必须等待nginx为新的websocket握手提供支持？假设让app服务器和websocket服务器都在端口80上监听是一个要求,那么这可能意味着我必须在没有nginx的单独服务器上运行Thin吗？
提前感谢任何建议或意见.:)
-约翰
我试图完全理解Rack中并发请求处理的选项.我已经使用async_sinatra来构建一个长轮询应用程序,现在正在尝试使用裸机Rack throw :async和/或Thin的--threaded标志.我对这个问题很满意,但有一些我无法理解的事情.(不,我并不误解并发性的并发性,是的,我确实理解GIL施加的限制).
Q1.我的测试表明thin --threaded(即rack.multithread=true)在不同的线程中同时运行请求(我假设使用EM),这意味着长时间运行的请求A不会阻止请求B(IO旁边).这意味着我的应用程序不需要任何特殊编码(例如回调)来实现并发(同样,忽略阻塞DB调用,IO等).这是我相信我观察到的 - 这是正确的吗？
Q2.还有另一种更常见的实现并发的方法,涉及EventMachine.defer和throw :async.严格来说,不使用线程处理请求.它们是按顺序处理的,但是将它们的繁重工作和回调传递给EventMachine,后者使用async.callback在稍后发送响应.请求A已将其工作卸载到EM.defer后,请求B开始.它是否正确？
Q3.假设上述方法或多或少是正确的,那么一种方法对另一种方法有什么特别的优势吗？显然--threaded看起来像一个魔术子弹.有什么缺点吗？如果没有,为什么每个人都在谈论async_sinatra/ throw :async/ async.callback？也许前者是"我想让我的Rails应用程序在繁重的负载下变得更加快速",而后者更适合具有许多长时间运行请求的应用程序？或者规模是一个因素？只是在这里猜测.
我在MRI Ruby 1.9.2上运行Thin 1.2.11.(仅供参考,我必须使用该--no-epoll标志,因为EventMachine使用epoll和Ruby 1.9.2 存在一个长期的,据称解决但不是真正的问题.这不是重点,但任何见解都是受欢迎的.)
我一直thin -V start在开发Thin .
但是,我希望Thin是默认值而不是WEBrick,并且能够启动它rails s.
有没有办法在Rails 3中将Thin设置为默认值而不是WEBrick？
如果那是不可能的,那么至少有一种方法可以自动在测试环境中启动它吗？
只是想让人们对使用Unicorn vs Thin作为rails服务器的意见.我在网上发现的大多数文章/基准看起来都很不完整,所以有一个集中的地方讨论它会很好.
Unicron是一个多进程服务器,而thin是基于事件/非阻塞的服务器.基于事件的服务器非常棒......如果您的代码是异步/非阻塞的,那么vanilla rails就会阻塞.因此,除非您使用非阻塞的rails库,否则我真的看不到使用Thin的优势.更糟糕的是,在非阻塞服务器中,如果您的I/O循环阻塞,您将阻止整个循环,并且在阻塞调用返回之前无法处理任何更多请求.阻止库会减慢速度!
为什么Heroku选择Thin作为他们的默认服务器(雪松)？他们是聪明人,所以我相信他们有理由.
贝娄是一个链接,建议用4名Unicorn工人取代Thin - 这对我来说非常有意义. Heroku上的4名Unicron工作人员