Re: To CS or not to CS?
From: Dan Freeman (spam_at_microsoft.com)
Date: 03/22/05
- Next message: Rolf Lystad: "Re: To CS or not to CS?"
- Previous message: Lew: "Re: AutoInc problem, VFP8"
- In reply to: Paul Pedersen: "Re: To CS or not to CS?"
- Next in thread: Paul Pedersen: "Re: To CS or not to CS?"
- Reply: Paul Pedersen: "Re: To CS or not to CS?"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 21 Mar 2005 16:59:35 -0800
Paul Pedersen wrote:
>> An INSERT definitely shouldn't take that long.
>
> Sorry, I was misleading there. It was a simple insert, plus some other
> processing that should also be quick.
OK, so it could be a horse of a different color.
One cullprit could be multiple REPLACE commands into the same record. I've
seen things like this:
REPLACE f1 WITH var1
REPLACE f2 WITH var2
..... etc.
It can all be done in one command and will be orders of magnitude faster
because it's a single write to disk and a single update to the indexes.
There are many things that can slow down code. Have you tried to run the
Coverage Profiler to see what's slow?
>> And, for what it's worth, there are many reasons to go to a C/S
>> architecture
>> but performance is NEVER on the list.
>
> That surprises me. I had thought that it WAS a reason, particularly
> with large data sets and large numbers of users.
>
> Can you explain?
Long topic. <g>
You move to a C/S architecture for table sizes >2GB, or for improved
security, or for reliability, or for distributed/replicated DB, or for
fail-over ... but all of those things carry a performance price tag.
Not to mention that your app would likely have to be re-architected. The
mantra with C/S is to fetch as few records at a time as possible. You may
have to go back to the server more often, but you'll want to work with
really small subsets of data.
You'll also move more and more off to stored procedures on the server.
Imagine your server with several hundred users calling stored procs all at
once. They execute on that centralized server box. Granted, C/S databases
are highly tweaked to support this, but it's still highly centralized
processing shared among all the users.
There are many benefits to C/S. Performance ain't one of 'em.
Dan
- Next message: Rolf Lystad: "Re: To CS or not to CS?"
- Previous message: Lew: "Re: AutoInc problem, VFP8"
- In reply to: Paul Pedersen: "Re: To CS or not to CS?"
- Next in thread: Paul Pedersen: "Re: To CS or not to CS?"
- Reply: Paul Pedersen: "Re: To CS or not to CS?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|