I recently helped out one of our biggest corporate customers to resolve issues with their print server. During the the last week of the financial year (when printing load is the highest) their print server became overloaded and stopped working. This sounds bad, but we quickly got things working smoothly again and learned that …
PaperCut scales incredibly well if you allocate appropriate system resources!
This customer had been running PaperCut for about 6 months without issue. Over this period they were gradually transitioning 100s of print queues from legacy print servers to the server hosting PaperCut. This single print server was hosting all queues for their offices country-wide. The extra load of these additional print queues combined with the end-of-year printing load pushed the server to the limit.
When analyzing the problem I noticed that this server was handling a huge print load. In the 30 day period prior the following printing occurred:
- 477,287 print jobs
- 2,021,454 pages printed
- Between 22,000 to 25,000 print jobs each week day
Wow! That’s a lot of printing!
They were also using hold/release queues and Find-Me printing (aka follow-me printing) to provide secure print release and to reduce paper wastage. The result was an average of around 500-600 print jobs waiting in the queue to be released.
The cause of the problem was under resourcing. Their setup was:
- A single server hosting the both the print queues and the PaperCut application server
- The server was a virtual machine assigned only a single processor
- Allocated 3GB of RAM
- Running on a 32-bit Windows Server operating system
My recommendation was to leave the print queues on the existing server, but move the PaperCut Application Server service to a server with 4GB of RAM, 2 or more processors, and running a 64-bit operating system with the 64-bit add-on pack. This configuration:
- Spreads the load between 2 servers
- Allows the PaperCut Application Server to take advantage of more memory (64-bit)
- More available processors allowed efficient processing of simultaneous print jobs
Since making these changes, their system has been running very smoothly. Their servers are now handling more load than ever, and without overloading the servers.
If you’re managing a large PaperCut installation, and in particular leveraging some of PaperCut’s advanced print management features such as secure print release, then there’s a few lessons to take from this:
- Don’t skimp on RAM or CPU resources
- Monitor your servers. Particularly if you’re adding print queues and increasing print load
- Consider running a 64-bit OS to allow for future expansion (e.g. more memory)
- Run PaperCut on an external database like SQL Server, Oracle, PostgreSQL or MySQL
CC image courtesy of Emilian Robert Vicol on flickr
Posted in General |
Last week we released PaperCut 10.0 with the much requested “Printer Groups” feature. But we’re not standing still. All our developers are working hard to implement the new ideas that you’ve been asking for. As you can see from our release history the product continues to improve with each release. But we want to do more … much more … and faster!
And to do that we need another fantastic developer to join the PaperCut team at our head office in Melbourne. If you’re interested, or know any friends who might be … please read on and apply.
The full position description is included below. If you’re applying mention that you read our blog for bonus points!
Posted in General |
Leave a comment
Here at PaperCut we develop software that’s used in every region of the world. Most of our customers are in USA, Canada, UK, Australia, Brazil and China. However there are thousands of customers in more exotic locations. We have customers located throughout the depths of Africa, the middle east, the channel islands, and even a small tropical island.
Developing software for the world represents unique challenges. The most obvious challenge is ensuring that every facet of the application is translatable. PaperCut is already translated into over 15 languages which shows that we’ve done this bit right. You also need to make sure that you are 100% Unicode aware so that you can handle all characters, like Chinese, Japanese, Korean, Russian, etc. Again, PaperCut handles all this with ease.
But occasionally we encounter a problem or unexpected behaviour that only affects users in a particular region in the world. A few weeks ago we had one of these problems. In this case the user was reporting a problem where they were unable to run any PaperCut reports. We obtained debug logs that showed the error details, but even with this information we could not explain the problem. In the end it was the customer that helped find the problem. They reported that if they changed their “language” to “English” the reports worked, and if they changed the locale to “Turkish” the reports failed. Aha!! With that information we reproduced the problem.
I won’t go into all the gory technical details, but it turns out that the problem was that in Turkish the letter “i” when converted to uppercase becomes “İ” (unicode character 0x0130) which is an “I” with a dot above it. Some of our code has assumed that if you uppercased “i” it would become “I”, and when this didn’t occur the report failed to run.
As they say, you learn something every day. And we did! We learned that when dealing with text in different locales around the world … assume nothing.
We’ve now fixed this problem and this fix is now available in our 9.3 release. And with this release PaperCut is available to another large group of users. Prior to this Turkish users needed to run PaperCut under an English/US locale.
Now all we need is a Turkish translation. 🙂 If you’d like to help translate PaperCut into Turkish (or any other language!!!) then let us know. We’d really appreciate your help.
Posted in General |
Leave a comment