88

サーバーで実行しているRailsアプリケーションがあります。リモート デスクトップに移動してアプリケーションをロードしようとすると、サーバーが単純な HTML ページで応答するのに 3 ～ 4 分かかります。ただし、サーバー上でローカルにページをロードすると、ページはわずか 1 秒で表示されます。リモート デスクトップからサーバーに ping を実行しようとしましたが、妥当な時間内に ping が成功しました。

これはすべて、Oracle の基本クライアントと SQLPLUS をインストールした後に始まったようです。オラクルを疑うべきですか？誰もこれに似たようなことを経験しましたか?

4

12 に答える 12

139

ここでも同じ問題があります（1年後でも）。Linux では、次のことを行う必要があります。

ファイル /usr/lib/ruby/1.9.1/webrick/config.rb を探して編集します。

ラインを交換する

:DoNotReverseLookup => nil,

と

:DoNotReverseLookup => true,

Webrick を再起動すると、魅力的に動作します :)

于 2010-08-12T06:12:02.960 に答える
36

同じ問題がありました。私にとって、この投稿は解決策を保持していました。Ubuntu を使用している場合は、avahi-daemon. service avahi-daemon stopデーモンを停止します。

Webrick が非常にスピーディーに感じられるようになりました。

この問題はRails Lighthouseに古いレポートがありますが、Ruby-on-Rails はそれ以降、チケットを github に移動しました。この古い問題がまだ残っているのはちょっと残念です。

ただし、ネットワーク上のプリンターやスキャナーを見つけるなど、実際に何かに使用すると、機能しなくなることに注意してください。 avahi-daemon

于 2011-08-12T09:25:04.380 に答える
23

ちょうど同じ問題がありました。の

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

私のためにもトリックをしました。rvm の下で Ruby を実行している場合に備えて、次のパスを使用します。

~/.rvm/rubies/ruby-<version>/lib/ruby/<version>/webrick/config.rb
于 2011-02-04T14:41:23.133 に答える
15

「シン」は、両方をローカルで実行するための優れたオプションになりましたそして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 などの並行 Web バックエンドに切り替えます。これにより、dyno が独自のリクエスト キューを管理し、長いリクエストでのブロックを回避できます。

于 2012-07-07T00:04:48.740 に答える
6

VPN経由でWEBrickサーバーにアクセスすると、漠然と同様の問題が発生しました。リクエストには長い時間がかかりますが、そのほとんどはネットワーク上で何も起こらない状態です。Windows上のRuby1.9mongrelでもthingemも動作せず、ソースからのコンパイルに巻き込まれる方法がなかったため、WEBrickを使い続ける必要がありました。

修正は、WEBrickサーバーを作成するときにconfigパラメーターDoNotReverseLookupをに設定することでした。true

server = HTTPServer.new {:DoNotReverseLookup => true, ...}
于 2010-03-11T11:32:44.047 に答える
5

を使用ApacheまたはインストールできますThin。あなたのGemfileで：gem 'thin'

また、railsのWebサーバーのリストを確認することもできます。

于 2012-09-29T10:17:12.537 に答える
2

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

ソースを見る

于 2014-06-03T11:07:45.043 に答える
2

1.8.7 の webrick でこれを実行しようとしましたが、変更する構成が見つかりませんでした。ただし、使用できるチートは、webrick を実行しているサーバーのホスト ファイルに、逆引きしようとしている IP アドレスを追加することです。

于 2011-08-13T02:03:51.140 に答える
1

:DoNotReverseLookupこれは、ローカル開発仮想マシンの問題を解決するのに役立ち、追加情報を追加したいと思った古い質問と回答のスレッドです。この Web ページでは、この問題が発生する原因となった Ruby コアのリグレッション エラーについて説明しています。強調は私のものです。要するに、これに対する Ruby コアの修正を求める GitHub プル リクエストがあり、これが承認されてすぐにリリースされる Ruby にマージされることを願っています。

数時間のトラブルシューティングの後、そうであることが判明しました。どうやら、Ruby の標準ライブラリが 1.8.6 から 2.0.0 に進化する過程のどこかで、WEBrick はデフォルト:DoNotReverseLookupで設定されている新しい構成オプションを獲得したようnilです。次に、WEBrick のリクエスト処理コードの奥深くで do_not_reverse_lookup、着信接続ソケット インスタンスのフラグを の値に設定しconfig[:DoNotReverseLookup]ます。この値はであるため、これは誤りであり、グローバルフラグをオーバーライドしnilて に設定した場合と同じ効果があります。そのため、WEBrick 構成に : がない限り、新しい接続ごとに逆引き DNS ルックアップが常に発生し、重大な遅延が発生する可能性があります。falseSocket.do_not_reverse_lookupDoNotReverseLookup => true

この発見に関連して、Ruby WEBrick ソース コードの問題を修復する方法を提案している著者からの GitHub プル リクエストがあります。

リクエストに記載されている解決策は、181 行目を次のように変更することlib/webrick/server.rbです。

sock.do_not_reverse_lookup = config[:DoNotReverseLookup]

これに：

unless config[:DoNotReverseLookup].nil?

このよく知られた質疑応答スレッドに出くわし、Ruby コアでこの問題を解決するための進歩に興味がある人は、ここで共有してください。このプルがマージされるか、根本的な問題が Ruby の次のリリースで何らかの方法で処理されることを願っています。たぶん2.1.6？

于 2014-12-13T03:55:22.303 に答える