New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
oh i see.. for me, i only source compile install haproxy 1.5.x dev on centos = problem free
for blitz.io errors make sure to test with appropriate timeout value -T for blitz.io..
i.e.
Yeah the client's been doing that. He's tried loading up AB on another instance and which has produced some errors on the LB for the first time which has shown some upgrades we need to do, but he's meeting his client in 30 minutes, so it'll have to wait.
Current stats show we can get about 600 3600 hits per second, and we're leaving it there for now, though we'll probably have to think more about this setup after Christmas.
3600 hits a second is good. Is that static content though?
http://s.lowendshare.com/11/1356465179.639.21k.png
Well, @Amfy, Apache Bench will give you all sorts of results.
ab has it's place, but like many load test tools, traffic isn't that highly repetitive and you have to consider what is being served directly from cache. That model would work for a big single site CDN serving the same page elements to a lot of folks, but not for much else anywhere those numbers.
3600 hits a second is alright, but real world, doubt the solution will touch that. Real world work loads vary but tend to be lots of disk seeks, different requests back to back, overhead management, application layer, etc.
I miss the days of flat HTML sites where every page was the same for everyone. Those sites you can scale massively on nothing for hardware
Wouldn't say that. Distributing the load of some wordpress blogs is much easier than scaling "load" of flat HTML files, since you have to do that on much lower network levels
Nah, 21k / s is not that bad, and that even on a 512MB VM
But you are fully right, almost no webapp will ever have that massive visitors, but I love to play with those setups.
Also, for example 10 requets per second are looking bad, but! 10 * 60 * 60 * 24 are even 864000 hits / day, not easy to build a app / blog / etc for that attention.
But @Amfy, Wordpress still needs to deal with sessions, tracking ,etc. unless the blog owner doesn't care/use any of that.
HTML flat content will always be the easiest and fastest to scale. Everything else adds config complexity and more rules to parse to deliver content, which drives latency up.
Scale is a black art truly. Have to be privy to the load / use info from the inside or it just gets silly and expensive.
Your 10 req/sec, yeah what a great multiplier. Would be a nice project
Too bad 80% of most traffic is concentrated in peaks of day while overnights are pin drop quiet comparatively.
Wouldn't count that as difficult to handle
Ok, then theoretically, say, we have a page which gets 50k q/s, how would you then do that? Of course there is DNS Roudrobin, but that is lame. On that size it's not so easy to add loadbalancers, since just this loadbalancing needs some resource overhead, etc
It was just to show people how much even 10q/s are
@Amfy,
The 50k request a second?
Regardless of what is being served that is a good sized cluster (unless it's purely bogus file serving of say default HTML file over and over). Quick and simple would be a few machines doing the "load balancing" via Nginx and those also doing caching up front (2-3, N+1 always = 3). How many machines, all depends on variables.
Looking at newer multi core machines, like the Xeon 5xxx and newer. Machines with ample RAM (although I doubt too much is needed for the IP tracking, session management, etc.).
Behind them more machines in a cluster doing the actual page generation parts. Probably 3-5 machines back there. Typically beefier machines back here unless you have tons of static data to cache (ala CDN -- then the front end nodes -- the load balancers will be bigger).
If it's all flat HTML content then a distributed / shared file system or replicated locally on each node, depending.
I'd be hashing the inbound IP to determine which machine the requests from them get bound to. It's a simple mod math operation I believe and hard to beat for stickiness with so very little overhead.
Scale horizontally. It's proven for stuff like this and best/easiest case to conquer reasonably. First bottleneck always are the back end page creator workers. Scale to saturation of the front end balancing nodes then scale the front balancers.
50k requests sustained probably is going to put a beating on network, router, etc. Total throughput might not be extremely high, but the network chatter and packet management will be high. Any lag or delays to end users will cause cascading delays and uneven performance in the cluster.
Guess this is why big companies aren't scaling 2-10x servers to need ratio but 100's and 1000's server to need.
Optimization and best practices implemented up front are mandatory at any scale like this. Opt for redundancy and some over-subscribe growth padding in case growth happens or in case of failure of server in the chain.
Check out highscalability.com is you like this sort of stuff