Accurate understanding of an application’s behavior helps ensure that it will not suffer from construction and performance problems.
eoSense is a runtime analysis tool that uses framework knowledge to explain application behavior, automatically detect performance issues and validate construction by modeling the application’s dynamic operation. eoSense version 2.5 has now been released with support for Apache Tomcat.
eoSense visualizes, traces and monitors a range of architectural components and services running on Tomcat: Spring, Servlets, Struts, JDBC and JNDI. Dynamic modeling of these services enables automated validation for the purpose of detecting patterns of misuse or bad practices. Detailed performance timing information for each service is available. Precise method and member variable tracing for any set of classes can be added using a few clicks. Analytics provided by eoSense are flagged very obviously at the model level; you can then drill down to source level causes. As a result easily missed problems that might otherwise only come to light during load testing or after deployment can be found before the application is under stress.
eoSense 2.5 adds support for Tomcat versions 5.0, 5.5 and 6.0, in addition to existing support for WebLogic 8.1,9.1,9.2 and 10 and WebSphere 6.1.
More informaion on eoSense visualization and monitoring for Tomcat can be found here
This appears to be a commercial product, but I can't see any pricing on the site. Is this a $10 product or a $100,000 product or somewhere in between? This is a major factor that determines whether I will even consider evaluating the product.
Thanks for your interest in eoSense. We are experiencing a large number of requests for evaluations since the announcement on TheServerSide.com.
You are correct, eoSense is a commercial product and like most software vendors our pricing is dependant on type and volume of enterprise usage.
If you would like an initial view on the pricing that might apply to your specific requirements please feel free to call us in the United States on 617 217 2814 or internationally on +44 1506 592247 and ask for sales.
I can assure you that our pricing is not in the $100,000 category.
I hope that this helps and look forward to supporting your evaluation.
"Java Servlet technology provides Web developers with a simple, consistent mechanism
for extending the functionality of a Web server and for accessing existing business systems."
How would you compare eoSense with JXInsight from JInspired ?
eoSense contains a lot more Java EE framework knowledge than conventional APM or profiling tools. Using Derived Model Analysis
we are able to provide Java EE framework knowledge in a way that helps find and understand problems in software systems built with those frameworks.
By using Java EE knowledge, eoSense differs from APM tools and profilers in 2 key capabilities:
1) The dynamic modeling of application architecture enables eoSense to provide a real-time visual explanation of what is going on inside an application server. The ability to visualize architecture helps users see through framework complexity and allows problems to be detected directly.
2) Triggered queries execute against our dynamic model to provide runtime error checking for architectural problems. eoSense has a catalogue of construction problems and bad practices that we can automatically flag as Alerts. These can be a lot more sophisticated than monitoring whether a call takes longer than a pre-set threshold. We Alert: incorrect/poor resource usage, unused requested data, redundant data requests within the same user interaction, invalid component usage scenarios/calling sequences, inappropriate transaction usage ... and so on.
"conventional APM or profiling tools"
Conventional. That is the first time some one has stated that about JXInsight.
"The dynamic modeling of application architecture enables eoSense to provide a real-time visual explanation of what is going on inside an application server"
JXInsight has had a software and system execution model and class meta model since the beginning long before eoSense. This is how we are able to associate (runtime analysis) inspections and graphical symbols with traces, transactions, diagnostics, object state models, metrics......
Did we use this model to create a debugger/replayer? No. Because the overhead both in terms of the runtime and human analysis is horrendous for anything other than a simple petstore application. You would not be able to find a performance problem (except for low hang fruit) or concurrency issue never mind attempting to run beyond a development environment.
There is no point is providing "real-time visual explanation" when it is not real-time because of the overhead being huge which it is. This is the conclusion reached by customers that have evaluated both products even though I would not view them comparable at all - like comparing a debugger with a profiler (which we are not necessarily).
What I find surprising about false marketing claims is that the tool and others alike have still not even managed to come close to what our first product, JDBInsight, offered in terms of transaction analysis. I would have thought that the most important enterprise technology to understand and analyze would be JDBC and the SQL transactions and statements flowing through this API. And I am not just talking about whether a statement is closed but whether the transaction semantics for a business transaction have been mapped accordingly to one or more resource transactions.
It looks like an interesting intelligent (framework wise) debugger but certainly not a APM or profiling solution - convention or not.
Gordon I think the next time you get someone from your company to contact us via a gmail account about pricing for JXInsight you might want to find out more about the product and it technologies in the first place.
eoSense aims to detect application problems as early in development as possible. But just because eoSense can be used in development doesn’t make it a debugger. The product embodies a wealth of knowledge relating to good enterprise architecture construction which takes it way out of the traditional debugger space.
Traditional APM tools are often used to detect problems during load testing or as a last resort in production environments , but that is a bit late in the day to be finding an application problems isn’t it? eoSense provides a way to find these problems earlier. The earlier a problem is detected the less it costs to resolve.
The fundamental difference between eoSense and traditional APM tools is that eoSense focuses on finding problems by analyzing instances of user interactions. By clearly analyzing and presenting the operation of a single request we can highlight problems in that operation directly. (Although the analysis of some problems within Java EE frameworks clearly requires the examination of thread contention, which we can also visualize and detect)
The impact of our real-time visualization is highly configurable. It is quite possible to run without the overhead of runtime visualization, store the event output and then visualize later. Or to frame-slip at selected rates to limit updates. And if the monitored sever is remote then the real-time visualization (and it is in real time) is processed in parallel.
Also worth mentioning is that, contrary to your comments, transaction tracking, tracking of enlisted resources, tracking transaction initiators and affected components and relating these to client transactions is a key eoSense feature, supported both at the event level and visually and with associated alerts.
While eoSense is not an APM tool solely focused on monitoring production environments, it is never the less often used to either diagnose known problems in production software or to audit delivered software systems. We have an advantage over conventional APM tools in these areas because our detailed analysis allows the automated diagnosis of problems that may have been indicated by other tools and dashboards, but they have not collected and analyzed enough information to resolve the problems.
eoSense clearly isn’t the only way to find applications problems. But it provides a reliable way to automate the process of performing runtime analysis for Java EE to improve software quality by detecting bad practice. In the same way that memory analyzers automate error detection in C/C++ programs, eoSense automates error detection in Java EE.
@Confused "...contrary to your comments, transaction tracking, tracking of enlisted resources, tracking transaction initiators and affected components and relating these to client transactions is a key eoSense feature, supported both at the event level and visually and with associated alerts."
I said resource transaction and I also mentioned at the same time SQL which should have been clear enough to most in the context of database transaction analysis and tuning. I did not mention JTA/JTS which is applicable to other technologies and not just JDBC. The top features on each of the following pages highlights this.
@Unsubstantiated "We have an advantage over conventional APM tools in these areas because our detailed analysis allows the automated diagnosis of problems that may have been indicated by other tools and dashboards, but they have not collected and analyzed enough information to resolve the problems. "
Sorry but problems in production cannot be solved by solutions that cannot run in production. For this reason we have a number of different and extensible technologies for each life cycle stage trading overhead, footprint with data collection and analysis.
Again I think this is an interesting tool in the similar vein of static code analysis but with a runtime perspective and knowledge modules for frameworks. But it is not in anyway comparable to APM solutions some of which can be used during development, test and production and offer cluster wide analysis along with distributed tracing. It is a quality assurance tool but not a solution for software performance engineering or application performance management and/or monitoring.
The P in APM is for performance which is certainly not what is normally attributed to debugger/replayers. If I am completely wrong on this then please post some benchmark results preferably SPECjvm2008 and SPECjAppServer with complete application/driver code base coverage.
I am surprised by your statement that “problems in production cannot be solved by solutions that cannot run in production.” Most application production performance problems originate in development, and that is the best place to nip them in the bud.
You have missed the supporting features in our product that apply in development and production:
We do support clustered operation and do have very significant support for distributed operation in general.
We can present a single model of an application using information integrated from any number of servers including distributed application tracing.
We are used throughout the software lifecycle, from early development, through testing, production and maintenance.
We provide full monitoring of JDBC.
Hope this helps,