 |
Quick feedback from Jazoon
Posted by fabriziogiudici on June 27, 2007 at 03:42 PM | Comments (6)
I still need some time to get to a comprehensive evaluation about Jazoon, so I will talk about the conference in general after the event is over. Nevertheless today I can say what has been the most interesting talk I've attended, since I think it will be highly unlikely that one of tomorrow's talks are better (also considering that I have to speak at two talks and I won't be able to attend other stuff in the same slots).
My favourite talk was Gregg Sporar's Integrated Profiling (with the NetBeans IDE). Well, I know the NetBeans Profiler quite well and I often use it, but Gregg illustrated some new trick that I wasn't aware of. I found it unbelievably useful: sure there are some debugging practices of mine that will be greatly improved by using all the potential of the tool. And also the Profiler in NetBeans 6 has some even new, great stuff (BTW, I've been using NetBeans 6 Milestones for months for a couple of projects, but never tried the profiler on them).
PS I've accomplished with large excess my goal of meeting more than twelve bloggers/VIP people; mostly thanks to the meeting of the JUG leaders. Also I'm so glad I've met Moritz Petersen. Moritz and I have been exchanging some emails about Java and imaging since a few months, and together with Emmanuele are planning to do something together...
Bookmark blog post: del.icio.us Digg DZone Furl Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
Integration within an IDE is overrated and it is certainly not the fastest way to solve real world performance problems unless of course you are (1) trying to flog an IDE, (2) have all the time in the world waiting for the IDE to manage and render both the source code and profiler (3) you only work on small pet store applications (4) the system context is irrelevant (workload, resources,...), (5) you have never worked or deployed into a production environment, (6) you have the source code for the appserver and all other resource managers (that explains the OS movement)....
Seriously though the integration of the NetBeans Profiler, which by the way is a nice low level code profiling tool, into an IDE is only useful for unit (code blocks) profiling and not for application profiling unless we are talking about a desktop application. The fastest way to solve a performance problem in a test or production environment is the analyze the real system as much as possible before moving to an artificial environment such as an IDE. I am assuming developers are not allowed to connect their IDE's to a production application.
William
Posted by: wlouth on June 28, 2007 at 06:18 AM
-
Well, if developers aren't allowed to connect to a production system, there's nothing a tool can do - it's a policy issue. But technically it's possible, as you can attach a profiler to a running, external Java process - I believe that with Java 6 you don't ever need to start the app with the special profiling command line options. And since NetBeans let you instrument only a portion of the application, you can control the performance penalty.
Anyway, I think I'll go deeper in this a post a webcast as soon as I have some time.
Posted by: fabriziogiudici on June 28, 2007 at 08:16 AM
-
I would say that one should analyze and profile their applications before moving to a test and especially a production environment, and having these things integrated with the IDE instead of a separate application is even better. The production environment is certainly not the place one wants to figure out whether the system will support a a certain load or not. Having metrics on areas of code should be very useful for anyone wanting to know how much CPU time and memory will be used in various code sections of their software as this can tell you ahead of time which areas are your bottlenecks and what will more than likely cause you issues. Memory leaks are certainly issues you want to know about before you move into production.
Then there is the testing environment. Mainly there are two types of testing environments, each for different things, one which is used to run unit and load tests and the other for user acceptance and to make sure the use cases are properly supported per specifications. With user acceptance and cases not exactly being when you want to learn about memory leaks and code with bad performance as you want to spend your time on the specifics of design and not easily detectable combinations of load and memory usage which may not crop up without unpredictable users. So, you want to spend your time on these things and not the things you could have caught with a profiler, many memory leaks and poorly performing code , had you taken some time up front to profile your code on a development system while running the unit and load tests.
Posted by: wadechandler on June 28, 2007 at 09:54 AM
-
Hi Wade,
I agree production is not the starting place for software performance engineering but I hope you do agree that for most Java EE applications the performance problems that do occur are related to concurrent workload patterns and volumes and less so on the actual execution of a some enterprise bean code unless of course this bean is invoking a high number of transactions and data access (or messaging calls). This is what is referred to as the software execution model. An IDE is not a requirement though I can understand it does makes things somewhat easier but the benefit is largely overstated in my experience and can in fact be counter productive when developers, testers and operations staff are forced to use different tools and models (software vs system) for data collection and analysis. From my experience developers using an integrated profiling tend to fall into the trap of premature code optimization instead of aiming to build and maintain a software performance execution model across releases and application life cycle phases.
Note: The system execution models which is derived in part from the software execution is based on real or expected operating conditions and is focused on behavior of service queues (request pipelines, data sources, connection factories....) under varying workloads.
William
Posted by: wlouth on June 28, 2007 at 12:24 PM
-
I have a few comments over in this entry.
Posted by: gsporar on June 28, 2007 at 01:03 PM
-
i would like to do a project for my final year that is almost like one specified within the projects currently being worked on. The project is to use mobile phones to access a computer and to start and shut it down. another idea i got is to do transactions using my phone eg transfer funds to other accounts or buy good using my phone by contacting my bank
Posted by: benniwas on June 28, 2007 at 11:10 PM
|