comparison Sphinx/source/faq/scalability.rst @ 554:4f3a6145ae34

Orthanc 1.8.1
author Sebastien Jodogne <s.jodogne@gmail.com>
date Mon, 07 Dec 2020 17:48:33 +0100
parents 034895d2432a
children e5ca21b61fe1
comparison
equal deleted inserted replaced
553:608094adf405 554:4f3a6145ae34
52 -------------------------------------- 52 --------------------------------------
53 53
54 Here is a generic setup that should provide best performance in the 54 Here is a generic setup that should provide best performance in the
55 presence of large databases: 55 presence of large databases:
56 56
57 * Make sure to use the latest release of Orthanc (1.8.0 at the time of 57 * Make sure to use the latest release of Orthanc (1.8.1 at the time of
58 writing). 58 writing).
59 59
60 * We suggest to use the latest release of the :ref:`PostgreSQL plugin 60 * We suggest to use the latest release of the :ref:`PostgreSQL plugin
61 <postgresql>` to store the database index (3.2 at the time of 61 <postgresql>` to store the database index (3.2 at the time of
62 writing). Make sure that ``EnableIndex`` is set to ``true``. 62 writing). Make sure that ``EnableIndex`` is set to ``true``.
176 ----------------- 176 -----------------
177 177
178 Exclusive access to the DB 178 Exclusive access to the DB
179 ^^^^^^^^^^^^^^^^^^^^^^^^^^ 179 ^^^^^^^^^^^^^^^^^^^^^^^^^^
180 180
181 As of Orthanc 1.8.0, the internal code accessing the DB is still affected 181 As of Orthanc 1.8.1, the internal code accessing the DB is still affected
182 by limitations induced by the SQLite engine that was the only one originally 182 by limitations induced by the SQLite engine that was the only one originally
183 available at the beginning of the project: inside a single Orthanc process, 183 available at the beginning of the project: inside a single Orthanc process,
184 there is no concurrent access to the DB. 184 there is no concurrent access to the DB.
185 185
186 One solution to avoid this limitation is to have multiple Orthanc accessing 186 One solution to avoid this limitation is to have multiple Orthanc accessing
188 <https://bitbucket.org/osimis/orthanc-setup-samples/src/master/docker/multiple-orthancs-on-same-db/>`__. 188 <https://bitbucket.org/osimis/orthanc-setup-samples/src/master/docker/multiple-orthancs-on-same-db/>`__.
189 189
190 Also note that the core of Orthanc does not currently support the replay 190 Also note that the core of Orthanc does not currently support the replay
191 of database transactions, which is necessary to deal with conflicts 191 of database transactions, which is necessary to deal with conflicts
192 between several instances of Orthanc that would simultaneously write 192 between several instances of Orthanc that would simultaneously write
193 to the database. As a consequence, as of Orthanc 1.8.0, when connecting multiple 193 to the database. As a consequence, as of Orthanc 1.8.1, when connecting multiple
194 Orthanc to a single database by setting ``Lock`` to ``false``, there 194 Orthanc to a single database by setting ``Lock`` to ``false``, there
195 should only be one instance of Orthanc acting as a writer and all the 195 should only be one instance of Orthanc acting as a writer and all the
196 other instances of Orthanc acting as readers only. Be careful to set 196 other instances of Orthanc acting as readers only. Be careful to set
197 the option ``SaveJobs`` to ``false`` in the configuration file of all 197 the option ``SaveJobs`` to ``false`` in the configuration file of all
198 the instances of Orthanc acting as readers. 198 the instances of Orthanc acting as readers.
207 207
208 208
209 Latency 209 Latency
210 ^^^^^^^ 210 ^^^^^^^
211 211
212 As of Orthanc 1.8.0, Orthanc still performs quite a large number of small 212 As of Orthanc 1.8.1, Orthanc still performs quite a large number of small
213 SQL requests. A simple request to a route like ``/studies/{id}`` can trigger 213 SQL requests. A simple request to a route like ``/studies/{id}`` can trigger
214 6 SQL queries. 214 6 SQL queries.
215 215
216 This is not an ideal situation and this might be addressed 216 This is not an ideal situation and this might be addressed
217 in a future larger DB refactoring (the most time-consuming queries have already 217 in a future larger DB refactoring (the most time-consuming queries have already