Alluvio AppResponse Reviews

AppResponse is for packet capture and analysis. I focus within public sector customers, state, local, and education.

I sell it; they buy it. Improvements depend on the enterprise and how they're using it specifically. They're capturing packet data and using other tools to help analyze it.

We are the partner of Riverbed. Once any customer buys the Riverbed product, we deploy and configure it to meet their use cases. Alluvio AppResponse can identify if a page or an application is slow and determine whether the issue is from the network side, server side, or application side. It's deployed adjacent to the core switch, where it spans the traffic and collects it. Then, we define the applications by name, URL, and port through which the application traffic is coming.

With Alluvio AppResponse, there is an in-built analytical analysis with AI and ML, which identifies and provides data such as the number of TCP retransmits, web access time, total connection time out, total connections established, and server-side errors. The RTCC response time composition chart is crucial because it helps pinpoint the issue's origin, whether from the server, network, or application side. It's a superb product when compared to SolarWinds SAM, which is agent-based, while Alluvio AppResponse captures all traffic from the core switch.

AppResponse is a device for network and application performance monitoring. It enables you to trace all transactions and connections and troubleshoot issues with the network, applications, and databases.

AppResponse is a total solution that gives you end-to-end visibility into applications at all levels, from Layer 1 to Layer 7. We can trace all those sections: physical, IP, transport, presentation, application, etc. It gives us the full picture.

We use Alluvio AppResponse to look at application response time between our servers and our actual end users.

Alluvio AppResponse has helped us with regard to some of our application projects. We utilize the solution to monitor response time between service and application endpoints.

We use the solution for application performance, as well as capacity. We also use it for debugging. As we have a packet, we can look to this should the need arise. 

This kind of question is nonsensical to me since the tool is selected based on the service it is supposed to provide. No tool is simple, in as much as they all require certain competency skills. Firstly, a proper and wide range of the IT system is required. Secondly, there must be sufficient time to learn about the format of the tool, how it is designed and how it must be used. This applies to every tool, be it APM, NPM or SIEM. With this in mind, it is up to the user to have the competency and requisite knowledge of the landscape and system so that he may use it properly. 

Of course, there are certain tools which have, lets say, a nicer dashboard than others, such as Dynatrace. But, the dashboard is merely an extra service provided by the tool. The actual purposes of the tool and its attendant advantages is not the dashboard. It is to provide intelligence for understanding and analyzing the traffic and for reproducing and doing synthetics.

Really, this question comes back to the person involved, the one who purchases the product and defines its need. 

Very easy to use and gather value from the start. Easy to deploy on servers with little impact. Easier to gather information from the Server than from the Network Switch when there are multiple servers to combine for an application study.

Marketing is complex and not well understood, so often this product is not considered a good fit just for a surface look. Applications are getting more complex as there are islands of services that are combined to provide value to the customer. The response time delay is hidden within service calls that are being made. This family of tools provides the insight needed to know where that response delay is happening. It also provides insight as to the number of service calls that are being made. While each service call may be short, doing 1,000 of them, brings major delays to the overall response time. Finding where that delay is happening is key to improving the application. These tools provide that insight and provide the ability to show the total response time that is taking place. As a side note: Often I used the Capture side of the product more than the Analysis side of the product. The ability to do captures without having to use tcpdump on each system is very helpful. This ability takes the grunt work out of gathering the basic information that is required for deeper analysis.They (Opnet) also use Wireshark in their analysis phase and then add even more analysis for some deeper dive information. This is helpful for general analysis. Also some of their decodes have been helpful as well.

We use Alluvio AppResponse for monitoring websites with the help of web transaction details. It also provides good network performance and application manager visibility.

Alluvio AppResponse monitors the entire packet. It provides us with complete visibility of every packet, and we can get the average response time from the back-end server. If you want to get detailed monitoring, AppResponse is a great solution.

The biggest problem of end-to-end Application Performance Monitoring (APM) solution is that service assurance is mapping a problem to the appropriate team. When the business units check their jobs, step by step, every single system seems to work properly but they need to check the big picture, which AppResponse does easily.

The application response time is very user friendly. With some APM solutions, it can take a long time to check a periodic report, but you can get all the necessary details quickly with AppResponse.