Skip to content

Error: "upstream request timeout" occurring on playground after clicking "Flash" #7

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.

Sign up for GitHub

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

Jump to bottom
Closed
deadprogram opened this issue Dec 24, 2019 · 6 comments
Closed

Error: "upstream request timeout" occurring on playground after clicking "Flash" #7

deadprogram opened this issue Dec 24, 2019 · 6 comments

Comments

@deadprogram
Copy link
Member

The error "upstream request timeout" is occurring frequently on the Playground website when trying to download code using the "Flash" button.

I do not have the same issue/slowness when compiling inside the web interface for the simulator.
@aykevl
Copy link
Member

aykevl commented Dec 25, 2019

It seems to work for me, although it is also rather slow at the moment.

@deadprogram
Copy link
Member Author

Might just be performance is too slow under current load? It used to be a lot faster...

@aykevl
Copy link
Member

aykevl commented Dec 30, 2019

For which target was this the case?

Might just be performance is too slow under current load?

Unlikely, it is little used. And even if there was a high load, GCP should just add more instances automatically.

There is a timeout of 20 seconds. I thought this was a reasonable upper limit, not expecting timeouts to happen. However, the samd-based boards are much slower to compile so probably are the reason why you're hitting a timeout.

@deadprogram
Copy link
Member Author

OK that makes sense, as those were the only boards I actually tried, it seemed like a general slowdown vs. the performance of a new feature.

So you will up the timeout?

@aykevl
Copy link
Member

aykevl commented Dec 30, 2019 •
edited
Loading

Ok, updated to 30s. Hopefully that fixes it for now.

For the long term, the compiler should really be sped up (something I've been working on already for a looong time, tinygo-org/tinygo#285).

@deadprogram
Copy link
Member Author

OK closing for now. Will reopen if needed.

aykevl added a commit to tinygo-org/tinygo that referenced this issue Jan 17, 2020
@aykevl
machine: avoid bytes package in USB logic
120929d 
This greatly cuts down on compile time (by about 5x for small programs)
and also makes the program a whole lot smaller. Overall it cuts down
`make smoke-test` in the drivers repository by half (from 160s to 80s).

This will probably also fix the timeout issue in the Playground:
tinygo-org/playground#7
@aykevl aykevl mentioned this issue Jan 17, 2020
Merged
deadprogram pushed a commit to tinygo-org/tinygo that referenced this issue Jan 18, 2020
@aykevl @deadprogram
machine: avoid bytes package in USB logic
4ee7bf0 
This greatly cuts down on compile time (by about 5x for small programs)
and also makes the program a whole lot smaller. Overall it cuts down
`make smoke-test` in the drivers repository by half (from 160s to 80s).

This will probably also fix the timeout issue in the Playground:
tinygo-org/playground#7
bgould pushed a commit to bgould/tinygo that referenced this issue Feb 6, 2020
@aykevl @bgould
machine: avoid bytes package in USB logic
d496323 
This greatly cuts down on compile time (by about 5x for small programs)
and also makes the program a whole lot smaller. Overall it cuts down
`make smoke-test` in the drivers repository by half (from 160s to 80s).

This will probably also fix the timeout issue in the Playground:
tinygo-org/playground#7
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@deadprogram @aykevl