If your database isn't already running on a high-end SSD, do that first. I never had that option.
MySQL is fine. It's your schema that matters, not your software usually.
> I have a website project algebra.com. Right now it gets about 61,000
> visits per day, and in peak times, serves about 55 requests per second
> (requests for HTTP objects, not pageviews).
>
> This is all good and well. When this goes on, it uses about 30% of CPU
> on my server, which makes me think about "scaling up".
What is using 30% CPU? Perlbal? That's pretty crazy for ~60 requests a second. Are you using XS header parser?
If the database: Make your queries more efficient.
If the web application: Buy more web servers (or make the code more efficient).
- ask
I have a website project algebra.com. Right now it gets about 61,000
visits per day, and in peak times, serves about 55 requests per second
(requests for HTTP objects, not pageviews).
This is all good and well. When this goes on, it uses about 30% of CPU
on my server, which makes me think about "scaling up".
(I seem to be not getting 1/4th of this thread? wtf google groups).
Take note that the "fate worse than death" article was an opinion piece by
a vendor attempting to sell something. I've seen people fear simple
sharding so much that they end up implementing it wrong when the time
comes.
SSD's and strategic magnetics will get you a *long* way though.
Perlbal is single process, but you can run many perlbal's. LVS or Haproxy
for "Stupid/fast" L4 LB, to a set of perlbals which then do more
intelligent things.
You can also serve static content via another hostname/IP combo which
directly talk to nginx or similar.
Make sure you have Perlbal::XS::HTTPHeaders installed, and `perldoc
Perlbal::Manual` has some sections on optimisation. Enabling backend
keepalives, client keepalives, etc, can drastically lower perlbal's CPU
usage.