Connection sharing

[sferik]

Now that v0.6.0 has shipped, I’ve started benchmarking the http branch of the twitter gem against master, which uses Faraday with Net::HTTP.

While the spec suite runs about 4X faster in the http branch, the following real-world example—which outputs the screen names of my Twitter friends that start and end with the letter “a”—performs about 2X slower (5 seconds vs. 10 seconds).

require 'twitter'

client = Twitter::REST::Client.new(consumer_key: 'abc', consumer_secret: '123')
client.friend_ids('sferik').each_slice(100) do |slice|
  client.users(slice).select { |u| u.screen_name.match(/^a\w*a$/i) }.each do |user|
    puts user.screen_name
  end
end

When I run:

ruby-prof examples/aa_friends.rb --mode=wall --sort=self --min_percent=1

It produces the following output:

 %self      total      self      wait     child     calls  name
 60.58     10.089    10.089     0.000     0.000      189   OpenSSL::SSL::SSLSocket#sysread 
 25.86      4.306     4.306     0.000     0.000        6   OpenSSL::SSL::SSLSocket#connect 
 11.91      1.983     1.983     0.000     0.000        6   TCPSocket#initialize 

As you can see, I’m initializing a new TCP socket and calling connect for each HTTP request, which takes about a second per request. In the master branch, I’m able to share a single HTTP connection across multiple request, which explains why it’s about 5 seconds faster.

How can I share a single connection across multiple HTTP requests with the HTTP gem? Without this feature, I won’t be able to replace faraday with http in the twitter gem. 😦

[ixti]

This depends on #72 and adding of Connection: Keep-Alive support.

[tarcieri]

I had planned to add connection pools ala Net::HTTP::Persistent as well.

@sferik is this the sort of thing you're after?

https://github.com/drbrain/net-http-persistent

[ghost]

not "needed" atm but having something like net-http-persistent in http would give me one more reason to not depend on net/http if i needed to re-use the same socket.

[sferik]

@tarcieri Yes, I’m looking for something functionally similar to net-http-persistent, however, I’m not such a fan of the interface, which reminds me of Net::HTTP. Have you thought about what the HTTP gem’s interface for persistent connections might look like?

[ghost]

imho something like HTTP.persistent("https://www.google.com").get("/foo").get("/bar") could be nice.

[sferik]

@johnny5- I need to be able to make separate, unchained requests using the same connection object, so this would need to work:

connection = HTTP.persistent("https://www.google.com")
connection.get("/foo")
connection.get("/bar")

[ghost]

there's no reason it couldn't work with my example and yours.

[ghost]

i think it would mean response's would end up being stacked in connection though and im not sure if that's good.

[sferik]

@johnny5- I just wanted to make sure it doesn’t require chaining the requests in a single statement.

[ghost]

supporting both might be odd, .get() could return a response that could proxy another .get() through to the same connection object, to implement chaining, but i think it's better if people more familiar with the code weigh in.

[ixti]

I'm totally opposed to idea of proxy objects. IMHO it's confusing magic. Why one would need to call get() without getting response? I imagine API to be something like this:

client = HTTP.persisted # => HTTP::Client::Persisted

users  = client.get("http://example.com/users.json")
groups = client.get("http://example.com/groups.json")

Persisted client will hold connection pool internally, so if one didn't flushed connection before making another one (above) it will create another connection. Once it will have more than one open (and fully flushed) connection to same host, it will close all superfluous ones. Also, if you will get different host - it will add another persisted connection to the pool. Persistence pool will be configurable (total size, per-host size, auto-flush upon next request).

Clarification on "if one didn't flushed connection before":

client = HTTP.persisted # => HTTP::Client::Persisted

# 0 open connections

puts client.get("http://example.com/users.json").to_s
puts client.get("http://example.com/users.json").to_s

# 1 open connection

resources = %w[users groups persmissions].map do |res|
  client.get "http://example.com/#{res}.json"
end

# 3 open connections

resources.each { |r| r.to_s }

# 1 open connection

client.get("http://foobar.com/users.json").to_s

# 2 open connections

[tarcieri]

My ideal API would be transparent... that each HTTP::Client would hold a pool of HTTP::Connection objects per origin (perhaps with a toggle to use a pool or not). I'd define an origin as a tuple of:

[(:http|:https), hostname, port]

[ghost]

i totally agree a proxy on a response back to the original connection would be confusing as hell :)

[sferik]

Resolved via #184.

[sferik]

Hmmm…trying to move this issue into the v0.8.0 milestone but I’m getting an error. Maybe it’s related to the denial of service GitHub was facing earlier today? Anyway, this feature should be released in v0.8.0.

[sferik]

@tarcieri @ixti Are you able to change the milestone to v0.8.0?

[tarcieri]

@sferik GitHub is giving me an error when I try to do that o_O

[sferik]

@tarcieri Me too. I thought it might be a permissions thing. Let’s remember to try again when GitHub isn’t under attack. I’d guess they’ve temporarily disabled some non-critical services like reassigning milestones.

[ixti]

I found the workaround to assign milestones :D via issues index not from particular issue...

[sferik]

@ixti 👍