Mercurial > hg > orthanc-book
changeset 188:60c91045bf2a
cont
author | Sebastien Jodogne <s.jodogne@gmail.com> |
---|---|
date | Thu, 31 Jan 2019 19:13:52 +0100 |
parents | 0fa1cf88c635 |
children | da12a1d08eb6 |
files | Sphinx/source/faq/scalability.rst Sphinx/source/faq/troubleshooting.rst |
diffstat | 2 files changed, 23 insertions(+), 11 deletions(-) [+] |
line wrap: on
line diff
--- a/Sphinx/source/faq/scalability.rst Thu Jan 31 18:55:58 2019 +0100 +++ b/Sphinx/source/faq/scalability.rst Thu Jan 31 19:13:52 2019 +0100 @@ -6,16 +6,23 @@ One of the most common question about Orthanc is: *"How many DICOM instances can be stored by Orthanc?"* -The source code of Orthanc imposes no such hard limit by itself. The -stress is actually put on the underlying database engine, and on the -storage area (check out :ref:`orthanc-storage`). As explained in the -:ref:`troubleshooting section <troubleshooting>`, the built-in SQLite -database engine should be replaced by an enterprise-ready database -engine as soon as the number of DICOM instances grow above about -50,000 (check out the :ref:`postgresql` and :ref:`mysql`). It is also -true that the performance of Orthanc in the presence of large -databases has continuously improved over time, especially when it comes -to the speed of :ref:`DICOM C-FIND <dicom-find>`. +The source code of Orthanc imposes no such hard limit by itself. At +the time of writing, we know that Orthanc is being used in production +in hospitals with more than 15TB of data, 125,000 studies and around +50 millions of instances (please `get in touch with us +<https://www.orthanc-server.com/static.php?page=contact>`__ if you can +share other testimonials). + +The stress is actually put on the underlying database engine, and on +the storage area (check out :ref:`orthanc-storage`). As explained in +the :ref:`troubleshooting section <troubleshooting>`, the built-in +SQLite database engine should be replaced by an enterprise-ready +database engine once Orthanc must store several hundreds of thousands +of DICOM instances (check out the :ref:`postgresql` and +:ref:`mysql`). It is also true that the performance of Orthanc in the +presence of large databases has continuously improved over time, +especially when it comes to the speed of :ref:`DICOM C-FIND +<dicom-find>`. Here is a generic setup that should provide best performance in the presence of large databases: @@ -29,7 +36,8 @@ * Make sure that :ref:`run-time debug assertions <troubleshooting>` are turned off. A warning will show in the logs if this is not the - case. + case. Note that all pre-built binaries provided by Osimis are + correctly configured in that respect. * We suggest to use the default filesystem storage area. Of course, make sure that the filesystem is properly backup, and that
--- a/Sphinx/source/faq/troubleshooting.rst Thu Jan 31 18:55:58 2019 +0100 +++ b/Sphinx/source/faq/troubleshooting.rst Thu Jan 31 19:13:52 2019 +0100 @@ -76,6 +76,10 @@ As a rule of thumb, the performance of the default SQLite engine built in Orthanc should run fine up to about 50,000 DICOM instances. + However, we have seen Orthanc running fairly well with more than 2 + millions of instances. This limit really depends upon your + application, and upon the patterns of access to the database. + Also check out the section about the :ref:`scalability`.