ADMIN PINGとは - CubicLouve

checkout_and_verifyの中で、AR::ConnectionAdapters::AbstractAdapter#verify!を呼び出して、取ってきたobejctの中のMySQLサーバーのコネクションが生きているかを確認し、もし死んでたら、MySQLサーバーへのコネクションを貼り直します。

veryfy! https://github.com/rails/rails/blob/v4.2.6/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb#L327

この中で、active?が呼ばれて最終的にpingが飛びます。

ADMIN PINGを抑制するために

AR::ConnectionAdapters::AbstractAdapter#verify!で何もしないようにする

def verify!(*ignored)
  reconnect! unless active? # ここを削除する
end

このveryfy!はconnection_pool経由でobjectを取って来た際に、objectは存在するがMySQLとの接続が切れている可能性があるためにその確認をするためのメソッドかと思います。 (思わぬところでconnectionが切れている、idle状態でwait_timeout超える等々)。

APIはリクエスト毎にMySQLのコネクションを貼り直していることを前提にします。

1リクエスト内では、一度貼ったコネクションをもつobjectは AR::ConnectionAdapters::ConnectionPool#connectionの中で、@reserved_connections インスタンス変数に現在のスレッドのobject_idをキーにキャッシュされ、ここから利用されます。 (余談ですが、WEBrickはmulti threadなWEBサーバーです)

そうすると1リクエスト内で一度AR::ConnectionAdapters::ConnectionPool#connection経由でコネクションを貼ると、AR::ConnectionAdapters::ConnectionPool#checkoutまで到達しません。

なので、AR::ConnectionAdapters::ConnectionPool#checkoutに到達するのは、

最初の一回目でコネクションをはるとき or 1リクエストの中で@reserved_connectionsが開放され、かつARのコネクションプールが残っている場合

です。

最初の一回目はコネクションを貼った直後に切れていることはないと思うので、verify!を向こうにしてADMIN PINGを飛ばないようにしても問題なさそうです。

https://github.com/rails/rails/blob/v4.2.6/activerecord/lib/active_record/connection_adapters/abstract/connection_pool.rb#L347

      def checkout
        synchronize do
          conn = acquire_connection <- ここで貼ったコネクションが
          conn.lease
          checkout_and_verify(conn) <- この間で切れる場合にveryfy!の結果が効くがそんな刹那なタイミングで切れることはないかと
        end
      end

@reserved_connectionsが開放されARのコネクションプールが残っている場合において、生存確認がないとMySQL側でコネクションが切られているときにエラーになりますが、MySQLサーバーがコネクションを切る場合はreconnectしてもつながらない場合のほうが多いかなと。

このMySQLサーバーとのコネクションが切れているconnection objectを使って通信すると Lost connection to MySQL のエラーが即座に返ってくるので、詰まることはないと思います。