The majority of SavaPage configuration is conducted in the Administrator Web App. Additional configuration
options can be set in the
/opt/savapage/server/server.properties configuration
file, and with the Config Editor.
Alternative port are set in the
/opt/savapage/server/server.properties
configuration file as shown in the table below.
| Key | Description |
|---|---|
|
|
Server http port. Default:
|
|
|
Server https port. Default:
|
|
|
Redirect HTML of non-SSL port to SSL:
|
|
|
The RAW Print Server port. Default:
|
Table 11.2. Server Properties: Alternative TCP/IP Ports
Important
Since SavaPage is run by user
savapage, you can't use ports
below 1024, because these ports can only be bound to by the
superuser (root). If you want SavaPage Web Apps to be
accessible through port 80 and 443 at all costs, you can use Apache or NGINX server to forward (or "reverse-proxy") requests to
SavaPage.
A high reliability server process like SavaPage must reject excess requests immediately (fail fast) by using a Request Queue with a bounded capacity.
When a request is rejected, the user browser will show a diagnostic message, for example that “The connection to the server was reset while the page was loading” because “The site could be temporarily unavailable or too busy”, with the advise to “Try again in a few moments”.
Request Queue capacity is calculated according to a tolerable “no-response” time.
For example, if the server is capable of handling 100 requests per second,
and 30 seconds of patience is accepted by users in the event of excessive
high load, you can set the queue capacity to
30*100=3000.
If queue capacity is set too low, the server will reject requests too soon and won't be able to handle normal load spikes. If set too high, a high load, that exceeds the processing power of the server application, will continue to stack requests on the queue. And thus, even after the load stops, the application will appear to have stopped responding to new requests as it still has lots of requests on the queue to handle.
Requests are FIFO processed by threads contained in a ThreadPool. The
maximum number of threads needed, in order to achieve the best performance,
depends on host resources (RAM and CPU cores) assigned to the SavaPage
application. The maximum value will typically be between
50 and 500.
The keys to set thread pool and queue capacity in the
/opt/savapage/server/server.properties
configuration file are shown in the table below.
| Key | Description |
|---|---|
|
|
The capacity (maximum length) of the queue holding
client requests to the server. Requests are FIFO
processed by threads in the pool. Default:
|
|
|
Maximum number of threads in the pool. Default:
|
|
|
Minimum number of threads in the pool. Default:
|
|
|
Maximum time a thread may be idle in milliseconds
after it is terminated. Default:
|
Table 11.3. Server Properties: ThreadPool Settings
ThreadPool settings are part of application performance tuning. See Chapter 20, Tuning in general and Section 20.1, “Linux Kernel Parameters” in particular.
Note
The browser “connection reset” message can be easily provoked by setting very low threadpool values, like:
server.threadpool.queue.capacity=4 server.threadpool.minthreads=1 server.threadpool.maxthreads=5 server.threadpool.idle-timeout-msec=10000
... and frantically pressing the F5 browser key.
Server Web Sessions expire after a certain period of inactivity: see Section 15.3.1, “Web Session Timeout”. Expired sessions are removed by a cyclic scavenge process. The cycle interval can be set with this property:
| Key | Description |
|---|---|
|
|
The interval (seconds) at which expired server
sessions are scavenged. Default:
|
Table 11.4. Server Properties: Session Settings
Database connections are both expensive to create and maintain over time. Therefore, they are an ideal resource to pool. That is just what SavaPage does, with the help of JDBC Connection Pooling[23].
The keys to set the Connection parameters in the
/opt/savapage/server/server.properties
configuration file are shown in the table below.
| Key | Description |
|---|---|
|
|
Maximum number of connections in the pool. Default:
Important: if you are using PostgreSQL as database back-end this value must align with the maximum number of client connections allowed by the database. See Section 11.3.2.1, “PostgreSQL Settings”. |
|
|
Minimum number of connections in the pool. Default:
|
|
|
Maximum time a connection may be idle in seconds after it is closed.
Default: |
|
|
Idle time in seconds before a connection is checked
for timeout. Default: This value must be less than
|
|
|
Number of prepared SQL statements that will be cached.
Default: Value |
Table 11.5. Database Connection Settings
Note
Database Connection Settings do not apply to the internal database.
PostgreSQL ships with a basic configuration tuned for wide compatibility rather than performance. Depending on available host resources and Database Connection Settings as described in the section above, there is a good chance the default parameters are very undersized.
Tuning Your PostgreSQL Server is an expert job, but there are
two obvious parameters in postgresql.conf[24] you need to consider:
-
max_connectionsmust at least be equal todatabase.connection.pool.maxplus the value ofsuperuser_reserved_connections. For example:#---------------------------------------------------------------- # When SavaPage: database.connection.pool.max = 200 # and in this file: superuser_reserved_connections = 3 # and SavaPage is the only process accessing the Database ... #---------------------------------------------------------------- max_connections = 203 # (change requires restart) # Defaults to 3 #superuser_reserved_connections = 3
-
The
shared_buffersdefault of 128MB can be replaced by a higher value, depending on the total RAM in your system. For example:#---------------------------------------------------------------- # System has 16GB RAM, we take a conservative 6.25% ... #---------------------------------------------------------------- #shared_buffers = 128MB # min 128kB # (change requires restart) shared_buffers = 1024MBA higher value allocates more shared memory during inter-process communication (IPC) between the database server and the requesting client, resulting in speedier data transfer. See PostgreSQL Memory.
Important: restart the database after changing any of these settings.
CUPS notifier is a custom SavaPage binary that pushes printer and print job status events from CUPS to SavaPage server.
Occasionally the notifier may fail to deliver job state notifications, as
can be seen reported in /var/log/cups/error_log. Since
a failure can result in no job end states being observed, a heartbeat
monitor pulls print status from CUPS for active jobs that have not been
notified since the previous beat of the heart. The heartbeat period can be
configured: see Section 11.3.3.4, “CUPS Configuration Properties”.
CUPS Job Status is handled in the following way:
-
Normally a print job that is stopped in CUPS, for instance because “job-completed-with-errors”, must be manually controlled (reprint, cancel, move) by an operator. However, when SavaPage identifies a stopped job it cancels it automatically.
-
At system (application) start-up, job status is pulled from CUPS for every proxy printed document that has not reached end-state.
See Section 11.3.3.4, “CUPS Configuration Properties” on how to change the defaults.
See Section 11.3.3.4, “CUPS Configuration Properties” on how to change defaults for the number of IPP connections to local CUPS and their IPP connect and read timeouts.
| Configuration property | Description |
|---|---|
|
cups.notifier.job-status-pull.heartbeat-msec |
Number of milliseconds since the last pushed print job status notification by CUPS Notifier after which a job status update is pulled from CUPS. Default: 30000 |
|
cups.job-state.cancel-if-stopped.enable |
Set to Y (default) or N, to enable/disable automatic cancellation of stopped CUPS Job Status. |
|
system.startup.cups.sync-print-jobs.enable |
Set to Y (default) or N, to enable/disable CUPS Job Status synchronization at system start-up. |
|
cups.ipp.local-connect-timeout-msec |
IPP connect timeout in milliseconds on local CUPS. Default: 5000. |
|
cups.ipp.local-socket-timeout-msec |
IPP read timeout in milliseconds on local CUPS. Default: 9000. |
|
cups.ipp.max-connections |
Max number of IPP connections on CUPS. Default: 10. |
|
cups.ipp.subscription.notify-lease-duration |
Duration of the notification subscription lease (minutes) for the CUPS Notifier. Value of must be greater than one (1) hour, since the renewal of the subscription is scheduled by SavaPage every hour. Default: 4200. |
Table 11.6. CUPS Configuration Properties
See Section 4.10.14.11, “Config Editor” on how to set these properties.
To separate files created at runtime from installation files you can set alternative locations for temporary
files, SafePages and public Letterheads in the
/opt/savapage/server/server.properties
configuration file.
Caution
All alternative file locations must reside on the same 
disk partition[25].
| Key | Description |
|---|---|
|
The location is not used by third-party Java
components: they use Default: subdirectory
|
|
Default:
|
|
Default:
|
Table 11.7. Server Properties for Alternative File Locations
These are the extra settings that can be configured in the
/opt/savapage/server/server.properties
configuration file.
| Key | Description |
|---|---|
|
|
Enable database cleanup at server start-up. See Section 4.10.13, “Backups”. Values: |
|
|
See Section 18.1.1.4, “Custom i18n”. Values: |
Table 11.8. Server Properties: Miscellaneous Settings
[23] SavaPage uses Java Database Connectivity (JDBC) Connection Pooling from c3p0: an easy-to-use library for making traditional JDBC drivers “enterprise-ready”.
[24] On Debian based systems postgresql.conf is
located in
/etc/postgresql/[version]/main/
[25] This constraint is needed because files are initially created in the temporary location and atomically moved to their destination. Atomic moves do not work cross-partition.