A customer contacted us to say that it was taking ten to fifteen minutes for RPM Remote Print Manager® ("RPM") to print their jobs.
Before exploring this issue, I'd like to explain that by "slow" I mean "jobs that do print, but it seems to take a lot longer than it should." If they don't print at all, this is a separate problem which I hope to address in a future FAQ.
RPM doesn’t have a "print faster" button, so addressing the speed issue is entirely a matter of first, determining what’s wrong and second, addressing the issues.
It seems that there are several distinct possibilities:
- RPM could be slow
- RPM could print perfectly fine, and the Windows print system could be the issue
- The network could be slower than expected
- We have heard of instances where the job file was in use by another process, and RPM retried the job until it had clear access
Everything in this article assumes you have a recent version of RPM. If you are using a version that is older than 6.2, not all of these techniques are going to apply to you.
We also assume that:
- You have the user interface open
- You have selected the queue the print jobs are sent to
- You have access to the Windows command line and can run elevated commands, in other words, you have admin privileges
- You are able to run a system performance utility such as Task Manager or perhaps Procexp, which is part of SysInternals (owned by Microsoft, highly recommended)
Now let’s explore these possibilities in more detail.
How to tell if RPM is slow
If I were to attempt to judge RPM’s slowness, this is what I would look for. Send a print job to RPM, and watch it in the queue as it’s processing. Typically it should only take a few seconds to process. A minute seems unlikely.
If it’s taking 10 to 15 minutes to process, and you can see it in the user interface all that time, then let’s try database maintenance first.
We have an article on our website on doing database maintenance. We’ve found that many of our customers have never done database maintenance, or don’t do it often enough. Rather than being the last resort, it should be the first resort.
I recommend that you read that article on database maintenance, follow the instructions, then try sending print jobs again. You’ll want to do database maintenance with the service and the user interface both stopped.
If your print jobs are still taking a very long time after database maintenance, you might check whether RPM is consuming a lot of CPU. We have not seen this happen in years so running a current version of RPM is an idea in your favor.
Run Task Manager and find the process "rpmsrv" or perhaps "RPM Remote Print Manager". Or, I prefer to use procexp. When I’m processing jobs RPM rarely gets above 5% of the CPU. If you are seeing RPM use 25% of the CPU, and you have a quad-core machine … doing some quick math it seems that RPM is consuming a full CPU. Or if you have an 8-core machine, and RPM is consuming 12.5% or close … you get the idea.
If you see this behavior, I'll recommend one more time that you run the database maintenance as suggested above.
If that fails to make a difference, you’re probably going to want to contact our support.
Considering the Windows print system
Troubleshooting Windows printers is probably above my pay grade but I do have a few observations which may help.
First, print to your printer from a regular Windows application such as Word or notepad or whatever you like. If the printer is slow, then you should stop reading this article and fix your printer! It’s not us, friend.
Second, check that your printer has the latest driver available. How to do this varies depending on the version of Windows you are running, so do a Web search on how to check your printer driver and do that.
Third, if your printer is fine, then in the RPM user interface go to the action you are using to print in this queue. If you are using a text print action then use the Browse to select your printer again, just so you can refresh the definition in RPM with the latest driver you have installed.
If you are using a raw print action then use the Printer Selection list object to see the current printers, reselect your printer, and click OK.
Finally, you could consider restarting the Windows spooler. You would want to do this when no one is printing, of course. Again, use a Web search to find out how to do that for your edition of Windows.
Slow network
One change we made in RPM 6.2 is that jobs now appear in the user interface when they are fully received. If you send a job, and it seems to take a long time to appear in RPM, then the network is probably slow.
One consideration for network slowness is that some customers use a print monitoring tool that sends a queue status request after each print job. We've come to understand these are used to make sure the print server is still available.
RPM has been able to handle those requests all along but we didn’t realize people were leveraging that request for status. Consequently, we haven’t kept up with this feature from year to year. RPM assumed that the status requestor would close the connection the way print clients do. Bad for us, this wasn’t the case. We found out when a customer complained of "slow print" and when they supplied us with some logs, we found that when RPM was shut down, all these connections closed at the same time.
It turns out that handling one request and ending up with an extra connection is no big deal, but having 600+ open connections is a much bigger issue.
This problem was not hard to fix and the customer has not experienced their slowness issue since. This change was available in update 6.1.0.471 dated 2018-02-21 so if you have a version prior to that, please update and see if this fixed your problems.
Job retry
We have spoken with customers who told us the print job suddenly printed after a minute. On investigation, we found that the action used to process the job reported an error in the event log, and the job automatically retried as it was supposed to. The retry schedule was set for a minute. If the retry schedule had been set to a longer period, then the delay would have been ... that much longer. I hope that makes sense.
It turns out the reason the job errored the first time was that another process had the job file open, and RPM was not able to open it.
Conclusions
I’ve saved this last comment to the end: if your network on the machine is slow, or if the network bandwidth between your print clients and RPM is slow, then there’s nothing we or RPM can do to help until that situation is resolved.
Other than these things, as I said at the top, there is no "go fast" setting in RPM or "go slow and force an upgrade". Certainly not! Hopefully one or more of these suggestions will help you track down the real problem.