By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,678 Members | 2,155 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,678 IT Pros & Developers. It's quick & easy.

Access Performance Curiosity Question

P: n/a
To those that have been around Access long enough, I'm sure that
insight can be shared as to what aspects of computer processing speed
improves its performance. Perhaps in some respects even sufficient to
partially offset an inadequate or poor database design. Also, and using
Access 97 as a starting point, have there been significant
changes/improvements in performance of the later versions of Access?
Assuming that a system has adequate memory resources, how much benefit
is realizable in having a 3GHZ processor vs. a 1GHZ, a 400MHZ bus vs. a
100HZ, etc.? Perhaps a final question would be what specific elements
of Access benefit most from faster hardware and those that benefit the
least? Thanks in advance for your comments and opinions.

Nov 13 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
Rolan wrote:
To those that have been around Access long enough, I'm sure that
insight can be shared as to what aspects of computer processing speed
improves its performance. Perhaps in some respects even sufficient to
partially offset an inadequate or poor database design. Also, and using
Access 97 as a starting point, have there been significant
changes/improvements in performance of the later versions of Access?
Assuming that a system has adequate memory resources, how much benefit
is realizable in having a 3GHZ processor vs. a 1GHZ, a 400MHZ bus vs. a
100HZ, etc.? Perhaps a final question would be what specific elements
of Access benefit most from faster hardware and those that benefit the
least? Thanks in advance for your comments and opinions.


IME it's very I/O bound so a fast disk will give the greatest benefit
(seek time rather than raw transfer speed unless your queries are really
inefficient <g>) although having said that most data resides on a
network so the disk speed may not be of much use when the bottleneck
will come from the network cards. Gigabit cards and switches are getting
cheaper nowadays.

The difference between a 1GHz and 3GHz CPU (with the memory and bus
bandwidth upgrades that came with them, e.g. DDR333/400 over
DDR266/SDR133) would result in faster loading times for the application
as a whole and for objects loading into memory, this may well be where
performance is most critical if the database itself is efficient. But in
general the i/o (network/disk) are the places to look at first for the
database part.

On the network, if you're limited to a 100Mb/s network then make sure
you have a switch rather than a hub to avoid packet collisions. Hubs
send packets to every node on an Ethernet network, the PC with the right
address picks it up as it passes, switches are intelligent in these
matters and will send the packets down the relevant wire, this is good
for both speed (re collisions) and security (re packet sniffers[1]).

On the disk front, don't bother with RAID-0, it's touted as being fast
but useless for anything other than video capture, high data transfer
rate but does nothing for seek times (slows down if anything). It's not
called RAID-0 for nothing, the 0 refers to the amount of redunancy and
your chances of disaster recovery. If on a server, go for redundancy
before speed (RAID-1 or 5). The data you're seeking is rarely contiguous
so lower seek times are what you want from a disk.

Disk types, SCSI obviously the fastest and most expensive, IDE not far
behind in terms of speed, ATA133 disks hardly likely to saturate an
ATA100 controller so don't go out of your way to get ATA133 if you only
currently have ATA100 on your mobo or RAID card.

ATA RAID Cards, for simple striping or mirroring (or both), usually
software based, use the CPU but little overhead, expect to pay less than
a Chinese Takeway, to get more complex parity checking (RAID 3, 5, etc)
requires a bit more horsepower ATA RAID 5 cards with co-processor expect
to pay for a slap up meal at a fancy resturant including drinks, caberet
and taxi home.

[1] Not the be all and end all of sniffing security if switches are
daisy chained, etc.

--
This sig left intentionally blank
Nov 13 '05 #2

P: n/a
> Rolan wrote:
To those that have been around Access long enough, I'm sure that
insight can be shared as to what aspects of computer processing speed
improves its performance.

"Trevor Best" <no****@besty.org.uk> wrote IME it's very I/O bound so a fast disk will give the greatest benefit
(seek time rather than raw transfer speed unless your queries are really
inefficient <g>) although having said that most data resides on a
network so the disk speed may not be of much use when the bottleneck
will come from the network cards.

If you understood all that Trevor said, then you don't need advice:)

I would just add that IMHO the most significant thing you can do to speed up
your database is to make sure it has sufficient memory so that it never has
to use the disk in place of RAM. Asuuming your OS needs a realistic minimum
of 256MB, you should have at least 512 MB for the BE, and the same for every
front end PC. Of course, that's not the case where I work, but that's my
issue ...

Second, indexes, properly used, are amazing. Improperly used, they're
pretty amazing at how crappy they can work, too. I have not been able to
find any code optinization that gave more benefit than I received from
indexing my fields correctly.
Darryl Kerkeslager


Nov 13 '05 #3

P: n/a
"Rolan" <co******@safe-mail.net> wrote:
To those that have been around Access long enough, I'm sure that
insight can be shared as to what aspects of computer processing speed
improves its performance. Perhaps in some respects even sufficient to
partially offset an inadequate or poor database design.
Are you having a specific problem or is this a general question?

Have you visited Access Performance FAQ page at
http://www.granite.ab.ca/access/performancefaq.htm yet?
Also, and using
Access 97 as a starting point, have there been significant
changes/improvements in performance of the later versions of Access?


No. Some things, until corrected, actually make Access significantly slower.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Nov 13 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.