ESPAsyncWebServer
ESPAsyncWebServer copied to clipboard
Stability Issue Solved
Been fighting a stability issue for a while, it works fine on a single request, and blows up when I use a browser to pull the full web interface (4-5 files at same time).
Just had it worked first time. Issue in AsyncTCP
This has the fix. https://github.com/me-no-dev/AsyncTCP/pull/145
Can we get this merged. As it affects ESPAsyncWebServer rather badly, and I've spent days finding why.
Glenn, what HW platform are you using when running the code? My is ESP8666 which has very small RAM. I'm curious if fits after the queue & stack resize. But maybe your platform is the same and the test result is known alreday ... (?)
Im using a ESP32 (In a m5paper from m5stack). It is far better with patch. It still blows up if I do like 10 concurrent sessions, but befoer it was blowing up on 4 sessions. Really should have it "reject" if to many sessions, I believe there another pr for that as well.
I had the same issue last year and also discovered the fix of increasing the queue length from 32 to 128 in
_async_queue = xQueueCreate(). It's been mentioned a few times before which is how I found it, but can't recall where exactly. Anyway this is the only line I needed to change, haven't seen a reported outage yet from any of my users.
+1 for merging it
in my case this changed almost nothing. i don't even have a "stressed" interface, since i'm commonly the only user, it's just a web interface for a esp32cam device, so serving 1) html 2) favicon 3) a js file 4) the stream.jpg of the camera and 5) websockets data. basically i can load the page 1 time out of 10, for the rest it's a restart. totally unreliable.. totally.. it's a pity because on esp8266 this library is close to perfection
My workaround has been to design the site/page to only load 4 or fewer files. This setup is very reliable. Anything over 4 file loads almost always fails. Another technique that I have used is to have an initial loader page which loads the icon file and the Javascript file (or other file(s) - total of 4 or less files) and include a Refresh timeout to load the main html. E.G.: include this in header of the loader page: <META HTTP-EQUIV=”refresh” CONTENT=”5; URL=http://Esp32.local/main.html”> These files are then cached so that when you include them on your main html page, the browser doesn't initiate another file transfer.
you know you can pack your whole site into a gzip file?
On Mon, Jun 13, 2022 at 2:14 PM Chris Armbrust @.***> wrote:
My workaround has been to design the site/page to only load 4 or fewer files. This setup is very reliable. Anything over 4 file loads almost always fails. Another technique that I have used is to have an initial loader page which loads the icon file and the Javascript file (or other file(s) - total of 4 or less files) and include a Refresh timeout to load the main html. E.G.: include this in header of the loader page:
These files are then cached so that when you include them on your main html page, the browser doesn't initiate another file transfer.
— Reply to this email directly, view it on GitHub https://github.com/me-no-dev/ESPAsyncWebServer/issues/1167#issuecomment-1154176648, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYLTJEJ5EOOQRWUVERAGW3VO5T5PANCNFSM5XROW43A . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Anything over 4 file loads almost always fails.
Please see this: https://github.com/me-no-dev/ESPAsyncWebServer/pull/1116
It does not solve everything, but at least does some load balancing to automaticaly (reties by a browser based on responses from esp8266) load more them 4 files in a web project. This likely walk around some of underlaying problems and resource contraints (which exists in every embedded project).
it's a pity because on esp8266 this library is close to perfection
Please notice underlaying library is diffrent: #ifdef ESP32 #include <AsyncTCP.h> ... #else #include <ESPAsyncTCP.h> ... #endif
I'm not using esp32 yet, but I've noticed webserver stability (spurious resets) situation changes if my esp8266 is in mid-low RF conditions (where likely some tcp re-tx needs to happen). If someone would know a solution (tcp stack config in Arduino IDE known as working with the async web serwer, or simmilar), kindly please let me/us know :)
the fix from @glennswest fixed my issue with a crashing ESP32 with a simple svelte app that loaded to many dependencies at the same time.
Thanks for sharing and let's hope it will be included from @me-no-dev in this awesome project.
me hopes to be able to spend at least a month on the project to get it back in line. There are some options now in Espressif for that to happen. Fingers crossed :)
can we support you in some way?
No. this has to do with work. Since I am employed by Espressif, things there take priority. Luckily we now have a whole Arduino team (not just me) and also management has seen the benefit from supporting some of our external projects (like this one) so as soon as workload on Arduino there get's a bit lighter, I will devote some much needed time on the Async servers.
This is a very good news! and honestly i can also understand the "benefits from supporting external projects", i'm still using a lot of ESP8266 in place of newer and faster ESP32 just because of async server. Just let us know if you need some testing help, there's not much more we can do :) Thanks!
Its really nice if we could use full stack web frameworks on esp32, with async. My other problem, which I did workaround, was the slowness of fatfs, and the lack of long file name support. I manage to integrate in sdfat with the async library, and solved the speed and filename. Happy to point out that code. In addition be nice to find a way that it "sheds" or delays to many requests. So you dont have to sacrifice web complexity for max connections.
Thank you for pointing this out! @glennswest :)
Does this fix the heap memory leak issues? Like everytime a request is send and handled free memory on heap goes down, but never returns to it's previous state.
@me-no-dev I really appreciate the work you've put into these libraries (they are good). I hope you espressif also starts supporting these libraries :)
Edit: Nope the issue still persists to some degree:
The graph shows the currently available free heap and each of those steps are caused when reloading the webpage. Even after everything is fully loaded and there is nothing to send it doesn't return to it's previous state.
😓😔
[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.
[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.
The issue is still there
[STALE_CLR] This issue has been removed from the stale queue. Please ensure activity to keep it openin the future.
[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.
Why is it still open? What is the status?
[STALE_CLR] This issue has been removed from the stale queue. Please ensure activity to keep it openin the future.