14 Replies Latest reply on Jan 24, 2018 4:14 PM by Nikolay Karetnikov

    How many collectors does a customer need?

    Nikolay Karetnikov Navigator

      Hello!

      Recently, large customers became very server aware. Whenever you need a new server questions are arised whether it is a really business related stuff you are doing. Since a try to keep number of collectors from growing.

      We have the "Blueprint Installation guide" stating "A single Collector supports a maximum sustained rate of 160 print jobs per minute for up to 800 iMFPs". The 2nd parameter is pretty clear. Well almost clear. Is that a number of active iMFPs per a day, is that a number of iMFPs registered to a collector, is that a model depended? Would SR25 or Lexmark iPR count as a whole iMFP?

      Now the 160 print job limit. What does exactly it mean?  Is it a number of jobs incoming into a secured queue (#1) or a number of jobs released (#2)?

      In case it #1 a customer could try Print Queue monitoring to approximate necessary number of collectors, but in case of #2 it won't be any of use.

      Dear Pharos, could you please comment on the subject and share the best practices?

        • Re: How many collectors does a customer need?
          Scott Olswold Guide

          Nikolay,

          Thank you for your post!

          The less confusing way to state the limits of a Collector would be:

          • 160 inbound print submissions per minute (so, from the Windows/MacOS client)
          • 800 Secure Release Here-enabled devices (a device is any single- or multi-function printer/copier with a Pharos SR25, Omega, or iMFP terminal)

          From a "best practice" standpoint, it is pretty easy to determine how many devices you need to accommodate with a single question: "What do you want to secure?" but the "how much are you printing" question is a little harder. For simplicity's sake, I prefer to suggest that the Blueprint PrintScout be deployed across all client machines and a 90-day "inventory" be taken. This tells you what kinds of devices are being used most often (network vs. local; highest-traffic devices in an area) as well as the average number of printer per employee per day/hour/min. This gives you the data to accurately determine the number of servers required. It sets the Secure Print project back a little from the calendar perspective, but it allows you to be smart about deployment, which (I think) is a better option for employee adoption and long-term success.

           

          Thanks!

          Scott

            • Re: How many collectors does a customer need?
              Nikolay Karetnikov Navigator

              Thank you, Scott!

              >> 160 inbound print submissions per minute (so, from the Windows/MacOS client)

              is that a limit per a print queue or per a host?

                • Re: How many collectors does a customer need?
                  Scott Olswold Guide

                  Nikolay,

                   

                  That's per host. But truly, even in large-scale implementations, that tends to be an unapproachable number; the highest "per minute" count I've seen personally is 95 jobs received in a minute, and that was with a potential pool of 5,000 office workers. At a separate account, I was asked to stress test a rather unusual server configuration, and for that purpose I used an application that generated a number of variable-paged print jobs over the course of a period of time. I created a session on 4 different workstations and set the application on each to print 100 print jobs between 25 and 50 pages each in a minute (the system configuration's intent was to split inbound print traffic between two servers). Aside from the obvious queuing that occurred due to network availability and the Windows Print Spooler operations on both the client and server side, there was no defect or resource issue that prohibited the successful Blueprint-side processing of the 400 print jobs (approximately 200 per server in the one minute time span).

                   

                  I hope this helps,

                  Scott

                   

                  DISCLAIMER: Stress-testing is not an indicator of system fitness for anything but extreme peak activity against any given component within the system. Sustained throughput should not approach any level used for stress-testing and should, in fact, be considerably lower.

                    • Re: How many collectors does a customer need?
                      Nikolay Karetnikov Navigator

                      Thank you!

                      So, 160 is a safety net, then?

                        • Re: How many collectors does a customer need?
                          Scott Olswold Guide

                          Nikolay,

                           

                          That number pre-dates me, so it is most likely driven by a limitation of some factor within a test-bed server. So does it really apply anymore? I cannot say. However, I can say that each time a secured print queue is accessed by a user, an instance of PCounter.exe runs to get job details. That operation is temporarily CPU and, potentially (for large files), memory intensive. By default, to preserve system availability, we only allow 5 instances of PCounter to run (you can change this if you need to), the net-net being that if a ton of inbound jobs hit the server at once you're going to get a significant backlog of files to process. And if you end up in a situation where the users pop right out of their chairs to go fetch their stored print job, you'll end up with errant help desk calls because "I sent a job, but there's nothing in my list when I go to print."

                           

                          So yes, I would consider 160 jpm a safety net. And if you push an envelope and run into a tight spot, we're going to ask you to scale it back as a test to see if there is a resource issue at hand.

                           

                          -Scott

                            • Re: How many collectors does a customer need?
                              Nikolay Karetnikov Navigator

                              Thank you, Scott! Your comments are very much appreciated!

                                • Re: How many collectors does a customer need?
                                  Nikolay Karetnikov Navigator

                                  Hello!

                                  A follow-up. You've probably heard about server-less LRS solution. This is how they put it. In fact, it is not server-less printing, but rather server controlled printing, so the actual job travels between a workstation and a device whereas to which device a print-job must travel to is controlled by the central server via a ticket like approach.

                                  Nevertheless, advent of LRS can hurt collector based systems.

                                  Are there any plans to implement a similar feature in the Pharos's products, namely Blueprint?

                                    • Re: How many collectors does a customer need?
                                      Scott Olswold Guide

                                      Nikolay,

                                       

                                      Yes, by extending the capabilities of the Beacon platform, Pharos is very near to the introduction of a truly cloud-based, serverless solution for secure printing.

                                       

                                      Scott

                                        • Re: How many collectors does a customer need?
                                          Nikolay Karetnikov Navigator

                                          May I ask, would the Beacon support on-premise installation or a private cloud?

                                            • Re: How many collectors does a customer need?
                                              Carl Conley Scout

                                              Nikolay,

                                               

                                              Currently Beacon is, as Scott mentioned, truly cloud based and is a very good fit for SMB customers or customers who are comfortable with moving their print based applications to the cloud. However, Blueprint and Beacon share certain technologies and the Blueprint roadmap does include leveraging some of the key components that continue to be developed for Beacon. This helps protect a customer's investment in their current Blueprint solution and accomodate those customers who are not at a point of moving their print solution to the cloud.

                                               

                                              We are aware of the offerring from LRS and actually have some very successful integrations with their VPSX servers at both the enterprise and global levels. But knowing that cost may be an issue with some customers, the Blueprint product team has been working on ways to reduce the cost of ownership of the an on-premise Blueprint solution from both an infrastructure and IT support perspective. We'll share progress on the development with our partners as it becomes available.

                                               

                                              Regards,

                                              Carl

                                                • Re: How many collectors does a customer need?
                                                  Nikolay Karetnikov Navigator

                                                  Hello!

                                                  Thank you, Carl!

                                                  So, as LRS solution also includes PrintRelease feature, may I ask on how VPSX and Blueprint do integrate between each other?

                                                  Is it that the Blueprint is better somehow technically or business wise?

                                                    • Re: How many collectors does a customer need?
                                                      Carl Conley Scout

                                                      Hi Nikolay,

                                                       

                                                      The Blueprint VPSX integration communicates with the VPSX servers using its API and generates a list of the user’s jobs, regardless of which VPSX server the job may be stored on, and tells the VPSX server which jobs to release. The Blueprint VPSX integration also includes the ability to import any job level data that the LRS system may collect. A single Blueprint Collector configured for use with a VPSX server has been known to handle well over 1000 devices per Collector.

                                                       

                                                      Why would a customer use Blueprint with a VPSX server? For true multi-vendor support when pull printing is required and for more granular data. LRS has its roots in data transformation - the conversion of proprietary data streams to industry standard page description languages, i.e. DJDE, IPDS, etc. to postscript or PCL. Pharos has its roots in secure pull printing. When a customer requires both then the Blueprint/VPSX integration is good choice. Another reason that a customer would want Blueprint as part of their solution is to address privacy laws. A Blueprint Collector can be installed within a given country thereby keeping the jobs within that country. A VPSX solution by design centralizes all print jobs onto a single server, typically within a data center that may or may not be within a country’s borders. Just something to consider when looking at designing a solution for a global or international customers.

                                                       

                                                      Hope that helps,

                                                       

                                                      Carl

                                                        • Re: How many collectors does a customer need?
                                                          Nikolay Karetnikov Navigator

                                                          Hi Carl!

                                                          Thank you for the answer! My knowledge on LRS confines just one presentation, but still I know LRS offers it's own pull printing for many vendors. Their approach does not require for the jobs to be stored on the central server, instead they transfer print tickets between sites sending actual jobs directly to printers. Combine that with some data transformation needs a customer may have and what is left for Pharos?

                                                          I may sound harsh but truly based cloud solutions are not for LA in Russia, yet (unfortunately)

                                  • Re: How many collectors does a customer need?
                                    Nikolay Karetnikov Navigator

                                    Hello!

                                    Scott, I've been recently thinking about stress tests for a client and vaguely recalled that we were talking about a similar subject about a year ago. Checked on the community and here it is

                                    Would you please share details on how you actually did those tests where " prohibited the successful Blueprint-side processing of the 400 print jobs". I'd need to reproduce that in my Lab environment.

                                    So far I've come up with only a batch file that sends how many documents I tell it into the queue from a single user. Anything more sophisticated you have? I'd need to simulate many users attacking a print server.