.. /*  
    * This file is part of the SavaPage project <https://www.savapage.org>.
    * Copyright (c) 2026 Datraverse B.V.
    * Author: Rijk Ravestein.
    *
    * SPDX-FileCopyrightText: (c) 2020 Datraverse B.V. <info@datraverse.com>
    * SPDX-License-Identifier: CC-BY-SA-4.0
    *
    * For more information, please contact Datraverse B.V. at this
    * address: info@datraverse.com
    */

.. _app-capacity-planning:

.. figure:: ../images/manual/savapage-logo-no-text-100px.png
   :width: 75px

Capacity Planning
=================

.. admonition:: |ADMONITION_TABLE_OF_CONTENTS|

   - :numref:`{number}. {name} <app-capacity-planning-database>`
   - :numref:`{number}. {name} <app-capacity-planning-safepages>`
   - :numref:`{number}. {name} <app-capacity-planning-network>`


This section discusses capacity planning considerations so
administrators can plan future infrastructure requirements and make
decisions about how to deploy the application. |PRODUCT_NAME| is designed
to be self-maintaining, however it is important that the administrator
understands the disk-space requirements and how this changes overtime.

.. _app-capacity-planning-database:

Database Sizing and Growth
--------------------------

Special attention is needed to make sure there is enough disk space to
hold a growing database. Database growth is very dependent on the usage
patterns and therefore can differ significantly from site to site.

Although, there is some overhead for data like Users, Proxy Printers and
Queues, this data is static and does not grow over-time. The majority of
database growth is caused by logging the document flow.

So, the best prediction of database growth is based on the estimated
number of documents printed to |PRODUCT_NAME| and Proxy Printers, and
exported to PDF.

The table below provides an indication of growth per 10,000 jobs for
|PRODUCT_NAME| and Proxy Printing and PDF export. Combining these numbers
with your estimate of user activity result in a growth estimate.

.. table:: Database size increase metrics per document flow.

   ========================================== ========================
   Job Type                                   Increase per 10,000 jobs
   ========================================== ========================
   |PRODUCT_NAME| printing                    15 MB
   |PROXYPRINTER| printing                    20 MB
   :ref:`SavaPage Financial <ch-financial>`   5 MB
   PDF export                                 20 MB
   ========================================== ========================

To demonstrate how to estimate database growth we make a number of
assumptions. Please adjust these assumptions to suit your organization.
The assumptions are:

-  1 job for each job type per user per day

-  20 working days in a month

-  Therefore, 20 jobs for each job type per user per month

Here is a sample database growth calculation based on a 500 user site:

1. Calculate the total number of jobs expected for the month (i.e. the
   total number of users multiplied by the number of jobs). So in this
   example, |PRODUCT_NAME| is handling 10,000 jobs for each job type a
   month.

  .. RST_HTML_NEWLINE

2. Calculate the monthly growth rate by dividing the jobs per month by
   10,000 and then multiplying by the database growth rate:

    .. list-table::
       :header-rows: 1
       
       * - Job Type
         - Monthly growth
         - Total
       * - |PRODUCT_NAME| printing
         - ``10,000 / 10,000 * 15``
         - ``15 MB``
       * -  |PROXYPRINTER| printing
         - ``10,000 / 10,000 * 20``
         - ``20 MB``
       * -  |PRODUCT_NAME| Financial
         -  ``10,000 / 10,000 * 5``
         - ``5 MB``
       * - PDF export
         - ``10,000 / 10,000 * 20``
         - ``20 MB``

   Therefore in this situation the database will grow by approximately
   ``15 + 20 + 5 + 20 = 60 MB`` per month.

3. To estimate the growth per year, multiply the above by 12. Therefore
   in this situation, the database will grow by ``60 * 12 = 720 MB`` per
   year.

.. tip::

   You can limit database growth by purging old log data after an
   automatic database backup. In our example, when you set the number of
   days document logs are held to 365, database increase will maximize
   to 720MB. See :ref:`Backups <ch-webapp-admin-options-backups>`.