I spent quite a bit of time this week studying a customer testcase to prepare some recommendations on how to improve the network traffic of their three-tier BC4J/JClient application. When building an application that is meant to run in 3-tier, it's advisable to test and profile the network traffic of your application early and often to catch yourself when you write code client-side that should be placed in your server-side components (generating unnecessary round-trips in the process).
JDeveloper has a built-in event profiler that helps you understand the nature of the problem. The screenshot below illustrates the project-level profiler settings that you can use to tune what event information the profiler shows you. Here we've asked it to only display VM garbage collection events (GC) as well as BC4J Remote Method calls. 
We demonstrated that by ripping nearly all code out of their JClient thin-client forms, and pushing the "work" into their middle-tier application module, we were able to rebuild a form of similar complexity, UI controls, and number/types of JClient bindings which brought the number of thin-client-to-appserver roundtrips down from over 100 in their example to 15. The form comprised 4 panels with six poplists, two JTables, and some text fields: a total of nine view objects involved in the data model.
I plan on taking the tips that were useful to this customer and publish some kind of generic JClient/BC4J performance "best practices" whitepaper that captures the essence of the advice we sent to them without revealing any specific details of their data or application.
In JDeveloper 10g (9.0.5) we have worked even harder on a new "Batch Mode" that allows us to batch up even more of your operations in a single roundtrip, so hopefully in 10g, those 15 roundtrips at form startup will be able to be counted on one hand (or a few fingers).
In the case of JDev 9.0.3.3 that we used for testing, here's what the event profiler showed us for the final, optimized example Swing form... 
2:25:00 PM 
|
