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.

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

800 bps when serving webpage with WSGIServer #174

Closed
rivques opened this issue Sep 10, 2022 · 2 comments · Fixed by #175
Closed

800 bps when serving webpage with WSGIServer #174

rivques opened this issue Sep 10, 2022 · 2 comments · Fixed by #175

Comments

@rivques
Copy link
Contributor

rivques commented Sep 10, 2022 •
edited
Loading

Hi! I've been messing around with a Metro M4 Airlift Lite and hit an interesting snag when trying to serve a webpage using Adafruit's esp32spi_wsgiserver and adafruit_wsgi.wsgi_app. (Code is here for those interested.) When serving the webpage, I was getting only about 800 bits per second, slow enough to cause Chrome to have issues recognizing the format of the page as HTML because (I assume) the <!DOCTYPE html> did not arrive quickly enough. After digging through debug=True logs and the various modules of adafruit_esp32spi, it seems like the issue is that WSGIServer.finish_response is sending data to ESP_SPIcontrol.socket_write one byte at a time. This bypasses socket_write's built-in chunking and seems to cause a lot of extra overhead, possibly due to #108. To fix this I use a slightly modified version of esp32spi_wsgiserver where I socket_write the entire response at once if possible instead of looping over every char in the response and writing it individually. This increased data rate to something like 178 kbps. Anyways, my questions are:

  1. Am I missing something that would cause this to be a non-issue?
  2. Is this a known issue and if so, is there another workaround?
  3. Would this problem be fixed by ESP_SPIcontrol._wait_for_ready is eating lots of time polling the READY/BUSY pin #108 being resolved?
  4. Is my workaround a reasonable one, or does it have pitfalls I can't see? If so, should I put it in a PR to this repo?
@dhalbert
Copy link
Contributor

My intention in the near future is to remove esp32spi_wsgiserver entirely and recommend that people use generic server implementations that use adafruit_requests, of which there are several. This makes the library smaller and allows us to write better server implementations that can be used in more circumstances. The PR to do that is #167, which is stalled for other reasons.

@dhalbert
Copy link
Contributor

Your fix sounds perfectly reasonable for now, and we can get it in for posterity.

rivques added a commit to rivques/Adafruit_CircuitPython_ESP32SPI that referenced this issue Sep 10, 2022
@rivques
close adafruit#174
6f2b40e 
by sending entire webserver response to esp32 in one go if possible
@rivques rivques mentioned this issue Sep 10, 2022
Merged
dhalbert added a commit that referenced this issue Sep 11, 2022
@dhalbert
Merge pull request #175 from rivques/main
ee6bfcf 
Close #174 by sending entire webserver response to ESP32 in one go if possible
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
2 participants
@dhalbert @rivques