Thanks for the link. The wrapper serializer didn't seem to speed it up much at all...maybe 5 seconds. I think we are going to have to re-design our approach. The data I was going to keep in memory on the server was "Catalog" data...data that doesn't change much at all if any. I'm thinking we will be better served to store this info on the client machine, reading directly from the DB when the app starts under a worker thread.
Message from "Potter, Mark S." <[EMAIL PROTECTED]>@DISCUSS.DEVELOP.COM received on 10/05/2005 09:09 AM 10/05/2005 09:09 AM "Potter, Mark S." <[EMAIL PROTECTED]>@DISCUSS.DEVELOP.COM Please respond to "Unmoderated discussion of advanced .NET topics." <[email protected]> Sent by "Unmoderated discussion of advanced .NET topics." <[email protected]> To: [email protected] cc: Subject: Re: [ADVANCED-DOTNET] Remoting speed Also please see Improving DataSet Serialization and Remoting Performance http://support.microsoft.com/default.aspx?scid=kb;en-us;829740 -----Original Message----- From: Unmoderated discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Heath Sent: Wednesday, October 05, 2005 10:01 AM To: [email protected] Subject: Re: [ADVANCED-DOTNET] Remoting speed + dataset version 1.1 serialize its parts to xml although you would have specified to serialize it binary... // Ryan On 10/5/05, Peter Ritchie <[EMAIL PROTECTED]> wrote: > What's the data source? Are you getting one record at a time from the > remote object; or are you receiving a dataset object? How big is each record? > > An extra 30 seconds for remoting doesn't seem all that bad. If you're > passing a dataset object over the wire (I'm assuming you are), it might be a > bit on the high side. If you're sending 1 record at a time, quite > respectable. If your DBMS is communicating over TCP as well, it's using the > same bandwidth that your remote object is and you're performance will be > coupled to that. > > I don't know what the expected throughput of TCP is when not going over the > wire; but, it still goes through the stack so it's still coupled to the > throughput of data going over the wire. If you yanked your cables you might > see a bit of an improvement. > > If you're concerned that 30 seconds is a bit high, you could using something > like Ethereal to see what is actually being sent and tweak the design, if > you can. > > On Tue, 4 Oct 2005 19:12:23 -0500, Franklin Gray > <[EMAIL PROTECTED]> wrote: > > >using TCP, binary and port 999, I've been experiencing data loading speeds > >7 times slower. Does that sound about right? > > > > > >Details: > > > >I read 30,000 records into a datatable when the remoted object get created > >(just once....singleton). > > > >When I open the form with the grid on it, I call the remoted object to get > >a copy of the dataset and load that copy into the grid. > > > >To cut out the network, I ran both the client and server objects on the > >same machine. > > > >If I run without remoting, the loading of data takes 4-5 seconds. If I > >run with remoting, it takes the loading of the data 35 seconds. > > > > > >NOTE: it is a slow machine but the customer has slow machines too so that > >is why I am using it. > > > >NOTE: Yes, I know...who in their right mind wants 30,000 records on a > >form....my customer does so I can't argue with that. > > > >=================================== > >This list is hosted by DevelopMentor(r) http://www.develop.com > > > >View archives and manage your subscription(s) at http://discuss.develop.com > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > > View archives and manage your subscription(s) at http://discuss.develop.com > =================================== This list is hosted by DevelopMentor(r) http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentorĀ® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentorĀ® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
