Webrick은 응답 속도가 매우 느립니다.

Webrick은 응답 속도가 매우 느립니다. 속도를 높이는 방법?

---

내 서버에서 실행중인 Rails 애플리케이션이 있습니다. 원격 데스크톱으로 이동하여 애플리케이션을로드하려고하면 서버가 간단한 HTML 페이지로 응답하는 데 3-4 분 정도 걸립니다. 그러나 서버에서 로컬로 페이지를로드하면 페이지가 1 초만에 나타납니다. 원격 데스크톱에서 서버에 ping을 시도했는데 ping이 적절한 시간 내에 성공적으로 진행됩니다.

이 모든 것은 Oracle의 기본 클라이언트와 SQLPLUS를 설치 한 후에 시작된 것 같습니다. 오라클을 의심해야합니까? 이와 비슷한 경험을 한 사람이 있습니까?

---

여기에 동일한 문제가 있습니다 (심지어 1 년 후). Linux에서는 다음을 수행해야합니다.

/usr/lib/ruby/1.9.1/webrick/config.rb 파일을 찾아서 편집하십시오.

라인 교체

:DoNotReverseLookup => nil,

와

:DoNotReverseLookup => true,

webrick을 다시 시작하면 매력처럼 작동합니다. :)

---

같은 문제가있었습니다. 저에게는 이 게시물 이 해결책을 제시했습니다. Ubuntu를 사용중인 경우 avahi-daemon. service avahi-daemon stop데몬을 중지합니다.

Webrick은 이제 매우 빠르게 느낍니다 .

문제는 Rails Lighthouse 의 오래된 보고서가 있지만 Ruby-on-Rails는 그 이후로 티켓을 github 로 옮겼 습니다 . 이 오래된 문제가 여전히 지속되는 것은 불행한 일입니다.

그러나 네트워크에서 프린터 및 스캐너 를 찾는 것과 같이 실제로 사용 하는 경우 더 이상 작동하지 않습니다.avahi-daemon

---

같은 문제가있었습니다. 그만큼

...
:DoNotReverseLookup => true,
...

나도 속임수를 썼다. rvm에서 루비를 실행하는 경우를 대비하여 다음 경로로 이동할 수 있습니다.

~/.rvm/rubies/ruby-<version>/lib/ruby/<version>/webrick/config.rb

---

"Thin"은 이제 로컬에서 둘 다 실행할 수있는 훌륭한 옵션입니다. 그리고 Heroku:

Heroku : https://devcenter.heroku.com/articles/rails3#webserver

웹 사이트 : http://code.macournoyer.com/thin/

Gemfile에 넣어 로컬에서 사용할 수 있습니다.

gem "thin"

... 그런 다음 bundle을 실행하고 thin start또는으로 서버를 시작합니다 rails s.

Heroku 업데이트

Thin은 이제 Heroku 에게 나쁜 선택으로 간주됩니다 . 여기에 더 많은 정보 :

https://blog.heroku.com/archives/2013/4/3/routing_and_web_performance_on_heroku_a_faq

그들의 추천 :

JRuby에서 Unicorn 또는 Puma와 같은 동시 웹 백엔드로 전환하면 dyno가 자체 요청 대기열을 관리하고 긴 요청에 대한 차단을 방지 할 수 있습니다.

---

VPN을 통해 WEBrick 서버에 액세스 할 때 나타나는 모호한 유사한 문제가있었습니다. 요청은 오랜 시간이 걸리며 대부분은 아무 일도 일어나지 않습니다. Windows의 Ruby1.9에서는 gem도 작동 하지 mongrel않았고 thin소스에서 컴파일하는 데 몰두할 방법이 없었기 때문에 WEBrick을 고수해야했습니다.

수정은 WEBrick 서버를 만들 때 config 매개 변수 DoNotReverseLookup를 로 설정하는 것입니다 true.

server = HTTPServer.new {:DoNotReverseLookup => true, ...}

---

을 사용 Apache하거나 설치할 수 있습니다 Thin. Gemfile에서 :gem 'thin'

또는 rails 용 웹 서버 목록을 확인할 수 있습니다 .

---

1.8.7에서 webrick으로 이것을 시도했지만 변경할 구성을 찾을 수 없습니다. 그러나 사용할 수있는 치트는 webrick을 실행하는 서버의 호스트 파일에 역방향 조회를 시도하는 IP 주소를 추가하는 것입니다.

---

Sinatra에서 자주 10 초 지연을 경험했습니다. 이 스 니펫은 나를 위해 그것을 해결했습니다.

app.rb파일 상단 근처에 추가

class Rack::Handler::WEBrick
    class << self
        alias_method :run_original, :run
    end
    def self.run(app, options={})
        options[:DoNotReverseLookup] = true
        run_original(app, options)
    end
end

출처 보기

---

This is an old question and answer thread that helped me solve the :DoNotReverseLookup issue on a local development virtual machine and wanted to add additional info. This web page explains the regression error in Ruby core that lead to this issue appearing for some; emphasis is mine; the long an short of all of this is there is a GitHub pull request for a Ruby core fix to this and hopefully it will be approved and merged in a soon-ish release of Ruby:

After a few hours of troubleshooting, it turned out that it was! Apparently, somewhere along the evolution of Ruby's standard lib from 1.8.6 to 2.0.0, WEBrick acquired a new configuration option :DoNotReverseLookup that is set to nil by default. Then, deep in the guts of WEBrick's request processing code, it sets the do_not_reverse_lookup flag on the incoming connection socket instance to the value of config[:DoNotReverseLookup]. Since this value is nil, which is falsy, the effect is the same as setting it to false, overriding the global Socket.do_not_reverse_lookup flag. So, unless you have :DoNotReverseLookup => true in your WEBrick config, reverse DNS lookup will always happen for each new connection, potentially causing serious latency.

Related to this discovery is a GitHub pull request from the author proposing how to repair the issue in the Ruby WEBrick source code: Fix regression bug in WEBrick's :DoNotReverseLookup config option implementation #731

The solution as outlined in the request is to change line 181 in lib/webrick/server.rb from this:

sock.do_not_reverse_lookup = config[:DoNotReverseLookup]

To this:

unless config[:DoNotReverseLookup].nil?

Sharing here if anyone stumbles over this well regarded question/answer thread and are interested in the progress in solving this issue in Ruby core. Hopefully this pull will be merged or the underlying issue be dealt with in some way in the next release of Ruby; maybe 2.1.6?

---

This is a very late answer but I spent a good part of the day debugging this very issue with Rails running on Vagrant. Changing the reverse DNS lookup didn't actually improve request times at all. A combination of two things took my page load from ~20 seconds to ~3 seconds in development mode:

Replace WEBrick with mongrel. I had to use the prerelease version or it wouldn't install:

sudo gem install mongrel --pre

Then add it to my Gemfile for dev:

group :test, :development do
  gem 'mongrel'
end

Started my server like this then:

rails server mongrel -e development

That cut a few seconds off, 5 or 6 seconds, but it was still terribly slow. This was the icing on the cake - add this as well to the Gemfile:

group :development do
  gem 'rails-dev-boost', :git => 'git://github.com/thedarkone/rails-dev-boost.git'
end

---

There is no DoNotReverseLookup option in ruby 1.8.x webrick. The solution is to put:

Socket.do_not_reverse_lookup = true

somewhere at the beginning of your script.

Source: WEBrick and Socket.do_not_reverse_lookup: A Tale in Two Acts

---

In my probably rare situation, it worked after I flushed my iptables, this didn't have any side effects because I didn't have any custom rules (just the default Ubuntu allow all):

sudo iptables -F

참고URL : https://stackoverflow.com/questions/1156759/webrick-is-very-slow-to-respond-how-to-speed-it-up