Topics: HP Output Server

HPOS performance tips

  • Use as much Postscript templates as possible. If you use a lot of PCL templates, you'll get a lot of ghostscript processes on your system, required for translation of Postscript to PCL. Most printers nowadays understand Postscript, and Postscript usually gives the best result, without the need of translation processes.
  • Keep the HPOS installation in 1 filesystem, if possible. When files are transferred through HPOS, they get moved from the DLM (dm) directory, to the JQM (drm) directory and ultimately to the DSM (dsup) directory. If you have these 3 in different file systems, the jobs need to be transferred from 1 file system to the other multiple times, causing a lot of disk I/O. By keeping it all in 1 filesystem, a move of a job file is nothing more than setting a file pointer, which is a lot faster and saves huge amounts of disk I/O.
  • Recycle your JQM's at regular intervals (discribed above). Be deleting the JQM and configuring it again, the job database is deleted and recreated, usually saving you hundreds of megabytes in disk space and memory consumption.
  • Restart your system and complete HPOS environment at least once a month. This will clear the memory.
  • Set the server-log-level of each server to "terse" or "info". This will keep the logging to a minimum.
  • Rotate the log files daily: copy the log files, clean out the original log files and remove old log files.
  • The faster the CPUs in your system, the better (this is a very obvious point...)
  • Put the JFS log on a different disk than your HPOS "var" directory. This will separate the disk I/O for JFS logging and the jobs of HPOS, avoiding disk contention.
  • Keep the amount of jobs in HPOS to a minimum. The more jobs in HPOS, the more memory and CPU it uses.
  • Use "generic" templates if you wish to stop HPOS from doing any job delivery monitoring. PJL templates will interrogate the printer about the job status frequently, and thus use more CPU. PJL templates do have a more reliable job delivery method though.
  • Restart any DSM's that use a lot of disk space and/or memory. By restarting them, the disk space and memory is cleared. This will restart any active print jobs, so be sure to check if any jobs are active for the DSM, before restarting it (Especially those 1000 page print jobs at 99% completion....).
  • If you have geographically dispersed users, it might be best to set up a secondary server, which also runs DLM, JQM and DSM, and EM processes. This will keep most network traffic local to the users, instead of moving documents from one location to the other for processing and then transferring it back over the network to the users again. Having an EM process local to the users, saves a lot on EM network traffic also.

If you found this useful, here's more on the same topic(s) in our blog:

UNIX Health Check delivers software to scan Linux and AIX systems for potential issues. Run our software on your system, and receive a report in just a few minutes. UNIX Health Check is an automated check list. It will report on perfomance, capacity, stability and security issues. It will alert on configurations that can be improved per best practices, or items that should be improved per audit guidelines. A report will be generated in the format you wish, and the report includes the issues discovered and information on how to solve the issues as well.

Interested in learning more?