Nelz's Blog

Mah blogginess

JavaOne - Day Two EOD Posting

TS-9235 Stress Testing your Web Apps

There are basically three big learnings that I pulled out of this session:

  1. Stress testing takes a lot of planning and resource (time). You can’t just shoot from the hip and have a great stress testing. Estimating from the hip right now, I’d say that at my last job we would have needed at least 1/2 of an FTE to get the whole system set up and maintained sprint after sprint.
  2. Just saying "stress testing" is not enough, since there are so many sub-concepts to that… You have to be really specific in what kind of stress tests you really want to do.
  3. Stress testing should be a major piece of architectural decisions. Your architects can’t just be doing white-paper evaluations, you should prototype everything, throw them up on some kind of sample server(s), and go at ‘em with some kind of automated load. This is the only way you can make real, educated decisions.

Also:

  • make sure you define what a "user" is and have all the different types of users in your tests
  • don’t just test the "normal" path, also include the more "corner cases" in your performance tests, as this is where bugs like to hide
  • use "real" data whenever possible
  • if you are using JMeter, don’t use the "real time" analysis. Save those cycles for the load, save off all the data to flat files, then import them to a spreadsheet program for analysis.
  • look into "JChav" as a tool to help…?

TS-6410 Hand’s On DWR

This presented a very pretty way of doing AJAX-type of stuff, but I wasn’t overblown and enamored with it all since I had just seen the GWT stuff the session before this one… (I’m doing a separate blog post for that after this one…)

I like it when frameworks identify conceptual scopes outside of the standard (application, session, page, request) ones. DWR has identified a "script-session" scope.

I did like that DWR prescribes to the "UNIX-model": "do one thing, and do it well", and integrate well with others.

BOF-9587 Static Analysis

(That’s not the really pretty name they titled it, which was something like "Pimp my application"…)

Basically, this session re-iterated a bunch of the tools I already knew about.

Structure Tools:

  • JavaNCSS
  • JDepend
  • Dependency Finder
  • Classcycle
  • XRadar (as an aggregator)
  • QALabs (as an aggregator)

Bug Finding:

Audience Member Suggested:

  • ? Macker ?

(Note to self: Look into "Hudson" as CI server?)