summaryrefslogtreecommitdiff
path: root/config.ru
Commit message (Collapse)AuthorAgeFilesLines
* Bump rack gem to 2.0.7sh-bump-rack-2.0.7Stan Hu2019-04-041-4/+0
| | | | | | | | | | | This update has two important fixes: 1. It reverts the monkey patch introduced in https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/23385 since https://github.com/rack/rack/pull/1201 is now part of the release. 2. Preserve forwarded IP address for trusted proxy chains (https://github.com/rack/rack/pull/1343).
* Enable the Layout/ExtraSpacing cop56392-enable-the-layout-extraspacing-copRémy Coutable2019-01-241-1/+1
| | | | Signed-off-by: Rémy Coutable <remy@rymai.me>
* Add monkey patch to unicorn to fix eof? problemKamil Trzciński2018-11-281-0/+4
| | | | | | | Rack with Unicorn is unable to handle chunked requests due to private `eof?` method. This exposes `eof?` not changing `rack` behavior. Issue: https://gitlab.com/gitlab-org/gitlab-ee/issues/8539
* Increase the memory limits used in the unicorn killerincrease-unicorn-memory-killer-limitsDJ Mountney2018-03-221-2/+2
| | | | | These limits were updated in our docs, and in omnibus some time ago. But the defaults in the source-install were missed.
* Release the entire envLin Jen-Shin2018-02-071-1/+1
|
* Try not to hold env and release the controllerLin Jen-Shin2018-02-071-0/+1
| | | | | | | | | | | | | | | | | | | after the request. This way, we could release the project referred from the controller, which potentially referred a repository which potentially allocated a lot of memories. Before this change, we could hold the last request data and cannot release the memory. After this change, the largest request data should be able to be collected from GC. This might not impact the instances having heavy load, as the last request should be changing all the time, and GC won't kick in for each request anyway. However it could still potentially allow us to free more memories for each GC runs, because now we could free one more request anyway.
* Warm up the app so it's fast for the 1st request38930-warmupLin Jen-Shin2017-12-281-0/+5
| | | | | | | | | | | | | | 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.
* set ENV['prometheus_multiproc_dir'] in config/boot.rb instead of config.ruPawel Chojnacki2017-06-151-3/+0
|
* Move Prometheus presentation logic to PrometheusTextPawel Chojnacki2017-06-021-1/+1
| | | | | | | | + 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
* Mark migration as requiring no downtimePawel Chojnacki2017-06-021-0/+1
| | | | | + Add spaces for four phases approach + fix InfluxDB rename
* Add Changelog fix textual description in config.ruPawel Chojnacki2017-06-021-1/+1
|
* Use only ENV for metrics folder locationPawel Chojnacki2017-06-021-3/+2
|
* Prometheus metrics first passPawel Chojnacki2017-06-021-5/+1
| | | | metrics wip
* Initial pass at prometheus monitoring.Kevin Lyda2017-06-021-0/+7
| | | | | | | | | | | | | | | | 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.
* Increase Unicorn memory limits to 300-350adjust-unicorn-memory-limitsYorick Peterse2016-01-201-2/+2
| | | | | | | 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.
* Use env variables for Unicorn memory limitsYorick Peterse2016-01-201-1/+4
| | | | | This makes it easier for users to use their own limits based on their server configuration.
* Disable Unicorn::WorkerKiller in non-production environmentsrs-no-killers-in-developmentRobert Speicher2015-05-271-4/+7
|
* Check specifically for Unicorn in rack config.ru fileДамјан Георгиевски2014-01-231-1/+1
| | | | | 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
* Fix 'uninitialized constant Unicorn' errordprolife2013-12-221-0/+1
|
* don't use unicorn worker killer if PhusionPassenger is definedJames Newton2013-12-201-4/+6
|
* Add unicorn-worker-killer with memory checkJacob Vosmaer2013-12-181-0/+6
| | | | | Conflicts: Gemfile.lock
* added RAILS_RELATIVE_URL_ROOT supportChris Frohoff2012-12-281-1/+4
|
* init commitgitlabhq2011-10-091-0/+4