scoutapp / scout-apm-laravel

ScoutAPM PHP Agent for the Laravel Framework
MIT License
22 stars 12 forks source link

Add an option to disable instrumenting Laravel queues #43

Closed imhmdb closed 4 years ago

imhmdb commented 4 years ago

We use scout APM in a production environment of high usage, when we updated to v1.2 that adds support to instrument Laravel queues we noticed that the workers became drastically slower than the usual, we downgraded back to v1.1 and the performance issue disappeared.

I couldn't figure out exactly why it makes the jobs slower, but my request is to add an option so we can disable instrumenting Laravel queues and that would solve our issue.

asgrim commented 4 years ago

@imhmdb Great idea to add a configuration option here. I've added a new one - instrument_laravel_queues. I've made a PR in #44, I just need to check it works on my setup before merging/releasing.

However, I'm still interested to fix the problem, I have a few questions if you don't mind please:

imhmdb commented 4 years ago

@imhmdb Great idea to add a configuration option here. I've added a new one - instrument_laravel_queues. I've made a PR in #44, I just need to check it works on my setup before merging/releasing.

However, I'm still interested to fix the problem, I have a few questions if you don't mind please:

  • Are you using synchronous dispatching (e.g. using dispatchNow, or using the sync queue driver)
  • Assuming an asynchronous setup, is the slowness caused by dispatching the job, or in the worker(s) themselves?
  • Are you using queue:work or queue:listen for your worker?
  • Are your workers on a separate machine to the dispatcher?
  • Are your workers on the same machine as each other, or distributed across multiple servers?
  • Do you see anything in the logs for your workers relating to Scout? (I'm wondering perhaps, if you have workers distributed across servers, they're all trying to download the agent, but failing for some reason - then each time a job is worked, it tries to download it again or something...)

- Are you using synchronous dispatching (e.g. using dispatchNow, or using the sync queue driver) We use Amazon sqs driver

- Assuming an asynchronous setup, is the slowness caused by dispatching the job, or in the worker(s) themselves? The slowness was in the workers, the dispatching had no issue.

- Are you using queue:work or queue:listen for your worker? queue:work

- Are your workers on a separate machine to the dispatcher? Yes

- Are your workers on the same machine as each other, or distributed across multiple servers? We have a dockerized environment and each worker is on a separate container

- Do you see anything in the logs for your workers relating to Scout? (I’m wondering perhaps, if you have workers distributed across servers, they’re all trying to download the agent, but failing for some reason - then each time a job is worked, it tries to download it again or something...) We think the issue is related to sending the monitoring data because when we set SCOUT_MONITOR=FALSE, it works great.

asgrim commented 4 years ago

@imhmdb Thank you for your responses there. Are you able to send me any log files from the workers when this slowness occurs please? You can email them directly to me james@roave.com if you prefer to keep them private. Thanks

asgrim commented 4 years ago

@imhmdb Good morning - I've just released 1.2.2 which adds a new configuration disabled_instruments=["laravel_queues"] to disable the queue instrumentation.

If you're adding configuration to config/scout_apm.php, you might add:

$config[ConfigKey::DISABLED_INSTRUMENTS] = '["laravel_queues"]';

If you're using .env configuration, you might add:

SCOUT_DISABLED_INSTRUMENTS=["laravel_queues"]

I'm still interested in seeing the logs from your worker if at all possible to try to figure out where the slowness is coming from. Many thanks! :+1: