Mercurial > hg > orthanc-book
changeset 777:5caf286f8a0a
note about ssd
author | Sebastien Jodogne <s.jodogne@gmail.com> |
---|---|
date | Wed, 22 Sep 2021 20:34:42 +0200 |
parents | 702d9c22651d |
children | 4707c55080c8 |
files | Sphinx/source/faq/scalability.rst |
diffstat | 1 files changed, 11 insertions(+), 7 deletions(-) [+] |
line wrap: on
line diff
--- a/Sphinx/source/faq/scalability.rst Mon Sep 20 15:22:05 2021 +0200 +++ b/Sphinx/source/faq/scalability.rst Wed Sep 22 20:34:42 2021 +0200 @@ -370,15 +370,19 @@ Slow deletions ^^^^^^^^^^^^^^ -Deleting large studies can take some time, because removing a large +Deleting large studies can take much time, because removing a large number of files from a filesystem can be an expensive operation (which -might sound counterintuitive). +might sound counter-intuitive). This is especially true with HDD +drives, that can be much slower than SSD (`an user has reported +<https://groups.google.com/g/orthanc-users/c/1lga0oFCHN4/m/jF1inrc4AgAJ>`__ +a 20 times speedup by switching from HDD to SSD). -It is possible to create an :ref:`storage area plugin -<creating-plugins>` that delays the actual deletion from the -filesystem. The plugin would maintain a queue (e.g. as a SQLite -database) of files to be removed. The actual deletion from the -filesystem would be done asynchronously in a separate thread. +If switching from HDD to SDD is not applicable, it is possible to +create an :ref:`storage area plugin <creating-plugins>` that delays +the actual deletion from the filesystem. The plugin would maintain a +queue (e.g. as a SQLite database) of files to be removed. The actual +deletion from the filesystem would be done asynchronously in a +separate thread. We are looking for funding from the industry to implement such a plugin.