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

Heroku request timeout #59

Open
epoberezkin opened this issue Jun 10, 2016 · 4 comments
Open

Heroku request timeout #59

epoberezkin opened this issue Jun 10, 2016 · 4 comments

Comments

@epoberezkin
Copy link

In my case the app always times out with this message on the page:

Application Error
An error occurred in the application and your page could not be served. Please try again in a few moments.
If you are the application owner, check your logs for details.

The logs are ok, the actual audit is successful and all the issues are created/updated.

The timeout is 30 sec and according to docs it is not configurable.

The solution is to serve page first and then dynamically serve results.

Or at least start sending the static page heading and once the results are ready finish sending the page - it would increase the timeout by 55 sec.

@prnewman
Copy link

We get the same application error in an organization with 273 github users.

@rtyley
Copy link
Member

rtyley commented Aug 2, 2017

@Nick-Smith has mentioned this issue as well - presumably you work together @prnewman ?! He said:

Basically, it looks like the request times out. I think the audits are being run successfully but the results page never renders because it has to wait too long. We have >250 users so it might just be an issue of too many users to churn through in the given time? You might be able to fix it by parallelizing the audit for each user.

Sorry to hear about the problems you've been having. Nick's idea of parallelizing the audit by user sounds reasonable, the code you'd want to try changing would be:

https://github.com/guardian/gu-who/blob/19d779dd16/app/lib/OrgSnapshot.scala#L111-L137

We have ~190 users and the job doesn't time out - usually the first run is the worst while all the GitHub calls are getting cached. We're also using a legacy Heroku dyno which may actually be better performing, but not an option for you:

image

It will also run slower if there are lots of non-compliant users - we're in the happy position of having 100% compliance at the Guardian, so the check runs pretty fast. You may want to run gu:who locally on a laptop for a few days (getting the number of non-compliant users to decrease) before switching over to Heroku.

I'm afraid @lindseydew & I are pretty busy right now, we haven't much time for maintenance on gu:who!

@Nick-Smith
Copy link

@rtyley Awesome, thanks for the help Roberto! And yes, @prnewman is a colleague of mine.
It seems like the service is actually working, it's just the UI that is timing out.

Hopefully once the service has warmed up and most of our users are compliant the UI will start working.

@prnewman
Copy link

prnewman commented Aug 2, 2017

@rtyley Thanks for the feedback. I'll update if things change as more users comply.

This hiccup notwithstanding, gu:who has been extremely helpful. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants