提交 d4d564c8 编写于 作者: L Lin Jen-Shin

Try not to hold env and release the controller

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.
上级 0b9825ca
......@@ -23,5 +23,6 @@ warmup do |app|
end
map ENV['RAILS_RELATIVE_URL_ROOT'] || "/" do
use Gitlab::ReleaseController
run Gitlab::Application
end
......@@ -28,7 +28,7 @@ module Gitlab
end
end
@app.call(env)
@app.call(env).tap { @env = nil }
end
private
......
module Gitlab
module Middleware
ReleaseController = Struct.new(:app) do
def call(env)
app.call(env).tap { env.delete('action_controller.instance') }
end
end
end
end
require 'spec_helper'
describe Gitlab::Middleware::ReleaseController do
let(:inner_app) { double(:app) }
let(:app) { described_class.new(inner_app) }
let(:env) { { 'action_controller.instance' => 'something' } }
before do
expect(inner_app).to receive(:call).with(env).and_return('yay')
end
describe '#call' do
it 'calls the app and delete the controller' do
result = app.call(env)
expect(result).to eq('yay')
expect(env).to be_empty
end
end
end
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册