Today’s episode takes us behind the scenes at PathSolutions...
When wandering the halls of PathSolutions’ lab, you never know what you might find. From white-coated scientists exclaiming, “It’s Alive!” to an employee in a blue shirt crying, “He’s dead, Jim!,” or a quaking red-haired marketing assistant exclaiming, “Meep!” when asked to demonstrate a new feature. There’s always something interesting to be found…
A Lesson in High Performance Network Monitoring
A common concern among network administrators (especially if they’ve tried other products) is exactly how much bandwidth is needed or used for monitoring the network. In our lab tests, we’ve noticed a drastic difference between the bandwidth and resources used by PathSolutions versus the competition.
SNMP GET Requests
Network management products typically use the SNMP protocol to fetch statistics from networking equipment. The network monitoring tool sends a “GET request” to the SNMP agent function residing on the router, switch, or other network equipment, asking for information from the agent, such as temperature, CPU Load, Traffic Load, etc. The agent in the network monitoring equipment then looks up the requested information, and returns it in a “GET response.”
In our lab tests, we found that other network management products nearly always use one “GET request” packet for EACH piece of information they want to gather from the network equipment. This means that if you ask to monitor 28 different items (CPU, Memory, Link Bandwidth, etc), this will result in 28 separate “GET request” packets being sent to the network equipment, which then replies back with 28 separate response packets.
The Grocery List
The key to achieving performance (whether in speed or ability) when scaling to even very large networks is efficiency. When you go to the grocery store, you bring a list and make a single trip. Nobody I know makes 28 individual trips to the store to buy one item at a time, especially when their vehicle can carry multiple items stuffed in multiple grocery bags.
Given the scenario we started with, instead of sending and then receiving 28 separate packets (mostly filled with empty space), PathSolutions sends a single “GET” packet containing a “grocery list” of the 28 items that it wants to monitor. In turn, it recieves a single packet back, containing all of the information on the “grocery list.” Instead of 56 packets crossing the network, the entire transaction only takes 2 – the PathSolutions transaction is 28 times more efficient in using packets.
Graph A & B: SNMP Traffic, 48-port LAN Switch (Smaller is Better)
PathSolutions: >28 times less packets
PathSolutions: >5.9 times less bandwidth
Ah, but aren’t the lists larger packets, you ask?& PathSolutions typically uses packets about 512 bytes in size. Other vendors place a handful of bytes in a single packet, and then have to place empty padding in the packet to bring it up to the minimum 64 bit size. In terms of bandwith, PathSolutions uses 1024 bytes of bandwidth (512b ask + 512b response), while others use 3,584 bytes (28x 64b ask + 28x 64b response) for the same response. In terms of bandwidth, that makes PathSolutions 3.5 times more efficient.
The numbers get even more impressive when you are getting statistics from a multi-port device, (after all, how many of us have networks built entirely with 1-port ethernet switches?). A single PathSolutions request for 28 port statistics sent to a 48-port switch results in 48 neat and organized packets returned in response. In the same scenario, a popular competitor sent 28 requests, and received 1,344 (28x48) separate responses! It doesn’t take a mathematics Phd to see that 49 (1+48) is FAR more efficient than 1,392 (28+1,344) packets, and 14,848 bytes is FAR less than 87,808 bytes. (See Graphs A & B.)
Now imagine this scenario where you are monitoring a very large multi-site network, and the monitoring traffic is traversing expensive WAN links, sharing bandwidth with performance sensitive data. You can see why PathSolutions monitoring goes where our competition fears to tread.
What Do You Call that Feature? Um, Efficiency?
At one point here in the lab, there was an intense discussion between marketing and engineering. An enthusiastic marketing person asked, “What do you call that feature? We should brand it!” The response from our engineering department was classic. “What do we call that feature? Um, EFFICIENCY!”
I can just see the new brochure from marketing: “Path Solutions, Monitoring Your Network with Um, Efficiency™. (Facepalm follows).
