At this point pretty much everyone knows that Twitter has become a critical business communication tool. Right? And as an increasing amount of business users -- everyone from independent consultants to CEOs and even corporations such as Comcast -- are using Twitter for branding or engagement of some sort, the Twitter user base is skyrocketing. Right? But that's OK because aside from Twitter's own stability issues, the rest of us users can continue to tweet and direct message and brand our little hearts out without worrying about our own network stability.
Twitter's roughly 2 million user base is growing at an estimated monthly clip of 6 percent. A large portion of those 2 million users are likely the business users I mentioned above. And, as a considerable amount of those business users are on company-sanctioned Twitter time, there's a whole lot of microblogging traffic flying through company networks. As with any application (relative examples being IM and other P2P), even too much unaccounted-for Twitter traffic could affect your company's network performance. IT managers need to discern how much network traffic his or her networking devices can handle before making a purchasing decision and subsequent deployment. Especially in companies with excessive amounts of social media-savvy users, these IT managers are likely already asking their networking vendors about social networking application traffic.
Because the Twitter phenomenon for businesses is still relatively new there's a good chance that many of the currently deployed networking devices have not yet been tested using Twitter traffic. BreakingPoint, a testing systems company that creates tools for network equipment manufacturers, today announced (via a Twitter press release) a new application protocol that the company claims will allow network equipment manufacturers -- including those who develop routers, switches and security appliances -- to test the boundaries of their future products against real-time Twitter traffic.
I did a quick Q&A with BreakingPoint developer Todd Manning, who created the Twitter application protocol, to find why this testing is seemingly so important.
Q. [Jennifer] How important is testing network device performance with apps like Twitter?
A. [Todd] If you're interested in testing networking gear, especially equipment that does any kind of deep packet inspection such as IPS equipment, it is important that the testing you do reflect, as closely as possible, the real kinds of protocols and applications your network actually sees. By simulating realistic Twitter clients, the Twitter AppSim protocol (AppSim is the feature within BreakingPoint testing platform to test with the different application protocols) will send packets that match the sizes and content you would expect to see in a network where real Twitter users are active.
Q. What other "social networking" apps would BreakingPoint consider supporting for testing?
A. The first candidates for social networking applications would be those requested by our customers. The development team has a list of protocols we are working on, but if a client came to us with a need to simulate some specific application, we would want to accommodate that need quickly. This actually happens all the time around other applications and we typically can deliver the protocol for testing in a day or so. Since most social networking applications like Twitter are really just riding on top of HTTP, it would be simple to add.
Q. So can this actually help Twitter’s performance issues?
A. The current implementation of AppSim works for testing inline devices, such as IPS, routers, and switches. If Twitter performance issues are related to this type of inline equipment, then using a BreakingPoint box to test that equipment would definitely help. BreakingPoint’s Twitter support is geared more toward use by service providers and equipment vendors that need to test the performance of their devices using realistic application traffic.
Q. What does it mean that you guys are testing with “real” application traffic? Why is that so important?
A. Testing with real app traffic means that the BreakingPoint testing platform is doing more than just blasting random bits onto the wire. With AppSim, we're simulating realistic content in our TCP sessions. HTTP clients look like real clients, meaning they act like Mozilla, Safari, and Internet Explorer; HTTP servers look like Apache or IIS. Our protocol implementations allow users the ability to tune the traffic to resemble the traffic their real networks see. This means that when a customer tests a device, they know the performance they are going to see out of that device when they deploy it out in their live network.
Q. Is BreakingPoint using a different method to test performance against Twitter client traffic than it does to assess IM client traffic?
A. No. The testing method is the same for all protocols. We implement actions for both the clients and servers of all the supported applications. This allows customers to mix and match any number of applications in a single test, which is a requirement in order to support our goal of generating realistic application traffic.
Q. Does this apply only to client users? Meaning, if an employee is using Twitter via the Web version, is that traffic on the network considered?
A. The BreakingPoint Twitter implementation currently behaves like Twitter API clients. We don't currently simulate the traffic that is generated by users that browse the twitter.com website directly. If a BreakingPoint customer wanted to add this type of traffic into their AppSim test, they could easily add custom HTTP requests that simulate this traffic.
Q. Is this a result of demand from companies who use your products? If so, can you name any?
A. Actually, the decision to add Twitter was a joke I made in a meeting about what protocols we were deciding to add. BreakingPoint's marketing group makes heavy use of social media, and Twitter in particular, so I joked that they would be overjoyed to see Twitter support. Everyone actually thought it was a good suggestion. The joke was then on me to go implement the API. AppSim actually simulates both the client and server traffic, so I had to go take a look at how their servers respond to each of the API calls, which can be in up to four formats.