Solid State Drives or SSDs are one of the biggest advancements to modern computing in recent years. 

Traditional hard disk drives or HDDs consist of a series of metal platters that spin around.  There are magnetic arms that then move around to read the data off of the hard drive.  This limits the speed of the hard drive to how fast those platters can spin, and because there are moving parts involved, the hard drive tends to wear out faster than any other part of the computer.  Spinning the platters also causes additional heat and noise inside the computer.

SSDs don't have moving parts.  You can think of them as basically memory or RAM that stores the data permanently.  There are differences, of course, between these two technologies, but the high level concept is the same.

Because there are no moving parts, it is much faster to read/write data.  They also use less power and create less heat. While they'll still wear out eventually, they can last longer than traditional hard drives.

The only downside, currently, is that solid state drives cost more per GB of storage.  As the technology advances, this is becoming less of a discrepancy.  The 128GB SSD cost me $150, but you can currently get a 2TB hard drive for about $100. 

How fast is an SSD vs. an HDD

The best way to explain the difference is to give you an example.  For those of you who know MySQL, you know that backing up the database consists of running MySQLDump, which writes out a file with all the insert statements that can then be read back into MySQL to recreate a database.

I used a database that is large enough to easily see the differences.  The database dump file was about 1.5GB in size. It contains 200+ tables and millions of rows of data.

First, I restored it to my traditional hard drive, then I installed an SSD, reconfigured MySQL to use the SSD as the data directory, and then restored the same file again. The rest of the PC was exactly the same, which happens to have 4GB of RAM and a 6 core AMD Phenom II 1090T Processor.  It's running Linux Fedora 14.

This computer only has SATA2 controllers, which has a limit of 3GB/s of data that can transfer across its wires.  There are now motherboards with SATA3 controllers, which increases this limit to 6GB/s. The SSD I used was a OCZ Technology 128GB Vertex 4 Series SATA 6.0 GB/s 2.5-Inch Solid State Drive.  It's backwards compatible to the SATA2 or 3.0 GB/s speed.

My traditional hard drive took 35 minutes to import.  My solid state drive took about 5.  In theory, if I had a SATA3 controller, this could be cut in half again, though I doubt it would end up that efficient.  More likely, it would be 3 1/2 to 4 minutes.  So for this one test, the SSD was 7 times faster than my regular hard drive, and might end up 10-12 times faster under SATA3. 

There are also SATA3 controller cards that you can buy for about $50.  I thought about buying one of these, but I suspect that it wouldn't give you a full 6 GB/s because I believe you'll lose some speed as it travels through the card into the motherboard.  If you've done this, please comment and let me know your findings.

When to use SSDs

Any time you need speed over raw storage, use a SSD.  Some common uses are:

• Boot drive - you'll boot up much faster using an SSD.  Store your photos and data on a traditional HDD.
• Database Drive - if you are running any sort of database, the hard drive is often your slowest part.  Move your data over to a SSD and you'll notice a speed increase.
• "Working Drive" - if you're using programs such as Photoshop that saves a history of each file change, you should see an increase in performance if your working drive is an SSD especially since most Photoshop files are 100MB or more. 
• "Swap File" - If you are using more programs than you have available RAM, some of your working data will be moved to a file called the Swap file.  Put this on your SSD for a boost in speed.
• Any time you're using a program that is hard drive intensive (i.e. has to load or save a lot of files or data while using the program).
• If heat is an issue, such as in a data center where you have hundreds of computers or in a server where you're striping many hard drives together, use an SSD to decrease the amount of heat produced.
• Use a SSD to reduce the amount of noise produced by your computer.

When to use HDDs

• When cost is a factor
• For raw storage such as large photos and other data that doesn't need to be accessed often
• Storing backups where speed isn't an issue

This is more of a set of modifications rather than an actual module, but the end result is the same.

First thing you’ll need to do is backup your existing site and database. I’d recommend using a test install of Xcart so that nothing in production gets messed up. With that in mind, the first step is to alter the pricing table by using the following alter table command. If you have a different version of MySQL, you might need to tweak this a bit.

ALTER TABLE `xcart_pricing` ADD COLUMN `numpymnts` INTEGER UNSIGNED NOT NULL DEFAULT 1,
ADD COLUMN `paymentprice` DECIMAL(12,2) NOT NULL DEFAULT 0 AFTER `numpymnts`,
ADD COLUMN `sourceproductcode` VARCHAR(255) DEFAULT 0 AFTER `paymentprice`,
ADD COLUMN `sortby` INTEGER UNSIGNED NOT NULL DEFAULT 0 AFTER `sourceproductcode`,
ADD COLUMN `mastervariant` SMALLINT(5) UNSIGNED NOT NULL DEFAULT 0 AFTER `sortby`,
ADD COLUMN `price_override` SMALLINT(5) UNSIGNED NOT NULL DEFAULT 0 AFTER `mastervariant`,
ADD INDEX `numpymnts`(`numpymnts`),
ADD INDEX `paymentprice`(`paymentprice`),
ADD INDEX `sortby`(`sortby`),
ADD INDEX `sourceproductcode`(`sourceproductcode`),
ADD INDEX `mastervariant`(`mastervariant`),
ADD INDEX `price_override`(`price_override`)
, ENGINE = MyISAM;

The new columns are as follows:
numpyments = number of payments
paymentprice = price the export expects to see (might be one payment or the total)
sourceproductcode = product code (sku) that export expects to see
sortby = the order in which the variants show up on the admin page
mastervariant = overrides the ’starting at’ price
price_override = use this table for the price instead of the orders table for reporting

Next, you’ll need to modify some of the admin template files, such as:

Modify Files:
/skin1/modules/Product_Options/product_variants.tpl - add fields to the variants html table - don’t add the price_override column.

/modules/Product_Options/func.php - edit func_get_product_variants and add in the columns that were added to the product_variants.tpl file

When you submit the variants, the form goes to:

product_modify.php
section=variants
mode = product_variants_modify
productid = [variable]
submode = “data”
geid = “”

Once sumbitted, the code is run in this ELSEIF block in modules/Product_Options/product_variants.php:
} elseif ($mode == ‘product_variants_modify’ && $vs && $submode != ‘prices’) {

In here, you need to edit the $query_price_data array to include the additional fields; for example:

## BB Edit - added additional fields
$query_price_data = array(
"price" => $v['price'],
"variantid" => $k,
"productid" => $productid,
"quantity" => 1,
"membershipid" => 0,
"numpymnts" => $v['numpymnts'],
"paymentprice" => $v['paymentprice'],
"sortby" => $v['sortby'],
"sourceproductcode" => $v['sourceproductcode'],
"mastervariant" => $v['mastervariant']
);

Next, you need to edit the modify options page, otherwise, if you change options, it’ll remove your new field data.

When submitting this form, it passes these variables to product_modify.php:

section=options
mode=product_options_add
classid= your classid
productid = your productid
geid=”"

If you change add[is_modifier] (price modifier = ‘y’, else it’s blank), it rebuilds the variants by calling func_rebuild_variants in modules/Product_Options/func.php

//Rebuild variants: . . . . product_modify.php?productid=18&section=options&classid=71

In func_rebuild_variants, change the $_product[’prices’] $data variable to:

$data = array(
"productid" => $productid,
"quantity" => $p['quantity'],
"membershipid" => $p['membershipid'],
"variantid" => $variantid,
"price" => $p['price'],
"numpymnts" => $p['numpymnts'],
"paymentprice" => $p['paymentprice'],
"sortby" => $p['sortby'],
"sourceproductcode" => $p['sourceproductcode'],
"mastervariant" => $p['mastervariant']
);

This will keep your data from being lost in the new columns. And that’s it, as far as back end functionality for the multi pay option. Depending on how your templates are set up, you’ll probably want to use the new columns to force the “mastervariant” column to show up in the “starting at” price. Do this by ordering that query by mastervariant in descending order. The rest of the columns really come in handy when you need to see the full price such as in reports, modifying omniture code, and to produce export files where the fulfillment company wants to see the full amount instead of the per payment price.