[Fileserver] Fileserver Memory Usage with 200k concurrent connections. about fasthttp HOT 5 CLOSED

I am worried if I make the maxSmallFileSize to 400KB, how would the memory usage would be affecting.

This shouldn't affect memory usage - this just instructs fasthttp to avoid sendfile path for serving files smaller than 400KB. Though CPU usage may increase.

Also, after I switched on bytesRange, the number of Established connection starts gradually increasing. Which means either the collections are not closing, or they are waiting for the next request.

By default fasthttp doesn't close incoming connections unless the client asks this either via using HTTP/1.0 without Connection: keep-alive request header or via Connection: close request header. Such a behavior conforms HTTP/1.1.

Fasthttp server may be configured to close idle keep-alive connections after a certain period of inactivity - see Server.ReadTimeout.
There is also a possibility to disable keep-alive on a per-request basis - see RequestCtx.SetConnectionClose.

Is there any way I can run the service on tcp4 instead of tcp6.

Yes. Just pass a custom listener to Server.Serve:

        s := &fasthttp.Server{
            Handler: requestHandler,
            // Other Server params may be set up here.
        }

        // create tcp4-only listener
        ln, err := net.Listen("tcp4", ":8080")
        if err != nil {
                log.Fatalf("cannot listen tcp4: %s", err)
        }

        // start the server
        if err = s.Serve(ln); err != nil {
                log.Fatalf("error when serving: %s", err)
        }

from fasthttp.

Hi, @siddharthg

Does fileserver use sendfile for bigfiles?

Yes, it should use sendfile for files bigger than maxSmallFileSize, which is currently 8KB. But this depends on internals of Go standard library, so may break in the future Go releases. Currently it works as expected in go 1.5 and go 1.6.

After going through the code, I am suspecting that request handler opens a file every time all the bigFileReaders are already in use, does this mean 200k concurrent connection created 200k bigFileReaders instances.

Yes. Fasthttp must open a file per each connection due to the current sendfile implementation in standard Go library. It cannot share the same file handler among distinct connections as smallFileReader does for files smaller than 8KB, since sendfile implementation in Go depends on the current file handler's position.

Try increasing maxSmallFileSize inside fs.go to the value exceeding file sizes you serve. This should significantly reduce the number of open files in the server process at the cost of higher CPU usage and, probably, slower transfer speeds.

from fasthttp.

You can also limit server's memory usage by setting Server.Concurrency to the maximum allowed concurrent connections.

from fasthttp.

Just realised that sendfile implementation in go might have yet another problem - sendfile syscall requires a dedicated OS thread like any other syscall or cgo call do. This may result in a lot of OS threads when reading files from slow media (for instance, HDD or network storage), since sendfile under linux may block when reading data from the file even in non-blocking mode. Nginx solves this problem by executing sendfile calls under linux on a dedicated thread pool with limited size - see this article for details.

from fasthttp.

Thanks a lot for the reply. Most of the files I am serving lie between 100-400 KB. But there are a lot of files, I am worried if I make the maxSmallFileSize to 400KB, how would the memory usage would be affecting.

Also, after I switched on bytesRange, the number of Established connection starts gradually increasing. Which means either the collections are not closing, or they are waiting for the next request.

Is there any way I can run the service on tcp4 instead of tcp6.

from fasthttp.