3 ms·

I think as opposed to looking at how your hosting should be structured, you need to pay more attention to how your application is structured. As carpal said, w

I think as opposed to looking at how your hosting should be structured, you need to pay more attention to how your application is structured. As carpal said, where are your bottlenecks? Is your app structured with one Web server talking to 1 or more replicated database servers, or multiple 'App' servers that can all take many requests or ... ? In my (rather limited) experience the most common scaling problem for apps is database performance, so it may be in your best interest to get a host where you can change your DB config to up the (rather conservative) default resource limits. (And make sure to take a good hard look at your indexing and queries first) If you're having RAM or CPU problems, you may just need a beefier server, and if it's bandwidth or IO then perhaps a scalable service like AWS may be a good solution. AFAIK The key for most small growing apps is structuring so that your bottlenecks are linked to sharded databases, so that you can just throw more hardware (virtual or physical) at the problem when you hit some limit of users, possibly even on the fly. I think i may be wrong about this now, but at least from early trials it seemed like most people using S3 and AWS were using it more for backups and backend processing/data mining, not on the fly work, due to data integrity concerns. I'd also recommend eventually moving to a more full-featured host, once your business can sweat the $300-500/server a month fees you'll run into with a host like Rackspace. Having great backups and the ability to get someone on the phone at 3am with no hold is essential when your server the only thing paying your bills =P.

izak30 19y ago
>AFAIK The key for most small growing apps is structuring so that your bottlenecks are linked to sharded databases, so that you can just throw more hardware (virtual or physical) at the problem when you hit some limit of users, possibly even on the fly. Joshwa's link at the bottom of the page suggests just the opposite, using many cheap servers, and distributing well, so it's not only a 'program architecture' issue, but also an issue of where your data is stored and its redundancy there, in 'shards' of cheap servers.
- showerst 19y ago
  That's actually exactly what i was trying to say. You set up your app so that you hit a limit of users (or whatever your main DB service is) and so you add another cheap slave to the pool, as opposed to having one or two super important servers that need hardware upgrades to expand.

izak30 19y ago

>AFAIK The key for most small growing apps is structuring so that your bottlenecks are linked to sharded databases, so that you can just throw more hardware (virtual or physical) at the problem when you hit some limit of users, possibly even on the fly. Joshwa's link at the bottom of the page suggests just the opposite, using many cheap servers, and distributing well, so it's not only a 'program architecture' issue, but also an issue of where your data is stored and its redundancy there, in 'shards' of cheap servers.

showerst 19y ago
That's actually exactly what i was trying to say. You set up your app so that you hit a limit of users (or whatever your main DB service is) and so you add another cheap slave to the pool, as opposed to having one or two super important servers that need hardware upgrades to expand.