Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I would like advice in starting a new website that will be relatively high volume. Will need a database. I want a system that will grow with volume by adding hardware. What would be the recommendation for database, operating system, and hardware architecture ? Also, any ballpark cost estimates would be great. PLan to start out with a hosting service but may need a dedicated system from the start.

share|improve this question

closed as off topic by Mark Henderson Jan 16 '12 at 3:25

Questions on Server Fault are expected to relate to server, networking, or related infrastructure administration within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

It would help to be a little more specific. "I want to make a website, what hosting should I get?" isn't going to get you much. Tell us about your application and exactly what you need. – Sasha Chedygov Jun 28 '09 at 21:15

whatever technical solutions you're going to choose [ operating system, application layer, database engine ] - from very first day plan with scalability / high-availability in mind.

so - shard your data from day from day one, think how to spread load between servers generating pages.

it all really depends on what you're going to serve... couple of random addresses/books to take a look at [ linux/php/mysql biased ]:

share|improve this answer
For the definition of shard, see – Chris W. Rea Jun 28 '09 at 23:32

You might want to check this out. While not a direct answer to your question, and no ballpark costs on it, it features Jeff talking about the hardware and setup of this site. It was a bit of an eye opener for me.

share|improve this answer
  • Choose something that will scale horizontally vs. vertically. This means that would will be better suited for growth and uptime if you have many small web servers behind a load balancer vs. one big web server with a single point of failure.

  • The OS and Database really depends on whoever is developing your web site. Seek counsel with them before making a decision. My default answer is Linux, Apache, Postgres. :D

  • Consider hosting in the cloud (, No huge capital costs, High Availability, fast scaling.

share|improve this answer

You'll definitely want to go with a dedicated hosting provider. Someone like RackSpace or Pair Networks comes to mind. I use RackSpace, and have been very happy with them for the past 4 years. When you call any provider, you should talk through what you're looking to do and they'll help you build the system.

share|improve this answer

I would consider dreamhost because they are initially cheap to host and you can switch over to their virtual, private hosting (4 gig of RAM, etc). It isn't technically a dedicated system, but it should come with many of the benefits.

share|improve this answer

Model your application and database. Using these models, determine where you need concurrency and where you need persistent storage. Use PostgreSQL for persistent storage and memcached for temporary storage. If you need long-term persistent storage for unstructured binary objects, use a cloud storage engine like Amazon S3 and a client library to interface with the API.

Develop and deploy your application on a cloud computing system like Amazon EC2. Define server roles and model the network architecture. Use Debian GNU/Linux as the base OS and an automated build system to bootstrap specific server roles.

Install statistical reporting tools like Munin and monitoring tools like Nagios when you have enough data to determine what "normal" is for your application.

When your application is live, monitor the growth of the data set and simulate a 1000 times increase of that set. Log your SQL and run some example queries through the PostgreSQL planner to determine where your database bottleneck is located. Trace that back to the application.

Determine a framework-dependent stats package for your application code. Review reports from this tool and determine what user actions are generating the slowest response times.

share|improve this answer