Do you remember the first day of our chess project last year? The server was directly overwhelmed by the traffic, the page card can not even send out the cards, the players cursed - later a check, it is not a DDoS attack, purely bandwidth estimation of less, the peak hours of the number of people online burst, the resources crowded like the morning rush hour subway station. I was squatting in the engine room scratching my head: this year to engage in chess, high defense CDN selection is not the right bandwidth, is equal to the opponent to send head ah.
Many peers think that the bandwidth to the big buy always right, the result of the cost soared to the sky; or stingy search to save the budget, the user experience sucks like PPT. in fact, accurate measurement of bandwidth demand, the core of a sentence:Stare at the number of concurrent users, do not believe in the vendor's “peak traffic” metaphysicsI have tested three mainstream CDN service providers. I have tested three mainstream CDN service providers, found that they give the recommended value of the general inflated 30%, purely to sell more resources - especially some of the small manufacturers, even QoS guarantee to play word games.
Why are chess and card games particularly bandwidth-hungry? Simply put, every game is a real-time data exchange: player operations, game status, chat messages all have to take a long connection, plus audio and video streams (such as the landlord open mic trolling), the bandwidth occupied by a single user is much higher than that of a web page. I usually do a rough calculation according to this formula:Base bandwidth (Mbps) = average traffic per user × number of concurrent users × redundancy factorThe “average traffic per user” has to be broken down. One of the "average per user traffic" must be split up to see: TCP connection to keep alive about 5Kbps / person, game packets depending on the game, chess and cards usually 20-50Kbps / person, if with 720P video streaming also have to add another 500Kbps to start.
For example: Suppose your chess platform is online 5000 people at the same time, of which 30% people open video chat. The calculation process is as follows:
But don't just take that number and order it! The real world has to be taken into account.Flow rate fluctuation curve--Chess user activity by time of day, e.g. the 8pm peak may be 3x as high as noon. I used to pull out the historical monitoring data, using statistical methods to calculate the 95th percentile bandwidth (the kind that cuts the peaks and fills in the valleys), which can save 20% cost. Once used CDN07 home elasticity billing, according to the 95th calculation than the fixed bandwidth program to save a small two million per month, but his family CC attack weak point, have to make up for their own set of WAF rules.
When choosing bandwidth for a high-defense CDN, you also have to look at the protection capability. Some vendors claim “unlimited protection”, the actual encounter Syn Flood directly lying flat. I pressure tested CDN5 and 08Host, the former any more than 200Gbps of traffic will trigger speed limit (although the document does not write), the latter hard to carry 500Gbps but the price is painful. If the number of people online at the same time is high, the priority to choose the elastic expansion - such as 08Host's “second bandwidth bursting” feature, burst traffic automatically add protection, rather than the temporary increase in the package to save time.
For the sample configuration piece, this is how I usually set up the Nginx reverse proxy (with CDN optimization):
One final spitball:Don't trust those “smart bandwidth prediction” features!! I've suffered a loss where a vendor's algorithm counted weekend traffic lows in the averages, and as a result, Monday's activity blew right through. Now I write my own monitoring scripts, use Prometheus + Grafana to pull real-time online number, linkage CDN API dynamic bandwidth adjustment. The code looks like this:
In the end, chess high defense CDN bandwidth is not a math problem but an economics problem - balancing cost and experience. The actual test down, CDN5 is suitable for tycoon company (protection is stable but expensive), CDN07 cost-effective (suitable for small and medium-sized projects), 08Host compromise (low network latency, Asia-Pacific nodes). Remember:Peak number of people online x peak traffic per user x 1.3 redundancy, this formula carries the 90% scenario, leaving 10% to rely on surveillance to underwrite.
I forgot to say, the recent test 08Host found a tawdry operation: their Asia-Pacific nodes support “bandwidth warm-up”, 5 minutes in advance to reserve resources to prevent bursts, more than a temporary increase in humanized money. Anyway, choose CDN is like choosing teammates, you have to find with you to fight a hard battle, not the kind of traffic on the play dead plastic brother.
