Perhaps messaging has some overhead that Remoting doesn't? Messaging should still be using AMF3 so that is probably not where the bottleneck is. You might still be able to add the same benchmarking stuff to the underlying channel on the Consumer.
-James From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of netdeep Sent: Wednesday, March 26, 2008 10:00 AM To: [email protected] Subject: [flexcoders] Re: blazeds performance Thanks for the reply. Since you were pulling down 20K rows in less than 2 seconds in the benchmark app, it seems like I am certainly doing something wrong. I looked at the benchmark app and tried to emulate the way you measured the performance, however it looks like you are doing things a little differently from the way I am. You are setting up a channel in your code: var channel:AMFChannel = new AMFChannel(null, "messagebroker/amf"); channel.netConnection.objectEncoding = ObjectEncoding.AMF3; var channelSet:ChannelSet = new ChannelSet(); channelSet.addChannel(channel); ro.channelSet = channelSet; channelSet.messageAgents[0].addEventListener('acknowledge',loadDone); But I am just using a subscribe with a consumer: <mx:Consumer id="consumer" destination="factory" message="messageHandler(event.message)"/> I tested the time between when messageHandler is first called and when it is finished drawing and it is 52 seconds. I'm not sure if that includes the load or not. I'm not sure how to actually test the performance since I can't grab the start time from before the message is sent since the message request does not originate in my code. One thing I was also wondering is whether or not I am defining the channel properly and using blazeds or perhaps some other protocol. Here's how I set it up in my messaging- config file: <adapters> <adapter-definition id="TCgateway" class="factory.ReportManager"/> </adapters> <destination id="factory"> <adapter ref="TCgateway"/> </destination> And ReportManager is just an instance of ServiceAdapter: public class ReportManager extends ServiceAdapter { public Object invoke(Message message) { .... } } --- In [email protected] <mailto:flexcoders%40yahoogroups.com> , "James Ward" <[EMAIL PROTECTED]> wrote: > > You will probably need to do more research to determine where in the process the bottleneck is. Check out my Census Benchmark app to see what the different parts of process you can measure (right-click to get the source code): > http://www.jamesward.org/census > > My guess is that it's not blaze that is slow but the data transformation and display of the data in the charts. > > I hope that helps. > > -James > > > > ----- Original Message ----- > From: [email protected] <mailto:flexcoders%40yahoogroups.com> <[email protected] <mailto:flexcoders%40yahoogroups.com> > > To: [email protected] <mailto:flexcoders%40yahoogroups.com> <[email protected] <mailto:flexcoders%40yahoogroups.com> > > Sent: Wed Mar 26 05:27:37 2008 > Subject: [flexcoders] blazeds performance > > I am wondering if anyone has an idea about increasing blazeds performance. I am receiving > information from a database for a chart. Each record is a java object and the entire set of > aproximately 180K records is contained in two separate arrays since it is a multi-series > chart. I convert the records into actionscript objects from java objects when I get them. > From the time the records are sent to the flex app, til the time they get drawn on the screen > takes approximately 45+ seconds. This seems pretty long to me. Is this on par with what > should be expected? If not, what could I do to improve this performance? >
<<image001.jpg>>
<<image002.jpg>>
