Running Prosper202 on a Solid State Drive - Wicked Fast?

Hurr-Durr

Hurr-Durr

Hurr-Durr.com <-OBEY
Aug 18, 2010
842
16
0
Anyone run Prosper202 on a Solid State Drive? I talked to my web host and they said it should work insanely fast, especially when I pulled up reports in Prosper.

Anyone have a word on it?
 


Considering how fast the drive read/write speeds are it should be stupid fast.
 
.Hack said:
What host is this?
Click to expand...

liquidweb :)

Looks like it's sickk:

graphite-graph2a.gif
 
I'm with liquidweb too and one dude recommended I move my stuff over to SSD. Another guy said try more RAM first. I ended up bumping to 8gb RAM, which worked and was really cheap to upgrade. Handling 500 simultaneous requests no problem with P202 and a few other resource heavy scripts.

Might want to give that a shot first if you're not already there. But damn, I like the SSD. How much are they charging for that?
 
Had an ssd config in raid 5, it was stupid fast, they went to upgrade the ram and they erased the array by turning the machine off. I haven't had good things with ssd's over there.
 
I have an SSD in my box at home but I run 202 on my mediatemple box... I am going to do a local install now and see :D
 
Just closed the deal on a new stormondemand cloud package. Adding more ram like this is exactly what I was trying to do when on liquidweb but was limited in scalability. Pretty excited to test it out....
 
Hurr-Durr said:
Anyone run Prosper202 on a Solid State Drive? I talked to my web host and they said it should work insanely fast, especially when I pulled up reports in Prosper.

Anyone have a word on it?
Click to expand...

Yes I am doing this. actually I have Dual SSD drives on my server and 202 works incredibly fast even when pulling stats based on tens of thousands of clicks over 7 and 14 days.
 
fuck i shold look into this for cpvlab cause the load times are pissing me off.

but dont get me wrong - cpvlab still kicks ass and i think that if you used t202 for ppv it'd probably be just as bad.
 
SSDs have a limited read/write cycle. So be mindful of that especially if you're thinking of this in the long-term.
 
loxllxol said:
SSDs have a limited read/write cycle. So be mindful of that especially if you're thinking of this in the long-term.
Click to expand...
Not an issue with Windows and Linux.

Also, RAM>SSD. Just rewrite the queries to not hit the disk and/or do the actual aggregation in PHP and you should be fine.
 
Get more ram, make it so that the program keeps everything cached in the ram, and it's a lot faster than any hard drive.
 
^ yep, php_apc + tweak mysql and it's going to be as fast as it can be (network latency and processor not withstanding)

it depends on sooooooooooooo much stuff it's ridiculous... but yeah, if you're not into or don't have anybody to look at and optimize your servers, you might benefit a little from the ssd, but again, even that depends
 
LeFluffy said:
^ yep, php_apc + tweak mysql and it's going to be as fast as it can be (network latency and processor not withstanding)

it depends on sooooooooooooo much stuff it's ridiculous... but yeah, if you're not into or don't have anybody to look at and optimize your servers, you might benefit a little from the ssd, but again, even that depends
Click to expand...

please elaborate on php_apc and teak mysql (or are you just saying to tweak it and it's not some script to use?)
 
barman said:
please elaborate on php_apc and teak mysql (or are you just saying to tweak it and it's not some script to use?)
Click to expand...

PHP APC is an opcode cacher that's going to be built into PHP from version 6. Until then you can use it as an extension. What PHP does on every request is read and parse the file from disk... which of course is slow as fuck. PHP APC simply caches that in memory (even better than reading it from an SSD drive).

PHP: APC - Manual

Tweaking MySQL however is not that straightforward and it's highly dependent on the data and queries it's running... it's an art
 
For optimizing MySql, you can temporarily turn slow queries logging, and write a memcache wrapper class around SQL statements that take a long time.

I usually find the db to be the bottleneck; also, cache static html/text files for content that doesn't have to be in real time + minify js/css
 
I have to check out that PHP APC. MySQL can depend a lot on your indexes and general structure of the database. You should always shoot for a 4th normal form database at first, but for some apps it makes a lot of sense to deviate from that.
 
You must log in or register to reply here.
Top Bottom