You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@clue I've thought about a fix, and I see there is an intention to calculate an amount of request that can be handled concurrently, based on the memory limit and post_max_size.
I'm not sure what amount of request we should estimate to be possible the the post_max_size is unlimited, so that is why I'm not suggesting a PR to address this.
There could be several approaches.
To ignore the estimation and return self::MAXIMUM_CONCURRENT_REQUESTS? But what if the concurrent requests will exceed the memory then?
To limit to one concurrent request? But wouldn't that decrease the performance?
To change the estimation formula to use something other than post_max_size, but what in particular?
Activity
clue commentedon Jun 5, 2020
@smscr Thanks for reporting, I can indeed reproduce this with
post_max_size=0. Does anybody feel like filing a PR to address this? 👍In the meantime, you can work around this by setting
post_max_sizeto a large value, this should have the same effect.s-bronstein commentedon Jun 5, 2020
@clue I've thought about a fix, and I see there is an intention to calculate an amount of request that can be handled concurrently, based on the memory limit and post_max_size.
I'm not sure what amount of request we should estimate to be possible the the post_max_size is unlimited, so that is why I'm not suggesting a PR to address this.
There could be several approaches.