Mercurial > hg > orthanc-book

comparison Sphinx/source/faq/scalability.rst @ 777:5caf286f8a0a

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
note about ssd
author Sebastien Jodogne <s.jodogne@gmail.com>
date Wed, 22 Sep 2021 20:34:42 +0200
parents 4e9dc26a5cb9
children 01fa632daae9
comparison
equal deleted inserted replaced
776:702d9c22651d 777:5caf286f8a0a
368 368
369 369
370 Slow deletions 370 Slow deletions
371 ^^^^^^^^^^^^^^ 371 ^^^^^^^^^^^^^^
372 372
373 Deleting large studies can take some time, because removing a large 373 Deleting large studies can take much time, because removing a large
374 number of files from a filesystem can be an expensive operation (which 374 number of files from a filesystem can be an expensive operation (which
375 might sound counterintuitive). 375 might sound counter-intuitive). This is especially true with HDD
376 376 drives, that can be much slower than SSD (`an user has reported
377 It is possible to create an :ref:`storage area plugin 377 <https://groups.google.com/g/orthanc-users/c/1lga0oFCHN4/m/jF1inrc4AgAJ>`__
378 <creating-plugins>` that delays the actual deletion from the 378 a 20 times speedup by switching from HDD to SSD).
379 filesystem. The plugin would maintain a queue (e.g. as a SQLite 379
380 database) of files to be removed. The actual deletion from the 380 If switching from HDD to SDD is not applicable, it is possible to
381 filesystem would be done asynchronously in a separate thread. 381 create an :ref:`storage area plugin <creating-plugins>` that delays
382 the actual deletion from the filesystem. The plugin would maintain a
383 queue (e.g. as a SQLite database) of files to be removed. The actual
384 deletion from the filesystem would be done asynchronously in a
385 separate thread.
382 386
383 We are looking for funding from the industry to implement such a 387 We are looking for funding from the industry to implement such a
384 plugin. 388 plugin.