We're running 250 reporting end-points across our firewalls, data center switching, the SD-WAN deployment, and our branch and campus switching — all off a VM. If I was going to run any more than that, I would probably look at a hardware appliance or a distributed model.

We don't currently have plans to increase usage, but our organization invests in a lot of other organizations and that's when we would use it more. For example, in 2016 we bought another financial organization and we had to deploy to another 10 branches with 20 appliances, plus switches. It just depends upon what the business requires. I've got good visibility across my entire environment at the moment.

In terms of scalability, Plixer Scrutinizer is an excellent solution for enterprises. It's not really for SMBs. It scales very well for enterprises.

The scalability comes from Plixer's ability to have different log collectors. You can separate the database collection point from the log collectors. You can also have different database points as well, and roll those up. That seems to be very scalable. Although, to be fair, I didn't have to scale mine up that much for 63 devices. I just have the one device which is also the log collector, so I was able to keep it all on one server.

We do not have plans to increase its usage. The majority of current usage, about 80 percent if not higher, is as a first-responder type of setup. If we have a problem, Scrutinizer is almost the first thing that we look at to determine what's going on, traffic-wise.

Plixer Scrutinizer is an extremely scalable solution. It's known for its scalability which was why the customer selected Plixer Scrutinizer.

Plixer Scrutinizer is a highly scalable solution. Scalability-wise, I rate the solution an eight out of ten.

Plixer Scrutinizer allows its users to monitor more than 100 devices.

My company's clients who use Plixer Scrutinizer are mostly enterprise-sized businesses and a telecom company.

I haven't ever used more than a single collector. So, I've never really tried to scale. My quantity count for device input has always been below a 1,000. Thus, I have never pushed the box to its max.

Out of IT, there are about eight technicians who either configure debt flow on a device or are directly effecting a ticket. After that, we have about 40 to 50 end users that view data to understand their own areas of the network in the different regions, such as Asia, Europe, etc. These are IT professionals, but they are monitoring, not networking. For example, "What's my internet usage? What's my MPLS usage, so I can see how my site's doing?" It's become more of an overview.

We are not really looking to create any new usage. In fact, we've pulled back some of its usage only because we have gone away from traditional MPLS and routers and onto an SD-WAN solution that already brings onboard its own version of the same metrics. Therefore, we've reduced the number of inputs to it, but we're almost topped out there. 

That's pretty much our way in infrastructure. It's pulled back from the use of NetFlow. NetFlow is still being used for most of our major Internet connection points over the globe. It probably still is being used on all of our ties with other vendors, as they're private lines into our company. Also, it can be anything at the data centers that use traditional networking. So, we're not really growing it. It's not really shrinking anymore, but it was. Last year, it shrunk by quite a bit.

We are primarily a retail shop. We have a lot of little stores which used to be part of a much larger network. Those are all SD-WAN now, so they're not seeing anything with Scrutinizer. However, it's still on all of our Internet lines. So, it's pretty stagnant and stable.

It is easily scalable. I haven't seen any issues with it.

It is in full production. It monitors several firewalls, like Cisco Firepower, and IPS.

We only have three users who are using this solution as end users. We are all network administrators. It gives anybody within our group the ability to troubleshoot it easier.

It's scalable. They're coming up with a new way of scaling up. Ours is an appliance but I believe their VM products may be scalable. As far as we are concerned, all we need to do is increase the storage, which we can do by replacing a hard disk.

We are collecting data and the network traffic from almost 70 offices throughout the U.S. If everything goes well and we have the opportunity, we will probably try to increase the Scrutinizer footprint. But right now we're okay with what we have.

It is very good. It's very scalable, as long as you have their license.

There are no more than 10 people who have access to the solution. We have 10 to 15 administrators with accounts who are technical. 

Two network administrators are more than enough for deployment and maintenance. Usually, one network administrator is taking care of this. Sometimes, I'm backing up, but otherwise, only one person is necessary to manage it.

The solution's scalability is struggling on devices with a large number of flows.

ACI from Cisco, and not the Data points. Data points are improvements to how data is stored or archived. I've noticed that the solution is inconsistent on devices with a large number of flows, such as core switches for Data centers, or Cisco ACI.

To rephrase, the solution is suitable for a brand router or an internet switch, but it is not suitable for, at least in our environment, a core switch within a data center where the number of flows and communications will be high. From what I understand it is that the solution is not very scalable in a high volume traffic environment with a large number of flows.

This solution is used directly by 50 people in our organization. Most of the users were network engineers.

The solution received positive feedback. The usage was already on a daily basis. No further increases were anticipated or planned, but it was used extensively throughout the organization.

The scalability is excellent. It more than meets our needs. We had a certain size and we've had no problems scaling up and down.

It's scalable for what we need. It has a lot more functionality than what we use. We can distribute the collection engine and some things like that, but we're not using that because we don't need to. It is there if we do need it.

There are varied roles across different teams. There are about 20 users, in total, who are mainly network operators.

My personal impression right now is that we've reached a limit, or we are near a limit of flows per second, because we see that our system is getting quite slow. I suppose it's a hardware issue, not an issue of the software.

The actual size of the network is above 3000 users.

We have a rather large network and it can cope. So it is scalable. We're running somewhere in the region of about 40,000 active devices, which is rather a lot.

We don't have plans to increase usage. That would depend very much on the university rather than me. I'm happy that the current implementation of Scrutinizer will take what we have right now. We may have to go to a multi-deployment model if we increase our usage dramatically, but within the scope of the next five years I think we'll be fine.