3 ms·
keeping scaling in mind helps a lot, but the real problems you'll run into then are the ones you're not aware of... like a 32,000 directory limit on linux. as y
by drusenko 18y ago
keeping scaling in mind helps a lot, but the real problems you'll run into then are the ones you're not aware of... like a 32,000 directory limit on linux. as your application grows, you just get blindsided at random, and need to put out fires constantly.
and that's where experience with scaling comes in handy. if you don't have it, the next best thing you can do is to have a knowledgeable friend, read up on best practices, and deal with fires quickly.
- nostrademons 18y agoYou can also setup a script to load up a million fake users onto a spare box and then mimic some typical activity. This'll catch a lot of the unforseen problems that'll show up: it'd catch that 32k directory limit, it caught the >1000 files/directory slowdown when I tried it, and it'll catch most database indexing or join problems. And if your test computer is much slower than the computer driving the requests, you can catch CPU or I/O bottlenecks in the webserver stack. I use P2/200 Mhz that's 10 years old for this and ping it from my parent's desktop that they bought last year. There're still unforseen problems - there always are - but you can flush out some of the more obvious issues. And the testing can run concurrently with some of the last minute design tweaks, so it doesn't cost all that much in development time. Or do it after you launch when you've got a spare moment; very few websites get big immediately.