5 ms·
Just 10,000 visitors per day on a 64 core machine with 256GB of RAM? If were per minute (or even hour) it would make sense, otherwise, it seems poorly designed.
by faragon 12y ago
Just 10,000 visitors per day on a 64 core machine with 256GB of RAM? If were per minute (or even hour) it would make sense, otherwise, it seems poorly designed.
- bluedino 12y agoTrue. Maybe. Depends on what the users are doing, how long they are logged in... Are they just logging in twice a day to punch in/out, like a online timeclock? Certainly too many resources for that amount of traffic. But are each of the 10,000 users logged in all day, each working with large files or data sets, and doing intensive tasks?
- alecco 12y agoBeing a PHP + VMWare system (culture-wise, not the technology itself), I was not surprised about all the madness on DB level. They didn't use indices in Postgres but they added Redis. Its incredible how many, perhaps most, systems do crazy things like that.
- chris_wot 12y agoOf course, the flip side is too many indexes.
- themonk 12y agoI have seen both extreme: no index v/s all column indexed, no cache at all v/s cache at every level. I have seen caches having more inserts v/s reads. I have seen them replacing MySQL by NoSQL as it does not scale for them. This is common for early stage funded startups founded by non tech founders.
- raverbashing 12y agoOh I can imagine the pain... "Let's make our change password system handle 100k requests per minute but the front page starts to get wonky at 1000 req/min"
- themonk 12y agoThis sounds familiar. Few day ago i over overheard this, "Our user authentication system is on MySQL, it may not scale, let's move it to NoSQL." Only time this table is touched to check user entered correct password or not.
- faragon 12y agoNo. Most systems do not do crazy things like that. That system by itself could run Google search for lots of queries/s, and it is having trouble to deliver few operations per day. Come on, that server is faster than anything running in late nineties for world-wide massive access (!)
- jacquesm 12y agoI think you missed a '0' there. And not all applications are created equal, some really do have more business logic and systems requirements than others. 100K visitors on one machine is usually doable, 200K as well if the website isn't all that complex and the interactions between users aren't all that complex. Above that you're (usually, not always) going to see some clustering. If it is just static content then you should be able to saturate your uplink from one single machine. The 10K number applied to the whole setup, and that's now comfortably served from one box (as it should be). It could probably handle 10 times that number now without too much in terms of additional tuning (if any), above that it might require more work.
- blowski 12y agoI have built projects that had 100 users per day but was told by the CEO that it needed to be able to handle 100,000 concurrent users, and part of the acceptance testing was proving that.
- spydum 12y agoYup story of my life building a BI platforms lately. Everybody inflates their concurrency estimates, and you can question them all you want, just don't be wrong in the opposite direction..
- T-hawk 12y agoYup. Estimation inflation syndrome is a thing. One of my previous jobs suffered from that all the time, on database sizing. How much space does the client need for this trading app? DBA figures 1k transactions per day at 1kb/record for 1 MB storage, round that up to 1 GB per year, so tell them 10 GB should do for 10 years. CTO hears 10 GB from the DBA, adds his own safety margin factor of 10x, tells the client 100 GB. Client hears 100 GB, adds his own safety margin factor of 10x, tells their operations 1 TB. So now we have a client building a giant SCSI terabyte array (this was when 72 GB SCSI disks were the high end server standard) to hold a database that's a year away from reaching even one gigabyte.
- deleted 12y ago[deleted]