1

I'm currently stuck with a response time problem with the Faraday HTTP library. I'm using the following code to initialize a POST request to a server running on my local machine at 127.0.0.1. The server returns a valid JSON string. The code to initialize the Faraday object on the client side is as follows:

url = 'http://127.0.0.1'

conn = Faraday.new(:url => url) do |faraday|
  faraday.request  :url_encoded
  faraday.response :json, :content_type => 'application/json'
  faraday.adapter  Faraday.default_adapter
end

Then I send a JSON string via a POST request to the server. The code for sending the request looks like this (text size up to 5000 char):

payload = {:language => 'en', :text => 'some text'}.to_json

response = conn.post do |req|
  req.url '/api'
  req.headers['Content-Type'] = 'application/json'
  req.body = payload
end

The expected result is a JSON string of the following structure:

{
  "level1.1" : [
     {
       "level2.1" : [
          {
            "value1" : "Text",
            "value2" : "Text",
            "value(...)" : "Text",
            "value(n)" : "Text"
          },
          {...
          }
        ],
<and so on... - of course in a valid JSON structure ending>

When I run the code without doing anything with the result it performs pretty well and finishes in a reasonable time (< 0.5s). But as soon as I try to access the response object the script becomes terrible slow.

Just by adding the line:

p response.body

The processing time goes up to > 8s.

I have checked the server response with Postman and it works absolutely fine without any visible problems. Response time in Postman is >0.5 s as well. The slow down appears only on the client side when I try to access the response object. Just inspecting the response object doesn't effect the processing time either. But as soon as I start "to do" something with the response it becomes terribly slow.

I'm running Ruby 2.5.3 and Faraday 0.15.4 / Middleware 0.12.2

Any idea what might cause this slowdown is greatly appreciated.

Krid

EDIT

Despite my comment that HTTParty solved this issue this was just due to a smaller payload. HTTParty and Faraday both perform badly on my POST request while a POST request from Postman runs very fast even with large payloads. I have no idea what causes this different runtime behavior when querying exactly the same server app with exactly the same payload.

As said any ideas that might point me in the right direction greatly appreciated.

Krid

Krid
  • 269
  • 1
  • 3
  • 14
  • Does the same happen if you use `puts response.body`? – Aaditya Maheshwari Dec 31 '18 at 01:02
  • What version of Ruby? What version of Faraday? What is the actual JSON response? (preferably the smallest payload able to reproduce the issue) What are the headers for the response? Please remember that questions should include a [minimal, complete, verifiable example](https://stackoverflow.com/help/mcve). – anothermh Dec 31 '18 at 09:09
  • Thanks for your comments. I have edited my question. Unfortunately I can not post a real example here due data protection issues. I have looked into it a bit more and it appears that it is a Faraday issue. When I use HTTParty everything works fine without any latency. – Krid Dec 31 '18 at 13:19
  • @Aaditya: yes it happens with puts as well. The processing time goes up whenever I try to do something with the result object. The only thing that doesn't slow down the runtime is when I do p response.class - that produces an output directly without any lag – Krid Dec 31 '18 at 13:21
  • @Krid Something I came across. I think they never found a solution either. Do look into their chat link. https://stackoverflow.com/questions/48554031/google-api-response-time – Aaditya Maheshwari Jan 01 '19 at 01:39
  • @Aaditya: thanks for looking into it. Things are very strange. I have tried almost all settings (turn off IPV6, entries in hosts etc...). The strange thing is, when I query the server from my local machine with a Python HTTP Client it works perfectly. When I use a Ruby client it is painfully slow. I thought it might be a problem with the NET::HTTP library but it is the same with Excon. I'm sure it is a network issue somewhere on my local machine (MBP with High Sierra) but I have absolutely no clue to fix it... – Krid Jan 02 '19 at 16:25
  • @Krid Well, if it works fast well with postman, python, other languages and their libraries, etc. then it has to be a problem with ruby or the ruby i/o kernel. I will be surprised if it came out to be a problem with the MacOS. You could maybe try your code on another machine , if you have one or online somewhere like REPL, coder, etc...or a friend's machine. – Aaditya Maheshwari Jan 02 '19 at 18:43
  • @Aaditya: uhhh... you're so right. I didn't thought about checking the LAN. I tried it over the LAN with another MBP and it works like a charm. So the issue must be somewhere in the Ruby 127.0.0.1 or 'localhost' processing. I'll try to move the server to Docker and see if this helps. – Krid Jan 02 '19 at 19:12

1 Answers1

0

...after searching for a solution for days I finally found the issue. When you have Python and Ruby code combined within a folder that is connected with a virtualenv Python (and activated Python env of course) Ruby apparently has problems resolving the local address space. It works but it takes some strange detours that make the whole thing terribly slow.

My solution: I moved the Ruby code that has to play together with the Python code via HTTP connections in a folder outside of the Python code folder.

Krid
  • 269
  • 1
  • 3
  • 14