Rails Unicorn metrics

266 views
Skip to first unread message

Ben Kochie

unread,
Jan 23, 2017, 8:19:57 AM1/23/17
to Prometheus Developers
Julius and I have been working on ideas for dealing with Ruby/Rails apps that run in a multi-process mode.  For example Passenger[0] or Unicorn[1].

These worker processes can track metrics, but there's no good way to expose those metrics because they live behind a round-robin http proxy.

The solutions I've seen so far has been to use statsd or influxdb push metrics to a local aggregation proxy exporter.

Has anyone though about how to deal with Ruby multi-process?

Brian Brazil

unread,
Jan 23, 2017, 8:21:10 AM1/23/17
to Ben Kochie, Prometheus Developers
Any reason you can't take the same approach Python does? 

--

Ben Kochie

unread,
Jan 23, 2017, 8:28:52 AM1/23/17
to Brian Brazil, Prometheus Developers
Looking over the code, it's probably possible, I'm just not sure what the performance impact is for that style.  From what I can see every metric update has to read and write quite a bit of data to disk.

Brian Brazil

unread,
Jan 23, 2017, 8:31:10 AM1/23/17
to Ben Kochie, Prometheus Developers
On 23 January 2017 at 13:28, Ben Kochie <sup...@gmail.com> wrote:
Looking over the code, it's probably possible, I'm just not sure what the performance impact is for that style.  From what I can see every metric update has to read and write quite a bit of data to disk.

It's mmaped with no fsync, so basically the same as RAM accesses. The primary cost in Python turn out to be the mutexes.

Brian
 

On Mon, Jan 23, 2017 at 2:21 PM, Brian Brazil <brian.brazil@robustperception.io> wrote:
On 23 January 2017 at 13:19, Ben Kochie <sup...@gmail.com> wrote:
Julius and I have been working on ideas for dealing with Ruby/Rails apps that run in a multi-process mode.  For example Passenger[0] or Unicorn[1].

These worker processes can track metrics, but there's no good way to expose those metrics because they live behind a round-robin http proxy.

The solutions I've seen so far has been to use statsd or influxdb push metrics to a local aggregation proxy exporter.

Has anyone though about how to deal with Ruby multi-process?

Any reason you can't take the same approach Python does? 

--




--

Ben Kochie

unread,
Jan 23, 2017, 8:43:16 AM1/23/17
to Brian Brazil, Prometheus Developers
Yea, it's always going to be slower than a proper threaded implementation.  But if it can be implemented similarly I think that would work.

Of course, I'm no ruby expert. :)

Matthias Rampke

unread,
Jan 24, 2017, 3:51:39 AM1/24/17
to Ben Kochie, Brian Brazil, Prometheus Developers

Would this work on Windows?

Given the lock contention, what is the upper limit on throughput of a single machine?


--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
To post to this group, send email to prometheus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CABbyFmoVyyzBn3DuKw3%2BnM0tpwtJuYiG4w%3D5%2BbC-7SOYg%3D%3DWHA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Brian Brazil

unread,
Jan 24, 2017, 3:54:44 AM1/24/17
to Matthias Rampke, Ben Kochie, Prometheus Developers
On 24 January 2017 at 08:51, Matthias Rampke <m...@soundcloud.com> wrote:

Would this work on Windows?


Why wouldn't it?
 

Given the lock contention, what is the upper limit on throughput of a single machine?

For Python anyway, mutexes are relatively slow so you're limited to a few hundred thousand operations a second. If this were a problem I don't think you'd be using either Ruby or Python.

Brian 

On Mon, Jan 23, 2017, 14:43 Ben Kochie <sup...@gmail.com> wrote:
Yea, it's always going to be slower than a proper threaded implementation.  But if it can be implemented similarly I think that would work.

Of course, I'm no ruby expert. :)

On Mon, Jan 23, 2017 at 2:31 PM, Brian Brazil <brian.brazil@robustperception.io> wrote:
On 23 January 2017 at 13:28, Ben Kochie <sup...@gmail.com> wrote:
Looking over the code, it's probably possible, I'm just not sure what the performance impact is for that style.  From what I can see every metric update has to read and write quite a bit of data to disk.

It's mmaped with no fsync, so basically the same as RAM accesses. The primary cost in Python turn out to be the mutexes.

Brian
 

On Mon, Jan 23, 2017 at 2:21 PM, Brian Brazil <brian.brazil@robustperception.io> wrote:
On 23 January 2017 at 13:19, Ben Kochie <sup...@gmail.com> wrote:
Julius and I have been working on ideas for dealing with Ruby/Rails apps that run in a multi-process mode.  For example Passenger[0] or Unicorn[1].

These worker processes can track metrics, but there's no good way to expose those metrics because they live behind a round-robin http proxy.

The solutions I've seen so far has been to use statsd or influxdb push metrics to a local aggregation proxy exporter.

Has anyone though about how to deal with Ruby multi-process?

Any reason you can't take the same approach Python does? 

--




--

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-developers+unsub...@googlegroups.com.
To post to this group, send email to prometheus-developers@googlegroups.com.



--

Matthias Rampke

unread,
Jan 24, 2017, 12:44:58 PM1/24/17
to Brian Brazil, Ben Kochie, Prometheus Developers
Ah, I was misremembering https://github.com/prometheus/client_ruby/issues/9#issuecomment-73425882 – that was about shared memory. File open semantics are still different between Windows and Unix, but I'm fuzzy on the details.

On Tue, Jan 24, 2017 at 8:54 AM Brian Brazil <brian....@robustperception.io> wrote:
On 24 January 2017 at 08:51, Matthias Rampke <m...@soundcloud.com> wrote:

Would this work on Windows?


Why wouldn't it?
 

Given the lock contention, what is the upper limit on throughput of a single machine?

For Python anyway, mutexes are relatively slow so you're limited to a few hundred thousand operations a second. If this were a problem I don't think you'd be using either Ruby or Python.

Brian 

On Mon, Jan 23, 2017, 14:43 Ben Kochie <sup...@gmail.com> wrote:
Yea, it's always going to be slower than a proper threaded implementation.  But if it can be implemented similarly I think that would work.

Of course, I'm no ruby expert. :)

On Mon, Jan 23, 2017 at 2:31 PM, Brian Brazil <brian....@robustperception.io> wrote:
On 23 January 2017 at 13:28, Ben Kochie <sup...@gmail.com> wrote:
Looking over the code, it's probably possible, I'm just not sure what the performance impact is for that style.  From what I can see every metric update has to read and write quite a bit of data to disk.

It's mmaped with no fsync, so basically the same as RAM accesses. The primary cost in Python turn out to be the mutexes.

Brian
 

On Mon, Jan 23, 2017 at 2:21 PM, Brian Brazil <brian....@robustperception.io> wrote:
On 23 January 2017 at 13:19, Ben Kochie <sup...@gmail.com> wrote:
Julius and I have been working on ideas for dealing with Ruby/Rails apps that run in a multi-process mode.  For example Passenger[0] or Unicorn[1].

These worker processes can track metrics, but there's no good way to expose those metrics because they live behind a round-robin http proxy.

The solutions I've seen so far has been to use statsd or influxdb push metrics to a local aggregation proxy exporter.

Has anyone though about how to deal with Ruby multi-process?

Any reason you can't take the same approach Python does? 

--




--

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
To post to this group, send email to prometheus...@googlegroups.com.



--

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
To post to this group, send email to prometheus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLrHpUBT%2B6cRS8e%2BBf7i0AUqh6nkQSc4OhL5S5Etc36a7g%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages