[AccessD] Solid State Disk performance

Did you see this comment on the NewEgg site (perhaps it was you who posted it?)

"Other Thoughts: As soon as you get this drive, check the firmware revision on it (it will list it in the name of the drive in the BIOS). If its 1199, it has a bug in it that will cause the drive to start showing errors in Windows once it gets near full.

Google "OCZ Vertex Firmware" and you'll find detailed instructions on upgrading to the newer 1275 firmware. Its not terribly difficult, but you will lose any data you've already put on it.

The good news is that the firmware also fixes a bug that wasn't allowing the drive to write data as quickly as it should have, so now the drive is even faster than before."

Lambert

-----Original Message-----
From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, April 01, 2009 10:18 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Solid State Disk performance

In this particular case I am just installing the application on a VM and then copying the VM so that I run one instance in each VM.  Tech support for the application told me that as long as I have a license to use the software I could run more than one copy to speed up my processing.  The application does most of the processing locally so it is just my own hardware taking the hit.  It does upload a file for post processing but they told me I could do this (which is really pretty nice of them) so I am not violating any license.

Running it in a VM allows me to move the application to a different server if I need without uninstalling / reinstalling / obtaining the key for the new install etc.  Obviously it also allows me to run multiple instances to speed up the processing.

I process huge tables, for example last night / today I am processing about 50 million records.  My time to process (on an instance of the program) is about 4-5 million records / hour, however there is upload / process / download time on the remote server.  Together the total comes to about 20 minutes per million records so it will take about 17 hours or so to process the table.  If I can throw multiple VMs at it I can cut that by at least two, possibly three or even four.  Nine hours is better than 17, 5 hours is better yet.

We shall see.

The SSD gives me extremely high (RAID 0 like) bandwidth, but it also gives me extremely high IO processing as well as extremely low latency.  For a process like this where the system does nothing but read and process, the performance boost versus a hard disk is astounding.  And all for a measly $125!

John W. Colby
www.ColbyConsulting.com


Mike Mattys wrote:
> I wish I could do this with MapPoint and Access or Excel.
>
> Further, I would like to do multithreaded, asynchronous processing
> even if I have to open multiple app instances.
>
> Perhaps .Net will be of some assistance in this area ...
> if I can ever climb so high.
>
> -
> Michael R Mattys
> MapPoint and Database Dev
> www.mattysconsulting.com
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com