The focus is on being lightweight and asynchronous, it is not finished, but it is possible to test it out! The plan is to only support the DAP/* protocol (currently only v2 since client support appears to be spotty at the moment). So it will only support a fraction of the features that Hyrax and Thredds can do.
It has basic support for HDF5, NetCDF4 (through HDF5) and Ncml. Since the HDF5 library is not thread-safe at all, an concurrent (and highly experimental) HDF5 reader was written. Inspired by the DMR++ module in Hyrax (thanks for the advice and previous work!). It performs on par or better than the official HDF5 library for sequential reads, but far better for concurrent reads: https://github.com/gauteh/hidefix
Benchmarking is difficult or even meaningless, but I have tried to compare the performance (requests per second) between dars, thredds, and hyrax for a couple of cases. Note that it would be better to look at latency percentile histograms, but those are difficult to compare for servers that perform differently. The tests tries to make as many requests per second using 10 concurrent connections, for metadata (DAS & DDS), data: small request(40kb) slicing through large dataset (464mb), large request entire dataset (464mb), small request, entire dataset(740kb). The tests are run on the _default_ docker images for the servers. The large dataset is chunked, compressed (gzip) and shuffled, (MEPS) while the small dataset is chunked, but uncompressed (coads_climatology).
Note that I encountered frequent out-of-memory errors with thredds especially when benchmarking against the large dataset.
Hope this might be of interest!
Best regards, Gaute