Quantcast

40ms performance hit over org.apache.http

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

40ms performance hit over org.apache.http

drew
Here are two methods I can switch between:

  def getDispatch(root: String, q: String): String = {
    new Http x (
      new Request(root) / "facetedSearch"
      <<? Map("q" -> q)
      as_str
    )
  }

  def getApache(root: String, q: String): String = {
    import org.apache.http.impl.client.DefaultHttpClient
    import org.apache.http.impl.client.BasicResponseHandler
    import org.apache.http.message.BasicHeader
    import org.apache.http.entity.StringEntity
    import org.apache.http.client.methods.HttpGet

    val client = new DefaultHttpClient() // doing this and the shutdown() adds about .5ms
    val method = new HttpGet(root + "/facetedSearch?q=" + java.net.URLEncoder.encode(q, "UTF-8"))
    val responseBody = client.execute(method, new BasicResponseHandler())
    client.getConnectionManager().shutdown()
    responseBody
  }

This code is itself a webserver, and I am timing it with ab. Requests are in series, and the payload being proxied is only 5kB. Here are the times:
Skip my proxy server and call the inner /facetedSearch service directly with ab: 6ms
Call the proxy server and have it use getApache: 8.6ms
Call the proxy server and have it use getDispatch: 55ms

I realize I could do less setup/teardown, and I could probably get http pipelining going to save some overhead, but even without those improvements, something is still very wrong. (If I reuse the Http object, the 55ms becomes 32ms.)

I'd like to keep using dispatch, but I'm having to port critical requests back to HttpClient unless someone knows a way to fix the slowdown.

JVM 1.6, Scala 2.8.1, outer webserver is the jetty inside sbt.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 40ms performance hit over org.apache.http

n8han
Administrator
Could you try using an InputStreamReader instead, to rule out scala.io.Source as the culprit?
https://github.com/n8han/Databinder-Dispatch/blob/master/core/src/main/scala/handlers.scala#L88

Other than that, the underlying request flow you have with Dispatch should not be so much different from the one you're doing with HttpClient directly. It is worth retaining the Http instance, and parts of the request definition that don't change, but that's not enough to explain the disparity.

This is the configuration of the client in Dispatch, if you want to take a look:
https://github.com/n8han/Databinder-Dispatch/blob/master/http/src/main/scala/ConfiguredHttpClient.scala

Nathan

On 07/19/2011 07:49 PM, Drew [via Databinder] wrote:
Here are two methods I can switch between:

  def getDispatch(root: String, q: String): String = {
    new Http x (
      new Request(root) / "facetedSearch"
      <<? Map("q" -> q)
      as_str
    )
  }

  def getApache(root: String, q: String): String = {
    import org.apache.http.impl.client.DefaultHttpClient
    import org.apache.http.impl.client.BasicResponseHandler
    import org.apache.http.message.BasicHeader
    import org.apache.http.entity.StringEntity
    import org.apache.http.client.methods.HttpGet

    val client = new DefaultHttpClient() // doing this and the shutdown() adds about .5ms
    val method = new HttpGet(root + "/facetedSearch?q=" + java.net.URLEncoder.encode(q, "UTF-8"))
    val responseBody = client.execute(method, new BasicResponseHandler())
    client.getConnectionManager().shutdown()
    responseBody
  }

This code is itself a webserver, and I am timing it with ab. Requests are in series, and the payload being proxied is only 5kB. Here are the times:
Skip my proxy server and call the inner /facetedSearch service directly with ab: 6ms
Call the proxy server and have it use getApache: 8.6ms
Call the proxy server and have it use getDispatch: 55ms

I realize I could do less setup/teardown, and I could probably get http pipelining going to save some overhead, but even without those improvements, something is still very wrong. (If I reuse the Http object, the 55ms becomes 32ms.)

I'd like to keep using dispatch, but I'm having to port critical requests back to HttpClient unless someone knows a way to fix the slowdown.

JVM 1.6, Scala 2.8.1, outer webserver is the jetty inside sbt.



If you reply to this email, your message will be added to the discussion below:
http://databinder.3617998.n2.nabble.com/40ms-performance-hit-over-org-apache-http-tp6600779p6600779.html
To start a new topic under Databinder, email [hidden email]
To unsubscribe from Databinder, click here.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 40ms performance hit over org.apache.http

drew
Thanks for drawing my attention ConfiguredHttpClient! The fact that my httpclient setup doesn't respect http_proxy makes most of the difference, as I happened to have an http_proxy that was on a faraway network.

New timings, with no http_proxy:
Upstream service directly: 7ms
Through my proxy service, with httpclient: 10ms
Through my proxy service, with dispatch: 12ms

This is much more reasonable, and I know where to start if I want to squeeze out some more performance.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 40ms performance hit over org.apache.http

n8han
Administrator
That's a relief! If you do find that Source is responsible for some part of the remaining difference, we'll open an issue to use reader to build strings instead.

Nathan

On 07/20/2011 12:22 PM, drew [via Databinder] wrote:
Thanks for drawing my attention ConfiguredHttpClient! The fact that my httpclient setup doesn't respect http_proxy makes most of the difference, as I happened to have an http_proxy that was on a faraway network.

New timings, with no http_proxy:
Upstream service directly: 7ms
Through my proxy service, with httpclient: 10ms
Through my proxy service, with dispatch: 12ms

This is much more reasonable, and I know where to start if I want to squeeze out some more performance.



If you reply to this email, your message will be added to the discussion below:
http://databinder.3617998.n2.nabble.com/40ms-performance-hit-over-org-apache-http-tp6600779p6603372.html
To start a new topic under Databinder, email [hidden email]
To unsubscribe from Databinder, click here.

Loading...