hey nd, let me ask you a couple of questions and maybe we can figure out where the problems are.
* how are the points you are sending represented? Are they maybe Point objects in java, mapped to Point objects in AS? Is it, instead, a Point "result set", for example, with an array of number or int types and then these are converted on the client into a format that the graph can digest? * how are you using the "realtime" messaging on BlazeDS? Does your app actually require that you send/receive messages in realtime, meaning server push? perhaps you're sending/receiving the whole data set without having to. * which channel are you using to transmit information and what is the interval at which it gets transmitted? * are you sending the entire data set or just deltas? * what adapter are you using on the backend? And what is the return type on the methods you are calling? * Have you determined which part is locking up the client? For example, have you timed the request/response without displaying the results to see what the elapsed time is? And, do you have dummy data on the client that you can pass to your graphing methods to determine if graphing is the problem? You can see an example of a high-traffic data-transfer-from-blazeds-to-flex-scheme on app I built called the SearchCoders/Dashboard: http://www.searchcoders.com/ download the AIR version and give it a try. We send 100 email messages to the client in just a few milliseconds. The application runs on one instance of BlazeDS configured on the non-polling AMF over HTTP channel. If you do a search for something that is likely to have a ton of messages --so, search for adobe-- and you scroll through the thousands of results, you'll notice a small delay, but nothing that locks up the application. This is data paging in action, which is just one way of optimizing the data transfer and server load. I think BlazeDS and Flex are a great combination, especially if you're sending a big chunk of data because the compact size of the AMF protocol and the native serialization you get on the client just make the application very responsive, and the automatic type serialization made it quicker to implement and less brittle and error prone than making my own xml serialization scheme. Finally, I suggest you check out Tom Jordahl's excellent presentation on BlazeDS. It's not technical, but it gives you a good, highlevel overview of what it is and its advantages: http://my.adobe.acrobat.com/p56945801/ Best of luck. /r http://www.searchcoders.com/ On Tue, Apr 29, 2008 at 7:43 AM, netdeep <[EMAIL PROTECTED]> wrote: > > I've been working for quite a while on a project to display real-time data > in a flex chart and > just can't seem to 'turn the corner' on it. While the code works, it is > plagued by terrible > performance and frequently locks up the browser. And I'm wondering if I > am just doing > something wrong or if there are resources available to navigate out of > this quagmire. > > The BlazeDS website claims it enables "Real-time server push over standard > HTTP", but what > is the expected performance for something like this? How much data can it > handle? > > I realize most charts don't require tons of data points, often needing > only 10-100 separate > sets of data to display. But for small data sets, why not just use > standard HTTP and XML? > Why bother with BlazeDS? But in my experience, BlazeDS isn't handling > large sets of data > very well. I am needing to output scatter plots for scientific data so > the data sets can be > huge. I've plotted over 140K points in some runs. But even when I filter > the data and plot > around 10K points, I get browser lockup while it loads and it takes 5-10 > seconds to produce > the chart and lately it has even been crashing on the larger data sets. > Is it the conversion > from Java objects to Actionscript which is the problem? Am I not using > the right channel? > > I realize this may be too open-ended of a question to get a specific > solution, but if anyone > knows a book I could buy, or a course available, or a more in-depth forum, > please let me > know. There just doesn't seem to be much in-depth material available for > this functionality > right now. And if there are a few standard things to check for when > dealing with messaging > or just a performant approach to real-time server push in general please > share your insights. > I am the only developer working with flex at my job and I can tell that > people here are > skeptical about my choice to make flex the front end for this application. > I'm beginning to > wonder myself if I have not made the wrong decision. The graphs we > produce look great, but > in terms of usability, no one would want to use this product in its > current state, its way too > sluggish and clunky. Sorry this post ended up so long. Thanks for the > help the others have > offered in the past and if you have any insights into this, I'd sure > appreciate hearing from > you. > > > ------------------------------------ > > -- > Flexcoders Mailing List > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > Search Archives: > http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups > Links > > > >
