Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(gunicorn): add gunicorn and gevent test scenarios #4810

Closed
wants to merge 4 commits into from

Conversation

Yun-Kim
Copy link
Contributor

@Yun-Kim Yun-Kim commented Dec 20, 2022

Description

This PR builds off #4776 in adding test scenarios involving the gunicorn test fixture introduced in #4776.
This PR adds tests outlining our library's documented supported use cases with gevent workers in gunicorn servers, specifically testing the following scenarios:

  1. Using DD_GEVENT_PATCH_ALL=1 in the ddtrace-run command to have gevent patched immediately.
  2. Using DD_GEVENT_PATCH_ALL=0 in the ddtrace-run command. This will result in unexpected behaviors due to gevent not being patched immediately.
  3. Using import ddtrace.bootstrap.sitecustomize in the first line of the application instead of ddtrace-run and the DD_GEVENT_PATCH_ALL environment variable.
  4. Using a post_worker_init hook to import ddtrace.bootstrap.sitecustomize.

Checklist

Motivation

Design

Testing strategy

Relevant issue(s)

Testing strategy

Reviewer Checklist

  • Title is accurate.
  • Description motivates each change.
  • No unnecessary changes were introduced in this PR.
  • Avoid breaking API changes unless absolutely necessary.
  • Tests provided or description of manual testing performed is included in the code or PR.
  • Release note has been added and follows the library release note guidelines, or else changelog/no-changelog label added.
  • All relevant GitHub issues are correctly linked.
  • Backports are identified and tagged with Mergifyio.

@Yun-Kim Yun-Kim added the changelog/no-changelog A changelog entry is not required for this PR. label Dec 20, 2022
@Yun-Kim Yun-Kim requested a review from a team as a code owner December 20, 2022 22:50
@Yun-Kim Yun-Kim marked this pull request as draft December 20, 2022 22:50
@Yun-Kim Yun-Kim force-pushed the yunkim/gunicorn-test-scenarios branch from 2aa8eda to 05c5405 Compare December 20, 2022 23:03
from tests.webclient import PingFilter


DynamicInstrumentation.enable()
Copy link
Collaborator

@emmettbutler emmettbutler Jan 20, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Yun-Kim can you help me understand why you added this to the test app? I think it could play an important role in the tests I'm writing and I'm wanting to check my understanding. Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@emmettbutler good question! I added Dynamic Instrumentation here while tinkering around with the test scenarios to see if we could see any unexpected behavior. If I recall correctly @P403n1x87 mentioned there were known issues with Dynamic Instrumentation with gevent, although I'm not sure if it was enabling Dynamic instrumentation alone that caused the issues.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the idea was to start a service that would register after-fork hooks that re-start background threads. DI is an example where this happens, since it requires RCM and the uploader thread to be started soon after fork. The general pattern is also in this test

def test_gevent_reinit_patch():

@codecov-commenter
Copy link

codecov-commenter commented Jan 21, 2023

Codecov Report

Merging #4810 (58249cf) into 1.x (6de9b70) will increase coverage by 0.09%.
The diff coverage is 77.23%.

❗ Current head 58249cf differs from pull request most recent head 749dfac. Consider uploading reports for the commit 749dfac to get more accurate results

@@            Coverage Diff             @@
##              1.x    #4810      +/-   ##
==========================================
+ Coverage   74.64%   74.74%   +0.09%     
==========================================
  Files         810      817       +7     
  Lines       62276    63461    +1185     
==========================================
+ Hits        46489    47436     +947     
- Misses      15787    16025     +238     
Impacted Files Coverage Δ
ddtrace/_monkey.py 49.05% <ø> (ø)
ddtrace/contrib/elasticsearch/__init__.py 100.00% <ø> (ø)
ddtrace/contrib/flask/helpers.py 0.00% <0.00%> (ø)
ddtrace/contrib/flask/patch.py 0.00% <0.00%> (ø)
ddtrace/contrib/flask/wrappers.py 0.00% <0.00%> (ø)
ddtrace/contrib/flask_cache/tracers.py 0.00% <0.00%> (ø)
ddtrace/contrib/psycopg/connection.py 0.00% <0.00%> (ø)
ddtrace/contrib/sqlalchemy/__init__.py 100.00% <ø> (ø)
ddtrace/ext/user.py 0.00% <0.00%> (ø)
ddtrace/internal/remoteconfig/constants.py 0.00% <0.00%> (ø)
... and 186 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

@emmettbutler
Copy link
Collaborator

#4962 builds on this work. I'm going to close this PR to reduce confusion - please reopen if you want.

emmettbutler added a commit that referenced this pull request Jan 31, 2023
…y configs (#4962)

## Description

This pull request tries to answer two questions: 

* Is the [public documentation about
gunicorn](https://ddtrace.readthedocs.io/en/stable/advanced_usage.html#gunicorn)
accurate and complete?
* What problematic ddtracepy behavior was [this
commit](e1ab88c)
fixing?

It does so by implementing a series of integration tests against a real
gunicorn server. Each test configures the server and ddtracepy in a
different way. These tests check each configuration against known
failure modes. The set of configurations that avoid all known failure
modes is the one that the updated documentation recommends.

There were a lot more tests exercising various buggy configurations, but
I removed them to make CI run faster. Let me know if you think some of
those other configurations need to be included in automated testing.

By "known failure modes", I mean degraded performance, duplicated work,
or crashes that I found through experimentation based on following
logical threads from the relevant issues below. The big comment in the
diff explains it in detail.

## Checklist
- [x] [Library
documentation](https://github.com/DataDog/dd-trace-py/tree/1.x/docs)
- [ ] update these https://docs.datadoghq.com/
- [ ] update these
https://app.datadoghq.com/apm/service-setup?architecture=host-based&language=python

(I'll do the other documentation locations once we're in agreement about
the documentation decisions made in this PR)

## Relevant issue(s)

#2894
#4810
#4070
#1799

## Testing strategy

After the experimentation process that informed the integration test
writing, the testing strategy is the tests themselves.

## Reviewer Checklist
- [ ] Title is accurate.
- [ ] Description motivates each change.
- [ ] No unnecessary changes were introduced in this PR.
- [ ] Avoid breaking
[API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces)
changes unless absolutely necessary.
- [ ] Tests provided or description of manual testing performed is
included in the code or PR.
- [ ] Release note has been added and follows the [library release note
guidelines](https://ddtrace.readthedocs.io/en/stable/contributing.html#Release-Note-Guidelines),
or else `changelog/no-changelog` label added.
- [ ] All relevant GitHub issues are correctly linked.
- [ ] Change contains telemetry where appropriate (logs, metrics, etc.).
- [ ] Telemetry is meaningful, actionable and does not have the
potential to leak sensitive data.

---------

Co-authored-by: Munir Abdinur <[email protected]>
Co-authored-by: Brett Langdon <[email protected]>
jbertran pushed a commit that referenced this pull request Feb 1, 2023
…y configs (#4962)

## Description

This pull request tries to answer two questions: 

* Is the [public documentation about
gunicorn](https://ddtrace.readthedocs.io/en/stable/advanced_usage.html#gunicorn)
accurate and complete?
* What problematic ddtracepy behavior was [this
commit](e1ab88c)
fixing?

It does so by implementing a series of integration tests against a real
gunicorn server. Each test configures the server and ddtracepy in a
different way. These tests check each configuration against known
failure modes. The set of configurations that avoid all known failure
modes is the one that the updated documentation recommends.

There were a lot more tests exercising various buggy configurations, but
I removed them to make CI run faster. Let me know if you think some of
those other configurations need to be included in automated testing.

By "known failure modes", I mean degraded performance, duplicated work,
or crashes that I found through experimentation based on following
logical threads from the relevant issues below. The big comment in the
diff explains it in detail.

## Checklist
- [x] [Library
documentation](https://github.com/DataDog/dd-trace-py/tree/1.x/docs)
- [ ] update these https://docs.datadoghq.com/
- [ ] update these
https://app.datadoghq.com/apm/service-setup?architecture=host-based&language=python

(I'll do the other documentation locations once we're in agreement about
the documentation decisions made in this PR)

## Relevant issue(s)

#2894
#4810
#4070
#1799

## Testing strategy

After the experimentation process that informed the integration test
writing, the testing strategy is the tests themselves.

## Reviewer Checklist
- [ ] Title is accurate.
- [ ] Description motivates each change.
- [ ] No unnecessary changes were introduced in this PR.
- [ ] Avoid breaking
[API](https://ddtrace.readthedocs.io/en/stable/versioning.html#interfaces)
changes unless absolutely necessary.
- [ ] Tests provided or description of manual testing performed is
included in the code or PR.
- [ ] Release note has been added and follows the [library release note
guidelines](https://ddtrace.readthedocs.io/en/stable/contributing.html#Release-Note-Guidelines),
or else `changelog/no-changelog` label added.
- [ ] All relevant GitHub issues are correctly linked.
- [ ] Change contains telemetry where appropriate (logs, metrics, etc.).
- [ ] Telemetry is meaningful, actionable and does not have the
potential to leak sensitive data.

---------

Co-authored-by: Munir Abdinur <[email protected]>
Co-authored-by: Brett Langdon <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog/no-changelog A changelog entry is not required for this PR.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants