esp-idf httpd ethernet webserver performance is slow

[gecko242]

I am not sure that the filesystem is the whole story.
I agree spiffs is significantly slower than FAT, but I still believe that requests are getting stopped somewhere way before the webserver.

I have some JSON pages generated entirely on the fly, with no mention of a filesystem. It sometimes still takes a few seconds (10+) for the first request to get a response. Setting up the connection should not take this long.

I will keep digging!

[PeterR]

It really did work for me! EDIT: & like you my instrumentation suggested that the issue was within lwip, turned out my instrumenation was wrong.
I got the impression that once the wobble was introduced then the browser may go into over drive and then that pushed the socket limits etc.

Try making adding a "Connection: close" header to all responses & see what happens.
EDIT: An easy change and will be needed. Try opening your webpage from two/three different PCs/broswser types without.

[gecko242]

Connection:close does not help.
Still getting multiple second response times on 700 bytes of text, generated on the fly.

I can request the data, and there is no indication within the HTTPD server that a request has been made, until a couple of seconds pass and it serves up the data, which is why I thought the delay might originate inside LWIP.

Any other ideas?

[boarchuz]

I was setting up a configuration webpage with WiFi in APSTA mode recently and experienced similar issues. This doesn't sound like quite the same thing but I'll log it here anyway.

The ESP32 server was very responsive (<30ms) on the AP interface.
Requests on the STA interface, however, seemed to go walkabout somewhere between my browser and the ESP32, taking up to a minute for a response. If I queued up dozens of requests over this time, they'd all pile up until eventually getting a flood of responses (regardless of whether they'd been created 30 seconds or 100 ms ago). Requests on the AP interface were serviced immediately even while these STA requests were backing up.

ESP32 debug output showed the STA requests were not being received in a timely fashion (log was dead silent while I was accumulating requests via the browser), and responses were very fast when the requests finally arrived (ie. it wasn't a problem with the ESP32). I tried connecting with my phone and testing the STA interface and found the ESP32 responding as quickly as the AP interface. I decided at that point that it was something funky with my browser (Chromium on Linux) and moved on rather than waste any more time on it.

[gecko242]

Hmm, that sounds identical to what I am experiencing in STA mode.

I have just tested AP mode, and I am experiencing similar things to STA mode.

It is much more reliable in AP mode, but I am still getting a long block every 30 or so requests. I have tested this on Chrome, Edge and Firefox.

So not quite sure where to go from here!

[tionebrr]

EDIT: Sorry for the noise. It actually was the stream sender aggregating Tx packets, and not the ESP32 waiting for Rx packets. I had a *facepalm* moment when I found this =)

=================ignore this====================
Hello folks,

I encountered an issue with a TCP socket server on the esp32 on STA mode. The incoming packets are pilling up and are only processed every 250ms (precisely). It might be related to your issue. Would be glad to know if someone got deeper into this.

Here is the link:
viewtopic.php?f=13&t=16681
==============================================