CPVLab Hosting Recommendation

V

vinnythejinny

New member
Mar 5, 2008
1,698
11
0
Long story short, my P202 is killing me right now. I have to clear my DB almost every week because am running massive number of clicks.

I am planning to move to CPVLab and looked at beyondhosting but their servers look half ass to me. 2GB RAM is enough for 50-100K clicks a day?

I was looking at OVH US dedicated server at $139 with 32gb ram. Again, OVH is mainly clogged with warez, torrent , movie streaming and shit so wasn't sure if I want that neighborhood.

Any recommendation for a powerful server around $100 a month with min 12 GB ram.
 


Unarmed Gunman said:
Liquidweb

/thread.
Click to expand...

This was going to be my suggestion too. I have a fully managed i5 quad with 4gb of RAM, dual 500gb drives, and cPanel for $165 a month. I think to boost it to 12gb or 16gb? is another $50 a month on top of that. The support is usually pretty good. If you're going to stick with them for more than 10 months, then it's worth paying the $350 setup fee, as it reduces the cost by $35 a month. I was with my last hosting company for like 10 years, so that'll pay for itself many times over. You can also try negotiating with them for upgrades. I had them add on 2gb of RAM for free and I got a 10% discount as well on top of everything else.

Muy bueno!
 
Netphase said:
Another +1 for Liquid Web. I use their Storm On Demand service. It has been great. :thumbsup:
Click to expand...

Oh yeah. Who do you use, Chief Black Elk, Chief Lone Horn or Chief Touch The Clouds? for all these storms

rain_dance.jpg
 
You should be on at least 1 dedicated with quality routing.

None of this 100/month ghetto server with crappy routing.
 
Why not just ask the cunts from Cpvlab for recommendations? We're not their support forum ya know...
 
LOL@Jon. They actually recommend beyondhosting but its far from what i want. Will checkout liquidweb now, especially the cloud for reliability.
 
mattseh said:
Does 202 not use relational databases efficiently? Or are most ad servers that it uses poorly setup?
Click to expand...

Relational databases are simply not efficient with all the normalisation and joins that take place in a "well designed", normalised database.

Not really the place for me to go on about this, but it excites me.

Many high volume websites these days use some form of 'NOSQL' document based database. I just built my own ecommerce platform on MongoDB MongoDB , and as a guy that exclusively used MySQL for years, MongoDB is fucking brilliant. It takes a huge shift in thinking to design a document based database, but I'll never go back.

Take Magento for example, it does at least 100 database queries just to load a single product page. My ecom platform built on MongoDB does only one query to load a product page of infinite complexity because everything for that product is stored in a single 'document' rather than being spread over hundreds of joined tables.

Anyway I host all my shit on a single Amazon EC2 micro server I built from scratch to run NGINX, php-fpm and mongodb. I have my server image stored so I can set up new servers from the image within minutes, brilliant stuff. Only $15 a month for the micro server too. Even better is that I can choose the server to be hosted in Australia.
 
^^^

Any good tutorial on this topic? I am particularly interested in running nginx instances on EC2
 
johnmatrix said:
Relational databases are simply not efficient with all the normalisation and joins that take place in a "well designed", normalised database.

Not really the place for me to go on about this, but it excites me.

Many high volume websites these days use some form of 'NOSQL' document based database. I just built my own ecommerce platform on MongoDB MongoDB , and as a guy that exclusively used MySQL for years, MongoDB is fucking brilliant. It takes a huge shift in thinking to design a document based database, but I'll never go back.

Take Magento for example, it does at least 100 database queries just to load a single product page. My ecom platform built on MongoDB does only one query to load a product page of infinite complexity because everything for that product is stored in a single 'document' rather than being spread over hundreds of joined tables.

Anyway I host all my shit on a single Amazon EC2 micro server I built from scratch to run NGINX, php-fpm and mongodb. I have my server image stored so I can set up new servers from the image within minutes, brilliant stuff. Only $15 a month for the micro server too. Even better is that I can choose the server to be hosted in Australia.
Click to expand...

You should use the best database for the job. For a lot of things, that is relational.

You should check out redis, it's another piece of the puzzle.
 
johnmatrix said:
Relational databases are simply not efficient with all the normalisation and joins that take place in a "well designed", normalised database.

Not really the place for me to go on about this, but it excites me.

Many high volume websites these days use some form of 'NOSQL' document based database. I just built my own ecommerce platform on MongoDB MongoDB , and as a guy that exclusively used MySQL for years, MongoDB is fucking brilliant. It takes a huge shift in thinking to design a document based database, but I'll never go back.

Take Magento for example, it does at least 100 database queries just to load a single product page. My ecom platform built on MongoDB does only one query to load a product page of infinite complexity because everything for that product is stored in a single 'document' rather than being spread over hundreds of joined tables.

Anyway I host all my shit on a single Amazon EC2 micro server I built from scratch to run NGINX, php-fpm and mongodb. I have my server image stored so I can set up new servers from the image within minutes, brilliant stuff. Only $15 a month for the micro server too. Even better is that I can choose the server to be hosted in Australia.
Click to expand...

I thought AWS kills the value with their bandwidth pricing.
 
You must log in or register to reply here.
Top Bottom