This repository has been archived by the owner on Mar 27, 2023. It is now read-only.
Extend time until timeout in production #58
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
maltezacharias
suggested changes
Jun 25, 2020
There was a problem hiding this comment.
As per https://docs.gunicorn.org/en/stable/settings.html#timeout:
Generally set to thirty seconds. Only set this noticeably higher if you’re sure of the repercussions for sync workers. For the non sync workers it just means that the worker process is still communicating and is not tied to the length of time required to handle a single request.
I did some reading up on the different worker_classes and found this:
For full greenlet support applications might need to be adapted. When using, e.g., Gevent and Psycopg it makes sense to ensure psycogreen is installed and setup.
https://docs.gunicorn.org/en/stable/design.html
I think with async workers normally you shouldn't see a timeout happening here, have we implemented the above or is it possible that our DB calls are still synchronous? At least in requirements we have no psycogreen (yet?)
|
I added TODO:
|
|
As before, this should easily be resolved by adding the dependency to .isort.cfg .If that does not fix it, ping me again :) |
|
https://github.com/match4everyone/match4everything/tree/longer_timeouts-psycogreen starts for me. I can't get explain the @maltezacharias With the lower @bjrne Works, thx. Is there no better way? |
|
I'll try to set it low enough so I can see the same, to reproduce just start the server or is there anything else I need to do? |
|
@maltezacharias No. You should see a lot of CPU and disk load. Maybe it only happens for me because my machine is slower than yours but the server shouldn't be faster, right? |
|
I narrowed it down: only the first request after setting up a new database takes so long but the first one doesn't finish if we use a shorter timeout |
|
So to reproduce locally: I'll try that locally later today |
Create a completely new database container
Set timeout ridiculously low on your super-duber machine 😛 |
|
@Baschdl Can you please check out the easier deploy branch and try it out without changing the timeout. Do you still get the timeout error there? If not I would like to close this and keep timeout on the default. If you still keep the timeout error with the new branch I will accept this change. I just ran a completely fresh build with the easier deploy branch with a timeout set to 5 and didn't see any timeouts in the log: EDIT: And yes, I opened up the site after that and clicked on a few links. Before this test the old docker volumes were deleted, so everything was created from scratch |
|
@maltezacharias It seems to work with |
Merged
|
Opened #98 for psycogreen |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Some changes orthogonal to our code (didn't we freeze all necessary package versions?) cause load times of more than 30 seconds for the first request (at least on my machine) and therefore cause the gunicorn worker to timeout.
Should fixes timeouts in #49 and possibly also error 500 in #21