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:

웹 사이트 : 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에서는 보석도 작동 하지 mongrel않았고 thin소스에서 컴파일하는 데 몰두할 방법이 없었기 때문에 WEBrick을 고수해야했습니다.

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

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

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

또한 레일 용 웹 서버 목록을 확인할 수 있습니다 .

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

출처 보기

이것은 :DoNotReverseLookup로컬 개발 가상 머신 에서 문제를 해결하는 데 도움이 되었고 추가 정보를 추가하고 싶었던 오래된 질문 및 답변 스레드입니다 . 이 웹 페이지는 일부 사람들에게이 문제를 일으키는 Ruby 코어 의 회귀 오류 를 설명합니다 . 강조는 내 것입니다. 이 모든 것의 긴 단점은 이것에 대한 Ruby 핵심 수정에 대한 GitHub 풀 요청이 있으며 곧 Ruby 릴리스에서 승인되고 병합되기를 바랍니다.

몇 시간의 문제 해결 후 문제가 해결되었습니다! 분명히 Ruby의 표준 lib가 1.8.6에서 2.0.0으로 진화하면서 WEBrick은 기본적으로 :DoNotReverseLookup설정 되는 새로운 구성 옵션 을 얻었습니다 nil. 그런 다음 WEBrick의 요청 처리 코드 내부 do_not_reverse_lookup에서 들어오는 연결 소켓 인스턴스 의 플래그를 값으로 설정 config[:DoNotReverseLookup]합니다. 이 값은 nil이며 이는 거짓이므로이 값을 로 설정하는 것과 동일 false하며 전역 Socket.do_not_reverse_lookup플래그를 재정의합니다 . 따라서 다음이없는 경우 : DoNotReverseLookup => trueWEBrick 구성에서 새 연결마다 역방향 DNS 조회가 항상 발생하여 잠재적으로 심각한 대기 시간이 발생할 수 있습니다.

이 발견과 관련된 것은 Ruby WEBrick 소스 코드에서 문제를 복구하는 방법을 제안하는 작성자의 GitHub pull 요청입니다. WEBrick의 : DoNotReverseLookup 구성 옵션 구현 # 731에서 회귀 버그 수정

요청에 설명 된 해결책은 다음과 같이 181 행을 변경 lib/webrick/server.rb하는 것입니다.

sock.do_not_reverse_lookup = config[:DoNotReverseLookup]

이에:

unless config[:DoNotReverseLookup].nil?

누군가가이 잘 알려진 질문 / 답변 스레드를 우연히 발견하고 Ruby 코어에서이 문제를 해결하는 과정에 관심이 있다면 여기에서 공유하십시오. 이 풀이 합쳐 지거나 근본적인 문제가 다음 Ruby 릴리스에서 어떤 방식 으로든 처리되기를 바랍니다. 어쩌면 2.1.6?

이것은 매우 늦은 답변이지만 Vagrant에서 실행되는 Rails 로이 문제를 디버깅하는 데 하루 중 많은 시간을 보냈습니다. 역방향 DNS 조회를 변경해도 실제로 요청 시간이 전혀 개선되지는 않았습니다. 두 가지의 조합으로 개발 모드에서 페이지로드 시간이 20 초에서 3 초로 늘어났습니다.

WEBrick을 잡종으로 바꿉니다. 시험판 버전을 사용해야했거나 설치되지 않았습니다.

sudo gem install mongrel --pre

그런 다음 dev 용 Gemfile에 추가합니다.

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

다음과 같이 내 서버를 시작했습니다.

rails server mongrel -e development

그것은 몇 초, 5 또는 6 초를 줄 였지만 여전히 매우 느 렸습니다. 이것은 케이크의 장식이었습니다 -이것도 Gemfile에 추가하십시오 :

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

DoNotReverseLookupruby 1.8.x webrick 에는 옵션 이 없습니다 . 해결책은 다음과 같습니다.

Socket.do_not_reverse_lookup = true

스크립트 시작 어딘가에.

출처 : WEBrick and Socket.do_not_reverse_lookup : A Tale in Two Acts

내에서 아마 드문 상황, 내가 내 iptables에 플러시 후 나는 사용자 정의 규칙 (단지 기본 우분투는 모두 허용)을 가지고 있지 않았기 때문에,이 부작용이 없었했다 :

sudo iptables -F