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

Logging to stderr has some kind of limit in the PHP-FPM runtime #1714

Closed
curlysanders opened this issue Jan 11, 2024 · 6 comments · Fixed by #1852
Closed

Logging to stderr has some kind of limit in the PHP-FPM runtime #1714

curlysanders opened this issue Jan 11, 2024 · 6 comments · Fixed by #1852
Labels

Comments

@curlysanders
Copy link

curlysanders commented Jan 11, 2024

Description:
It seems that logging to stderr with monolog (using Symfony 6.3) has some kind of limit in the web function, with php-fpm runtime.
Whenever some threshold in amount (and size) of log entries is reached the lambda seems to hang until it times out after 28 seconds.

For instance we have an import endpoint which reads an uploaded Excel sheet. With logging enabled we can process about 260 rows before it hangs. The same command for processing but then run via a console command has no issue whatsoever, it handles 13.000+ rows easily. Also worker lambdas do not show this behavior

This behavior is also observed locally with the same runtime.

Debgging steps tried:
When minimum log level is raised to notice, the logging is reduced to next to nothing (only when an unhandled exception or a PHP notice/warning/error occurs it will be logged). In this case importing via web request works even for 13.000 rows, with only 1 or 2 seconds to spare before the 28 second timeout.
I've also tried increasing memorySize to no effect. No difference noticed comparing 1792M, 10240M and the default 1024M (which we normally use).

How to reproduce:
Attached a Symfony controller and a console command to test amount of log entries (on top of entries generated by frameork and dependencies).
source.zip

  • Create a simple Symfony (6.3) project with monolog and add the controller and command.
  • Add and setup Bref (2.1.3)
  • Setup serverless.yml with the runtimes (web: php-82-fpm, console: php-82-console, worker: php-82)
  • Use a local docker setup with web php image bref/php-82-fpm-dev:2

See also Slack: https://brefworkspace.slack.com/archives/C057S6G4Z9N/p1704917185595609

@kevincerro
Copy link
Contributor

kevincerro commented Jan 12, 2024

I was having this issue with symfony deprecation logs
When lot of deprecations are triggered, lambda hangs until timeout (28 seconds) is reached.

@curlysanders
Copy link
Author

@kevincerro I assume you 'solved' it by disabling deprecation logging.

@kevincerro
Copy link
Contributor

kevincerro commented Jan 12, 2024

@kevincerro I assume you 'solved' it by disabling deprecation logging.

I fixed the deprecation (was being triggered multiple times inside a for loop)

But yes, disabling deprecation logger was my alternative hotfix.

@mnapoli
Copy link
Member

mnapoli commented Jan 12, 2024

Pasting my comment from Slack here for reference:

FYI FPM logs are forwarded to CloudWatch via this: https://github.com/brefphp/bref/blob/master/src/FpmRuntime/FpmHandler.php#L82-L85

Something could be "overwhelming" the PHP code here?

Or maybe it could be this config option for the FPM configuration: https://github.com/brefphp/aws-lambda-layers/blob/main/layers/fpm/php-fpm.conf#L9-L10

@curlysanders
Copy link
Author

I've tried with different FPM config values, to no effect.

  • log_limit to ten times 8192
  • log_buffering = no

Also tested with php-fpm-83. No luck 🤷🏻‍♂️

mnapoli added a commit that referenced this issue Aug 14, 2024
We get rid of symfony/process where we had to forward all the FPM output to PHP. Instead we use `proc_open` and directly stream output to stdout/stderr.
@mnapoli
Copy link
Member

mnapoli commented Aug 14, 2024

I managed to reproduce and I have a fix in #1852, would love if you could test it and confirm if it works.

I'll be closing this issue as a duplicate of #1369 btw

@mnapoli mnapoli closed this as completed Aug 14, 2024
mnapoli added a commit that referenced this issue Aug 16, 2024
Fix #1369 and #1714 Support large amount of logs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants