- 30 10月, 2015 1 次提交
-
-
由 Yorick Peterse 提交于
This query used to rely on a JOIN, effectively producing the following SQL: SELECT users.* FROM users LEFT OUTER JOIN emails ON emails.user_id = users.id WHERE (users.email = X OR emails.email = X) LIMIT 1; The use of a JOIN means having to scan over all Emails and users, join them together and then filter out the rows that don't match the criteria (though this step may be taken into account already when joining). In the new setup this query instead uses a sub-query, producing the following SQL: SELECT * FROM users WHERE id IN (select user_id FROM emails WHERE email = X) OR email = X LIMIT 1; This query has the benefit that it: 1. Doesn't have to JOIN any rows 2. Only has to operate on a relatively small set of rows from the "emails" table. Since most users will only have a handful of Emails associated (certainly not hundreds or even thousands) the size of the set returned by the sub-query is small enough that it should not become problematic. Performance of the old versus new version can be measured using the following benchmark: # Save this in ./bench.rb require 'benchmark/ips' email = 'yorick@gitlab.com' def User.find_by_any_email_old(email) user_table = arel_table email_table = Email.arel_table query = user_table. project(user_table[Arel.star]). join(email_table, Arel::Nodes::OuterJoin). on(user_table[:id].eq(email_table[:user_id])). where(user_table[:email].eq(email).or(email_table[:email].eq(email))) find_by_sql(query.to_sql).first end Benchmark.ips do |bench| bench.report 'original' do User.find_by_any_email_old(email) end bench.report 'optimized' do User.find_by_any_email(email) end bench.compare! end Running this locally using "bundle exec rails r bench.rb" produces the following output: Calculating ------------------------------------- original 1.000 i/100ms optimized 93.000 i/100ms ------------------------------------------------- original 11.103 (± 0.0%) i/s - 56.000 optimized 948.713 (± 5.3%) i/s - 4.743k Comparison: optimized: 948.7 i/s original: 11.1 i/s - 85.45x slower In other words, the new setup is 85x faster compared to the old setup, at least when running this benchmark locally. For GitLab.com these improvements result in User.find_by_any_email taking only ~170 ms to run, instead of around 800 ms. While this is "only" an improvement of about 4.5 times (instead of 85x) it's still significantly better than before. Fixes #3242
-
- 29 10月, 2015 1 次提交
-
-
由 Stan Hu 提交于
Closes #3138
-
- 26 10月, 2015 2 次提交
-
-
由 Kamil Trzcinski 提交于
The previous code relied on having on ref stored in commit, however the ref was moved to the build.
-
由 Kamil Trzcinski 提交于
-
- 23 10月, 2015 6 次提交
-
-
由 Dmitriy Zaporozhets 提交于
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
由 Dmitriy Zaporozhets 提交于
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
由 Dmitriy Zaporozhets 提交于
Signed-off-by: NDmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
-
由 Kamil Trzcinski 提交于
-
由 Kamil Trzcinski 提交于
-
由 Valery Sizov 提交于
-
- 21 10月, 2015 3 次提交
-
-
由 Dirceu Pereira Tiegs 提交于
-
由 Artem V. Navrotskiy 提交于
-
由 Douwe Maan 提交于
-
- 20 10月, 2015 3 次提交
-
-
由 Jacob Vosmaer 提交于
-
由 Douwe Maan 提交于
-
由 Douwe Maan 提交于
-
- 19 10月, 2015 1 次提交
-
-
由 Yorick Peterse 提交于
This cuts down the time it takes to sort issues of a milestone by about 10x. In the previous setup the code would run a SQL query for every issue that had to be sorted. The new setup instead runs a single SQL query to update all the given issues at once. The attached benchmark used to run at around 60 iterations per second, using the new setup this hovers around 600 iterations per second. Timing wise a request to update a milestone with 40-something issues would take about 760 ms, in the new setup this only takes about 130 ms. Fixes #3066
-
- 18 10月, 2015 1 次提交
-
-
由 Douwe Maan 提交于
-
- 17 10月, 2015 1 次提交
-
-
由 Stan Hu 提交于
The counter_cache decrement function is called when a project star is deleted, but there was no guarantee multiple workers would not attempt to delete the same item simultaneously. Use an atomic update to prevent the count from going negative. Closes #3067
-
- 16 10月, 2015 5 次提交
-
-
由 Zeger-Jan van de Weg 提交于
-
由 Zeger-Jan van de Weg 提交于
-
由 Stan Hu 提交于
-
由 Stan Hu 提交于
If a branch is deleted with an open merge request, amended offline, and then pushed again, GitLab doesn't bother to update the merge request even though the last commit ID and/or code may have changed. This MR ensures that each push will update any relevant merge requests and adds a system note if this happens as well. Closes #2926
-
由 Kamil Trzcinski 提交于
-
- 15 10月, 2015 9 次提交
-
-
由 Alex Lossent 提交于
Password can now be specified at the same time as the new URL, and the service template admin pages now work.
-
由 Yorick Peterse 提交于
-
由 Yorick Peterse 提交于
-
由 Yorick Peterse 提交于
By comparing objects in Ruby we can greatly improve the performance of this method. In the worst case (should no data be eager loaded) this will run the same amount of queries as before, in the best case (when data _is_ eager loadeD) it requires no queries at all. The added benchmark used to produce around 273 iterations per second. With this commit this has been increased to almost 40 000 iterations per second: a speedup of roughly 145 times. Combined with eager loading Note associations this results in about 30 queries less when viewing a single issue, this in turn cuts down the loading time by 30-40%.
-
由 Yorick Peterse 提交于
This ensures that when viewing an issue each note already has the associated project, project members, group and group members available. Since this information is requres for every note this results in quite the reduction of SQL queries being executed.
-
由 Yorick Peterse 提交于
-
由 Yorick Peterse 提交于
This ensures we don't end up running N+1 queries for the objects in the affected collections.
-
由 Yorick Peterse 提交于
Performance is improved in two steps: 1. On PostgreSQL an expression index is used for checking lower(email) and lower(username). 2. The check to determine if we're searching for a username or Email is moved to Ruby. Thanks to @haynes for suggesting and writing the initial implementation of this. Moving the check to Ruby makes this method an additional 1.5 times faster compared to doing the check in the SQL query. With performance being improved I've now also tweaked the amount of iterations required by the User.by_login benchmark. This method now runs between 900 and 1000 iterations per second.
-
由 Valery Sizov 提交于
This reverts commit b4639754.
-
- 14 10月, 2015 7 次提交
-
-
由 Valery Sizov 提交于
-
由 Kamil Trzcinski 提交于
-
由 Kamil Trzcinski 提交于
Slightly refactor runner status detection: moving it to Runner class Signed-off-by: NKamil Trzcinski <ayufan@ayufan.eu>
-
由 Kamil Trzcinski 提交于
-
由 Kamil Trzcinski 提交于
-
由 Kamil Trzcinski 提交于
-
由 Kamil Trzcinski 提交于
-