Slow performance of FSBrowser on Chrome and Firefox

[rogerclarkmelbourne]

Hi,
I'm using the latest version of the repo from a few days ago, and I'm using the FSBrowser example as a base for a larger sketch.

I'm seeing very slow transfers to Chrome and Firefox on WIndows 7, but Internet explorer is fine.
I've also tested on Android (Firefox) and iOS Safari, and they do not have this problem.
Nor does Safari on OSX.

As an example. a 13k gzipped html file on IE 9 takes less than 100 milliseconds to load
However the same file on Chrome or Firefox takes a minimum of 1.8 secs to load and sometimes as long as 2.5 seconds.

The page is self contained and served from SPIFFS

So this looks like its an issue with the transfers to these specific browsers

Edit.
I tried reducing the HTTP_DOWNLOAD_UNIT_SIZE to 1024 but it didn't make any difference.

I guess I'm going to need to some packet analysis with WireShark :-(

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[me-no-dev]

seems like the browsers are waiting for more data. That is what usually causes delays around 2 seconds.
Any chance your content-length is wrong?

[rogerclarkmelbourne]

I'm just using the FSBrowser example without any modifications

The code that sends the file back to the browser is

bool handleFileRead(String path){
  unsigned long m=millis();
  DBG_OUTPUT_PORT.println("handleFileRead: " + path);
  if(path.endsWith("/")) path += "index.htm";
  String contentType = getContentType(path);
  String pathWithGz = path + ".gz";
  if(SPIFFS.exists(pathWithGz) || SPIFFS.exists(path)){
    if(SPIFFS.exists(pathWithGz))
      path += ".gz";
    File file = SPIFFS.open(path, "r");
    size_t sent = server.streamFile(file, contentType);

    DBG_OUTPUT_PORT.println(millis()-m);
    return true;
  }
  return false;
}

I just added the stuff to print the millis()

Looking at

server.streamFile(file, contentType);

which I think is the issue...

It does this

template<typename T> size_t streamFile(T &file, const String& contentType){
  setContentLength(file.size());
  if (String(file.name()).endsWith(".gz") &&
      contentType != "application/x-gzip" &&
      contentType != "application/octet-stream"){
    sendHeader("Content-Encoding", "gzip");
  }
  send(200, contentType, "");
  return _currentClient.write(file, HTTP_DOWNLOAD_UNIT_SIZE);
}

So its reading the file size from the SPIFFS

When I look at chrome's network display, it behaves as if the data is comming from a very slow source, i.e the progress bar slowly fills in.

What I don't really understand is quite how the data is being written in chunks back to the browser. There appears to be a setting

#define HTTP_DOWNLOAD_UNIT_SIZE 1460

which is passed to

_currentClient.write(file, HTTP_DOWNLOAD_UNIT_SIZE);

However I'm not sure where the call tree goes from this point.

Because _currentyClient is a WifiClient, but WifiClient doesnt have a write method that matches (File, int)

well it has

  template <typename T>
  size_t write(T& source, size_t unitSize);

Which I presume is what is being called

But quite where the actual code that gets executed is, I'm not sure.

[rogerclarkmelbourne]

Update.

I've looked at the transfers in Wireshark and it just looks like individual packets have delays between them.

I don't know if its the ESP8266 which is delayed in sending them, or whether its Chrome etc that is not requesting the next packet straight away.

I've compared it visually (in wireshark) and IE gets all the packets

Trying to compare whats happening on 2 different WireShark captures, there appears to be a 200ms delay between Chrome receiving one packet from the ESP8266 and it requesting the next packet.
Where as on IE there is only 0.06 milliseconds delay before IE requests the next packet.

The delay of 200ms on Chrome and Firefox does point to some internal time-out because the TCP code doesn't like what its been sent.

[drmpf]

I regularly measure 200mS on windows between packets, 10 to 40mS on Mac and Android
Not sure why IE is quicker.
Esp only handles one packet at a time (due to need to handle re-requests)
see #922

[igrr]

Could it be related to Windows delayed acks? https://support.microsoft.com/en-us/kb/823764

If you make a network trace with a network sniffer such as Microsoft Network Monitor, the TCP server sends a TCP ACK segment to the last TCP segment in a TCP data stream in the delayed acknowledgement timer (also known as the delayed ACK timer). By default, for Windows operating systems, the value for this timer is 200 milliseconds (ms).

[rogerclarkmelbourne]

Hi Ivan,

I found that as well when I looked for the 200ms delay ;-)

This is an absolute performance killer on Windows. As the packet size is about 1.5k, which then limits data rates to 5 packets per second or around 7.5k per second.

Its strange it only applies to Chrome and Firefox and not IE. I thought that they would all use the same Windows TCP services and not have their own TCP stack.

BTW. I have tested this on multiple machines, 2 different Windows 7 machines and also a Windows 8.1 machine. I have XP as well, but it takes some time to boot, so I've not bothered to try that as yet.

[drmpf]

My biggest issue is that the whole sketch is blocked for 10mS to 200mS, so I modified the code to make it non-blocking.

[rogerclarkmelbourne]

@drmpf

Thanks. I will try your code tomorrow ( as its 22:40 local here and too late to try it now)

It will be interesting to see if this is the same issue, because as far as I can see, it's the client end that seems to be inserting the delays, but I'm not an expert in TCP/IP or Wireshark, so the issue could be at the ESP8266 end, in my case

[me-no-dev]

you guys can you post here part of the wireshark results? I'm interested in the ACK packets timing compared to the data packets. More data on the packets will also help.
I do not think that the browsers use a different TCP stack then IE but maybe IE uses more options for the socket (TCP_NODELAY and such). If the content-length is set correctly, the browser should immediately close the connection regardless of options. In our WebServer implementation we set proper headers and generally do everything we can to get the browser to close as soon as the last byte is received.

[rogerclarkmelbourne]

OK. I will run Wireshark for both IE11 and Chrome on Windows 7 and upload the results somewhere they can be downloaded from.

BTW.
What format do you want the results to be saved in. Wireshark seems to save in loads of different formats.

[me-no-dev]

even a screenshot of the wireshark window will do. Information needed is visible in the grid

[rogerclarkmelbourne]

LOL
A screenshot was actually what I ended up using myself to compare the previous and last run's

But of course it doesn't let you dig down into more details.

BTW, there were also some differences when IE started to download the page, from what Chrome did.
but I didn't understand what the differences actually meant.

[rogerclarkmelbourne]

I tried to save the packet captures, but the files seem to be huge. (10Mb, perhaps this is because they save before the filters are applied)

Anyway, I've put the screen grabs in a google drive, as I can't seem to upload them to this github issue

With a bit of luck you should be able to access the shared folder here

https://drive.google.com/folderview?id=0B4AdvMiTQuacMzBBbjl3ZHdKUTQ&usp=sharing

[me-no-dev]

delayed ACK all the way... nothing you can do about it, neither can we...

[rogerclarkmelbourne]

Sorry I dont understand what you mean.

Delayed ACK from which end ?

I see delays in Chrome requesting more data.

How come I dont see the same thing when Chrome requests data from other web servers.?