be3b878443
Previously we'd create a separate Metric instance for every method call that would exceed the method call threshold. This is problematic because it doesn't provide us with information to accurately get the _total_ execution time of a particular method. For example, if the method "Foo#bar" was called 4 times with a runtime of ~10 milliseconds we'd end up with 4 different Metric instances. If we were to then get the average/95th percentile/etc of the timings this would be roughly 10 milliseconds. However, the _actual_ total time spent in this method would be around 40 milliseconds. To solve this problem we now create a single Metric instance per method. This Metric instance contains the _total_ real/CPU time and the call count for every instrumented method. |
||
---|---|---|
.. | ||
architecture.md | ||
ci_setup.md | ||
code_review.md | ||
db_dump.md | ||
doc_styleguide.md | ||
gitlab_diagram_overview.odg | ||
gitlab_diagram_overview.png | ||
gotchas.md | ||
instrumentation.md | ||
licensing.md | ||
migration_style_guide.md | ||
omnibus.md | ||
performance.md | ||
profiling.md | ||
rake_tasks.md | ||
README.md | ||
scss_styleguide.md | ||
shared_files.md | ||
shell_commands.md | ||
sidekiq_debugging.md | ||
sql.md | ||
testing.md | ||
ui_guide.md |
Development
- Architecture of GitLab
- CI setup for testing GitLab
- Code review guidelines for reviewing code and having code reviewed.
- Gotchas to avoid
- How to dump production data to staging
- Instrumentation
- Licensing for ensuring license compliance
- Migration Style Guide for creating safe migrations
- Performance guidelines
- Rake tasks for development
- Shell commands in the GitLab codebase
- Sidekiq debugging
- SQL guidelines for SQL guidelines
- Testing standards and style guidelines
- UI guide for building GitLab with existing css styles and elements