Improve author image performance

[mikiher]

This is the same as PR #3580, for author images.

[nichwall]

Do we want to add the X-Accel redirect to the author images to be consistent with the cover images?

I don't know if X-Accel is still useful due to these two PRs greatly reducing the response time for image fetch requests, so maybe we can just get rid of the X-Accel entirely.

[mikiher]

Do we actually have users using X-accel?

I've never used this, but from what I read, this requires an Nginx web server running in front of Audiobookshelf to handle the X-accel-redirect responses. I haven't seen any example of how to do this in our codebase or documentation, so this would likely only be used by advanced users, on systems that need to deal with a high throughput.

For those who do use it, there might still be some (?) performance gain by offloading the actual serving of those files to Nginx, but I wouldn't keep support for it unless there's a substantial portion of our userbase using it.

[nichwall]

It is implemented here for the cover cache.

audiobookshelf/server/managers/CacheManager.js

Lines 70 to 74 in 654b1d6

	if (global.XAccel) {
	const encodedURI = encodeUriPath(global.XAccel + writtenFile)
	Logger.debug(`Use X-Accel to serve static file ${encodedURI}`)
	return res.status(204).header({ 'X-Accel-Redirect': encodedURI }).send()
	}

@itzexor is the only one I know who uses it, I don't know if anyone else uses it. If these changes to the API makes the performance difference negligible I would say we can get rid of it.

[mikiher]

My opinion is that X-accel support is an undocumented feature that only benefits very specific (undocumented) setups. It also provides a level of optimization that is not matched by our server's capabilities (I mean, we've just seen how the server has issues dealing with 30 requests in parallel before sending even a single byte back).

I would gladly remove it altogether.

[advplyr]

@itzexor is the only user I'm aware of that is using it

[advplyr]

Thanks!