Webrick은 반응이 매우 느리다.어떻게 하면 빨라요?

Webrick은 반응이 매우 느리다.어떻게 하면 빨라요?

서버에서 실행 중인 Rails 응용 프로그램이 있습니다.리모트 데스크톱으로 이동하여 애플리케이션을 로드하려고 하면 서버는 간단한 HTML 페이지로 응답하는 데 3~4분 정도 걸립니다.그러나 서버에 로컬로 페이지를 로드하면 순식간에 페이지가 나타납니다.리모트 데스크톱에서 서버에 ping을 실행해 봤는데 ping이 정상적으로 종료되었습니다.

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

같은 문제를 안고 있다(1년 후에도).Linux에서 다음을 수행해야 합니다.

/usr/lib/ruby/1.9.1/webrick/config.rb 파일을 찾아 편집합니다.

회선을 바꿉니다.

:DoNotReverseLookup => nil,

와 함께

:DoNotReverseLookup => true,

webrick을 재기동하면 마법처럼 동작합니다:)

같은 문제가 있었어.저는 이 게시물이 해결책을 제시했습니다.Ubuntu에 있는 경우,avahi-daemonservice 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

"씬"은 이제 로컬 및 Heroku에서 모두 실행할 수 있는 훌륭한 옵션입니다.

Heroku에 대해서:

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

Gemfile을 넣으면 로컬에서 사용할 수 있습니다.

gem "thin"

thin start ★★★★★★★★★★★★★★★★★」rails s.

Heroku 업데이트

이제 헤로쿠에게는 얇은 것이 좋지 않은 선택으로 여겨진다.자세한 내용은 이쪽:

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

권장 사항:

JRuby의 Unicon이나 Puma 등의 동시 웹 백엔드로 전환합니다.이를 통해 dyno는 자체 요청 큐를 관리하고 긴 요청의 블로킹을 방지할 수 있습니다.

VPN 경유로 WEBrick 서버에 액세스 할 때 나타나는 비슷한 문제가 있었습니다.요청은 시간이 오래 걸리고 대부분 유선상에서 아무 일도 일어나지 않습니다. 쪽도 아니기 때문에mongrel 않다thinWindows®Ruby19와 연동되어 소스로부터의 컴파일에 관여할 수 없었습니다.WEBRICK web web web web web web web web web web web web 。

수정은 파라미터의 config를 이었습니다.DoNotReverseLookup로로 합니다.trueWEBrick 버 web :

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

하시면 됩니다.Apache 「」를 인스톨 합니다.Thin: .Gemfile :gem 'thin'

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

1.8.7에서 webrick을 사용하여 이 작업을 수행하려고 했지만 변경할 설정을 찾을 수 없었습니다.단, WEBRICK을 실행하고 있는 서버의 호스트파일에 리버스 룩업을 시도하고 있는IP 주소를 추가하는 경우는, 치트를 사용할 수 있습니다.

시나트라에서는 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 core의 회귀 오류를 설명하고 있습니다.중요한 점은 여기에 대한 Ruby 코어 수정에 대한 GitHub의 풀 요청이 있다는 것입니다.그리고 곧 출시될 Ruby에서 승인되고 병합되기를 희망합니다.

몇 시간 동안 트러블 슈팅을 실시한 결과, 그것이 판명되었습니다.1.에서 2.0은 새로운 인 "lib" 1.8.6" 2.0.0"을 :DoNotReverseLookup로 nil 속 깊은 WEBrick의 요청 처리 코드인 'WEBrick', 'WEBrick', 'WEBrick'을 합니다.do_not_reverse_lookup를 "Discription"의 으로 설정합니다.config[:DoNotReverseLookup]이 값은 거짓이므로 글로벌플래그를 덮어쓰고 로 설정하는 것과 같은 효과가 있습니다. 따라서 WEBrick Configuration에 DoNotReverseLookup => true:가 없는 한 새로운 접속마다 항상 역방향 DNS 룩업이 실행되므로 심각한 지연이 발생할 수 있습니다.

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

이 요구에서 개략적으로 설명한 솔루션은 의 181 행을 변경하는 것입니다.lib/webrick/server.rb여기서부터:

sock.do_not_reverse_lookup = config[:DoNotReverseLookup]

이를 위해:

unless config[:DoNotReverseLookup].nil?

이 잘 평가된 질문/답변 스레드에 대해 고민하고 Ruby core에서 이 문제를 해결하기 위한 진척에 관심이 있는 사람이 있다면 여기에서 공유합니다.이 풀(pull)이 통합되거나 루비의 다음 릴리스에서 근본적인 문제가 어떤 식으로든 처리되기를 바랍니다. 2.1.6은 어떨까요?

이것은 매우 늦은 답변이지만, 저는 Vagrant에서 실행되는 Rails에 대한 바로 이 문제를 디버깅하는 데 하루의 많은 시간을 보냈습니다.역방향 DNS 조회를 변경해도 실제로 요청 시간이 전혀 개선되지 않았습니다.개발 모드에서 페이지 로딩 시간이 최대 20초에서 최대 3초까지 걸렸습니다.

WEBRIC을 mongrel로 바꿉니다.프리리스 버전을 사용해야 하는데 설치가 되지 않습니다.

sudo gem install mongrel --pre

그런 다음 개발용 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

거기에는 없다DoNotReverseLookup루비 1.8.x webrick 옵션입니다.해결책은 다음과 같습니다.

Socket.do_not_reverse_lookup = true

대본의 시작 부분 어디쯤에서.

출처: WEBrick 및 Socket.do_not_displays_displays: 2막의 이야기.

드문 경우지만 iptables를 플래시한 후 동작했습니다.커스텀 규칙이 없었기 때문에 부작용은 없었습니다(기본 Ubuntu에서는 모든 것이 허용됩니다).

sudo iptables -F

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