1
0
Fork 0
mirror of https://github.com/puma/puma.git synced 2022-11-09 13:48:40 -05:00
Commit graph

14 commits

Author SHA1 Message Date
schneems
441a42e185 Expose top level Puma.stats API
Right now to get stats for a puma process the only way is to go through the control server. The puma-stats-logger does this by reading in a state file then querying the control server manually.

7ad7798e9d/lib/puma_stats_logger/middleware.rb (L28)

Instead, I’m proposing adding a top level `Puma.stats` method that will allow anyone inside of the same process to get access to the stats.

This could be instrumented by a gem to theoretically export these stats to say a Heroku dashboard where we could list out backlog or thread count.

The format of stats is a hash, and will change depending on if the server is in “single” or “clustered” mode.

Clustered:

```
{ "workers": 2, "phase": 0, "booted_workers": 2, "old_workers": 0, "worker_status": [{ "pid": 19832, "index": 0, "phase": 0, "booted": true, "last_checkin": "2018-03-12T16:03:12Z", "last_status": { "backlog":0, "running":5 } },{ "pid": 19833, "index": 1, "phase": 0, "booted": true, "last_checkin": "2018-03-12T16:03:12Z", "last_status": { "backlog":0, "running":5 } }] }
```

Single:

```
{ "backlog": 0, "running": 2 }
```

Alternatively if we could somehow enable another process to get these stats from Puma via pumactl by default without requiring any additional in app config, that would also work.
2018-03-20 11:24:32 -05:00
Francesco Rodriguez
ea22ade352 Require StateFile if needed. 2016-09-08 17:46:24 +02:00
Evan Phoenix
5fdf337790 Move puma.rb to just autoloads. Fixes #1063 2016-09-05 11:29:16 -07:00
schneems
182c836869 Initial Seperation of CLI and Server Launcher work
This is a WIP. This was the minimum I could do to get all tests to pass without changing any tests. Eventually I think we want all high level process controls to come from launcher, I also think we want another separate object that gets passed to Runner/Single/Cluster that will maintain a relationship with the Launcher. We could use this as the object that also gets exposed to the app like the Embeddable class we talked about earlier. 

Moving forwards i'm planning to port out the CLI tests to only test that they are parsing the correct config and launching servers. I'll port all low level unit tests over to the launcher. Making this change we could either keep all the public methods in CLI that delegate to `@launcher`, I'm guessing not many people are using the internals of CLI and we can take them out. It's your call though.

Wanted to kick this over the fence and see if you had any strong reactions or feelings about this approach.
2016-02-04 16:55:10 -06:00
Luis Lavena
9470937da9 Remove non-required dirs from $LOAD_PATH 2012-01-08 16:48:51 -03:00
Evan Phoenix
4439cfb6f8 Remove another ref to a file that doesn't exist 2011-12-01 15:58:54 -08:00
Evan Phoenix
eaa77ebb25 Remove require of deleted file 2011-12-01 15:54:28 -08:00
Evan Phoenix
2e414fbf78 Remove Configurator, not necessary anymore 2011-09-27 11:07:56 -07:00
Evan Phoenix
a3fc7ec951 Simplify, remove GemPlugin usage 2011-09-27 09:23:03 -07:00
Evan Phoenix
e9175fa559 Rename the optional gem loader what it is, optional. 2011-09-23 23:39:35 -07:00
Evan Phoenix
340d2fbf8e Remove HttpRequest via simplification 2011-09-23 23:26:13 -07:00
Evan Phoenix
f5ecd5dca6 More cleanup and removal 2011-09-23 20:46:33 -07:00
Evan Phoenix
000deba3c1 Prune out custom handlers, rack rules. 2011-09-22 22:14:39 -07:00
Evan Phoenix
190a81c55a Name change: Mongrel => Puma 2011-09-22 19:24:43 -07:00