I don't know if this is a bug report or a general performance improvement idea, but I experimented with some API endpoints and the response times seem quite high.
This takes between 4 - 5 second to respond, which seems quite long. Doing the exact same request again cuts it down to around 2.5 seconds. Changing then songOffset to make it return "new" data, brings it again up to the 4 - 5 second.
So, some observations about it:
The response time seems to be strongly influenced by the filesystem performance. On my system, Airsonic is running as a docker container on Linux. The Linux system is a VM running on a Windows host. The music data is located on hard disk on the Windows host and is mounted to the Linux VM. Usually using the VMware "Shared Folders" which uses vmhgfs-fuse, which is a userspace filesystem. This is quite slow in general. During the request, I see heavy CPU load on the java process but also on the vmhgfs-fuse (which is handling the file system over tneprocess:
When using cifs instead of the vmhgfs, then I am getting better filesystem perfomance and Airsonic is taking profit of it. The response time then goes down to around 1.1 second.
So, the question is: is it expected that processing a search3 API request relies heavily on file system access to the actual music files? I would have expected that the metadata information is stored in memory or can be retrieved from the internal Airsonic database.
My setup:
Running Airsonic as a Docker container in a Linux Vmware guest on a Win10 host. Music library is around 110000 files.
Scope
RestfulAPI
What problem
I don't know if this is a bug report or a general performance improvement idea, but I experimented with some API endpoints and the response times seem quite high.
For example, this request:
This takes between 4 - 5 second to respond, which seems quite long. Doing the exact same request again cuts it down to around 2.5 seconds. Changing then
songOffsetto make it return "new" data, brings it again up to the 4 - 5 second.So, some observations about it: The response time seems to be strongly influenced by the filesystem performance. On my system, Airsonic is running as a docker container on Linux. The Linux system is a VM running on a Windows host. The music data is located on hard disk on the Windows host and is mounted to the Linux VM. Usually using the VMware "Shared Folders" which uses vmhgfs-fuse, which is a userspace filesystem. This is quite slow in general. During the request, I see heavy CPU load on the java process but also on the vmhgfs-fuse (which is handling the file system over tneprocess:
When using cifs instead of the vmhgfs, then I am getting better filesystem perfomance and Airsonic is taking profit of it. The response time then goes down to around 1.1 second.
So, the question is: is it expected that processing a search3 API request relies heavily on file system access to the actual music files? I would have expected that the metadata information is stored in memory or can be retrieved from the internal Airsonic database.
My setup: Running Airsonic as a Docker container in a Linux Vmware guest on a Win10 host. Music library is around 110000 files.
Feature
Improve API query speed :)