Slow HTTP response times reported when content test is enabled

Issue #257 closed
Dmitry Dzhus created an issue

I'm using monit-5.14 on Ubuntu 14.04.

The only service definition I have is as follows

check process foobar with pidfile /var/run/foobar.pid
  start program = "/sbin/start foobar"
  stop program = "/sbin/stop foobar"

  if
    failed
    port 3000
    protocol http
    request "/endpoint"
#    content = "myText"
    then alert

It works as expected. In the monit web interface the check shows up as

Port Response time 0.041s to localhost:3000/endpoint type TCP/IP
protocol HTTP

However, if I uncomment the line with HTTP response body content check, the value increases hundredfold:

Port Response time 10.178s to localhost:3000/endpoint type TCP/IP
protocol HTTP

The expected content is present in the response body and the check succeeds. The response time is appalling though.

When I access that URL from terminal on the machine using curl, the response arrives in under 100ms (matching response time reported by monit without the content check):

root@hostname:/home/dmitry.dzhus# time curl -v localhost:3000/endpoint > /dev/null
* Hostname was NOT found in DNS cache
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 3000 (#0)
> GET /endpoint HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:3000
> Accept: */*
> 
< HTTP/1.1 200 OK
< Transfer-Encoding: chunked
< Date: Thu, 01 Oct 2015 21:28:04 GMT
* Server Warp/3.1.3 is not blacklisted
< Server: Warp/3.1.3
< Content-Type: application/json
< 
{ [data not shown]
100 10544    0 10544    0     0   264k      0 --:--:-- --:--:-- --:--:--  270k
* Connection #0 to host localhost left intact

real    0m0.047s
user    0m0.005s
sys 0m0.005s

Does anybody have any ideas what may be causing this?

It's almost as if monit uses a slow pattern-matching library and includes the time spent on searching for pattern in the response time.

Comments (10)

  1. Dmitry Dzhus reporter

    Sorry but I don't have access to build tools on target machine. I'll just wait when you release a fixed version, sorry :)

  2. Olivier Grange-Labat

    @dzhus you can use send/expect as a workaround, eg:

    #!
    if failed port 3000 send "GET /endpoint HTTP/1.0\r\n\r\n" expect "HTTP/1.[0-1] 200.*myText.*" then alert
    
  3. Log in to comment