6 ms·
My answer comes from the perspective of a recent grad who has spent a year at a mid-sized SF social gaming company, working only recently on the back-end (i.e.,
by pkghost 16y ago
My answer comes from the perspective of a recent grad who has spent a year at a mid-sized SF social gaming company, working only recently on the back-end (i.e., not a scaling expert).
A few things I've learned w/respect to scaling in my context:
- I/O is likely to be your bottleneck, so design your db well and anticipate splitting it across multiple machines (and what that means for your access logic)
- don't spawn a new thread for every request (a la apache)
- keep your services simple (perhaps: one for handling web requests, one for data access, one for caching, one for your payment system) and their relationships even simpler (one hop max from RPC caller to callee)
- cache like a hoarder
- find/write an efficient serializer for RPCs between services
What helped me get a grip on this stuff was sitting down with an architect who has done it successfully multiple times. I asked for an elevator pitch description of scaled web architectures, and then ask him about his failures. Voila bullet points.
- davidw 16y agoApache does not spawn a new thread for every request.
- jaydub 16y agoEvery request does not require a thread to be spawned (depends on configuration/load), but every connection would require its own thread. "The worker MPM uses multiple child processes with many threads each. Each thread handles one connection at a time. Worker generally is a good choice for high-traffic servers because it has a smaller memory footprint than the prefork MPM. The prefork MPM uses multiple child processes with one thread each. Each process handles one connection at a time. On many systems, prefork is comparable in speed to worker, but it uses more memory. Prefork's threadless design has advantages over worker in some situations: it can be used with non-thread-safe third-party modules, and it is easier to debug on platforms with poor thread debugging support." http://httpd.apache.org/docs/2.0/misc/perf-tuning.html http://httpd.apache.org/docs/2.0/misc/perf-tuning.html
- pkghost 16y agothanks for the explanation :)
- j_baker 16y ago"- cache like a hoarder" This isn't necessarily true. If the data is likely to be very volatile, it will probably be better just to ping the database than to bother trying to cache it.