This would make the application considered ready much slower,
but when it's ready, then it's really ready. Before this change,
it claims to be ready, but it's annoyingly slow for the first
request with GDK. It's 100% 502 for me, for the first request.
This shouldn't really affect production or so, because if it's
really ready, it should be blazingly fast, and it should not
slow things down too much.
The culprit here is probably `ActionController::Base.helpers.asset_path`
but this could make sure that anything else would load first, too.
+ Use NullMetrics to mock metrics when unused
+ Use method_missing in NullMetrics mocking
+ Update prometheus gem to version that correctly uses transitive dependencies
+ Ensure correct folders are used in Multiprocess prometheus client tests.
+ rename Sessions controller's metric
This is a step for #29118.
Add a single metric to count successful logins.
Summary types are not supported so remove Collector. Either
we need to support the summary type or we need to create a
multiprocess-friendly Collector.
Add config to load prometheus and set up the Collector and the
Exporter.
Fix `Gemfile` as current prometheus-client gemspec is missing the
`mmap2` dependency.
Using this limit on GitLab.com it appears we're able to reduce response
timings by about 620 milliseconds compared to the previous limit.
See gitlab-org/gitlab-ce!2421 for more information.
Don't assume that if the Rack server is not Passenger then it must be Unicorn. There are many other Rack servers in the world (uwsgi being one example that people use a lot).
The reverse check is much more logical, i.e. check explicitly for Unicorn