[Red envelope rain pressure test environment]

Red envelope rain pressure test environment

1. Number of users participating in the event: 100,000
2. Red envelope rain duration: 30 minutes
3. 5 games in total, each lasting 30 seconds
4. Number of requests made by each user during each red envelope shower: 90
5. Response time: 500 milliseconds
6. Usage per machine: 80% CPU and memory, 2MB of bandwidth per request
7. Points are used as the basic weight, and the weighted average of the activity and contribution indicators is used as the adjustment weight.
8. Total red envelope amount: 100,000 yuan
9. Minimum red envelope amount: 0.01 yuan
10. Maximum red envelope amount: 10 yuan
11. 70% of requests are concentrated in the first 15 minutes
12. Users initiate 3 requests per second
13. Total number of users: 300,000
14. Number of people online: 30,000
15. Environment UK and Poland
16. The average usage time of daily active users is about 30 minutes per day, and the number of opens is 5-6 times per day.
17. Java environment/SpringBoot+SpringCloud+MyBatis/Redis/MySQL/RocketMQ/JDK8
18. Standalone deployment

Concurrency estimate

Calculate the total number of requests during the red envelope rain period: Total number of requests = number of users x number of requests issued by each user during the red envelope rain period Total number of requests = 100,000 x 15 = 1.5 million times

Calculate the number of requests per minute during the red envelope rain: Number of requests per minute = Total number of requests ÷ Duration of the red envelope rain (minutes) Number of requests per minute = 1.5 million ÷ 30 = 50,000 times/minute

Peak period: 1.5 million x 0.7 = 1.05 million times, 1.05 million times ÷ 15 = 70,000 times/minute

Peak:

Points and weights

Users get 10 points for publishing articles, 1 point for liking and commenting, and 5 points for sharing.

Weight = Points + 0.5 * Activity + 0.5 * Contribution

For new users, the activity ratio is 70% and the contribution ratio is 30%.

New users can receive higher activity weights to encourage them to participate in platform activities. Activity and contribution ratio: 70:30.

Activity weight distribution:

The weight of login frequency can be 20%.
The weight of the number of articles read can be 30%.
The weight of topics followed can be 10%.
The weight of shared content can be 10%.

Contribution weight distribution:

The weight of the quality of published articles can be 10%,
the weight of the number of likes can be 10%,
the weight of the number of comments can be 5%, and
the weight of the number of shares can be 5%.

For authors of high-quality works, the activity ratio is 30% and the contribution ratio is 70%.

Analyze users based on user behavior data. Authors of high-quality works can receive higher contribution weights to encourage them to continue creating. Ratio of activity and contribution: 30:70

Activity indicator weight:

Frequency of login: 5%
Number of articles read: 5%
Topics followed: 5%
Content shared: 15%

Contribution index weight:

Quality of published articles: 25%
Number of likes: 15%
Number of comments: 15%
Number of shares: 15%

For ordinary users, the activity ratio is 50% and the contribution ratio is 50%.

The ratio of activity and contribution of ordinary users: 50:50.

Activity weight distribution

Frequency of login: 30%
Number of articles read: 30%
Topics followed and content shared: 40%
Frequency of login can account for 15% of the total weight
Number of articles read can account for 15% of the total weight
Topics followed can account for 10% of the total weight %
Shared content can account for 10% of the total weight

Contribution weight distribution

The quality of the article can account for 15% of the total weight.
The number of likes can account for 10% of the total weight.
The number of comments can account for 10% of the total weight.
The number of shares can account for 15% of the total weight.

The number of red envelopes distributed by each user

First of all, the red envelope shower must have been generated in advance, and the specific amount and quantity have been split into 60 during the preheating stage.

The survival time of each red envelope

Distribution according to age, 2 seconds for those over 60 years old and 1.5 seconds for those under 60 years old

Randomly assign red envelope locations

Generate random numbers on the backend, and send the location and quantity to the front-end for presentation. This prevents users from using debugging tools to obtain the random number algorithm on the client, thus affecting the location of the red envelope.

Red envelope speed, red envelope movement trajectory, and red envelope landing

The speed of the red envelope, the trajectory of the red envelope and the way the red envelope lands are all important factors in designing the game experience and user experience. Here are some reference values:

1. Red envelope speed: Generally speaking, the red envelope speed should not be too fast and not too slow to ensure that players have enough time to click on the red envelope. A guideline value for speed is 40 to 60 pixels of movement per second.

2. Red envelope movement trajectories: In order to increase the fun and challenge of the game, different red envelope movement trajectories can be designed. Reference values ​​include floating up and down, swinging left and right, flying diagonally, etc.

3. Red envelope landing method: The landing method can be designed to rebound when it falls to the ground, stop directly when it falls to the ground, etc. The reference value is the elastic coefficient of rebound after falling to the ground, which is set to 0.6 to 0.8.

It should be noted that the above reference values ​​are for reference only, and the actual design should be adjusted based on the game type and player group.

Red envelope status and snatching results

The red envelope status of Red Envelope Rain can be designed as the following:

1. Not started status: Before the activity time, the red envelope rain activity will be displayed as not started, and the user cannot perform any operations.

2. In-progress status: After the event starts, Red Envelope Rain will enter the in-progress status. At this time, users can participate in the red envelope grabbing activity within the specified time.

3. End state: When the specified time reaches or the number of red envelopes reaches the limit, the red envelope rain activity will enter the end state, and the user cannot perform any operations at this time.

The snatching results can be designed as follows:

1. Grabbing a red envelope: After users grab a red envelope, they can see the amount of the red envelope or coupon information in the pop-up prompt box.

2. Unsnatched red envelopes: If the user does not grab the red envelopes, the user can see the unsnatched information reminder in the pop-up prompt box, and can continue to wait for the next round of red envelope rain.

3. Already grabbed: After the red envelope rain event ends, if the red envelope has been snatched up, the user can see the information prompt that the red envelope has been grabbed.

Server environment configuration

Huawei Cloud

2 sets of 8-core 16GB general-purpose SSD 500GB
cloud database Redis 2 cores 4 nodes
Cloud database primary and backup 4-core 16GB general-purpose SSD 200GB
elastic load balancing
Content distribution network
Disadvantages are not available in the UK, only annual and monthly subscriptions

Ali Cloud

Advantages of 3 8-core 16GB general-purpose SSD500GB
, with servers in London, UK, and support pay-as-you-go

ALB load balancing (up to one million concurrency) billing method:
https://help.aliyun.com/document_detail/447066.html?spm=a2c4g.311110.0.0.49403365fCu0sZ
ALB specifications:
https://help.aliyun.com/ document_detail/197202.html?spm=a2c4g.250240.0.0.6e69253bJsXvzj

CDN defaults to billing by volume, but if you want yearly and monthly billing, you can purchase a resource package and use the resource package for deduction. For
specific deduction standards, please refer to the following document:
https://help.aliyun.com/zh/cdn/product -overview/billing-rules-of-basic-services?spm=a2c4g.11186623.0.0.32ec4ebfZpo5tP

Tencent Cloud

The Frankfurt node covers users in Europe, the bandwidth is mainly for overseas, and the mainland access delay is high.

Calculate the number of visits from 300,000 users according to the 80/20 rule

Assume that there are 300,000 users and the proportion of users who visit the website every day is 20%, then approximately 60,000 users visit the website every day.
Assuming that each user clicks 6 times on average, then the total page views PV=36W.
There are 24 hours in a day. According to the 80/20 rule, most users are active every day in (24 * 0.2), which is approximately equal to within 5 hours, and most users refer to (36w clicks * 80%), which is approximately equal to 28.8W (PV), which means that within 5 hours, there will be about 28.8W clicks, which is about 16 (28.8W/5 hours/3600) requests per second.
16 is just an average number. During these 5 hours, the request volume is not necessarily uniform, and there may be a situation where a large number of users visit together (for example, for websites like Taobao, the peak hours of daily visits are concentrated at 14:00 pm and 21:00 pm, of which 21 :00 is the peak number of visits in a day). Normally, the request volume during peak traffic hours is 3 to 4 times the average request volume (this is an empirical value), and we calculate it as 4 times. Then during these 5 hours, there may be 64 requests per second. Therefore, the problem has changed from supporting 30W users to a specific problem, that is, the server needs to be able to support 64 requests per second (QPS=64). And that’s just for daily visits.

In the stress test environment, there were 100,000 users of the red envelope rain, and there were 5 games in total. The duration of the red envelope rain was: 30 minutes, one game every six minutes. On average, there were about 20,000 users in each game initiating 3 requests per second, and each time lasted for 30 seconds. Seconds, 2w*3=6W(PV), 6w/30=2000 requests per second. The peak value of 4 times is 8000 requests per second (QPS), and TPS is (8000/0.5) = 16000 (TPS refers to the number of transactions per second, that is, how many operations can be completed per second).

Tomcat influencing factors

Tomcat is a Java-based Web server that requires a TCP connection to communicate with clients. TCP connections have the largest overhead on system resources in memory, as they require setting up read and write buffers. On Linux systems, the minimum size of these two buffers is 4096 bytes. Therefore, the minimum memory occupied by a tcp connection is 4096+4096 = 8k. If the machine memory is 8G, then the maximum number of concurrency is about 1 million. However, in actual applications, due to the Linux kernel's restrictions on some resources and the impact of program business processing, it is difficult to reach 1 million connections with 8GB of memory. For Red Packet Rain, this level of connection is basically not available, so there is no need to worry about this factor.

Tomcat relies on the configuration of the JVM, and the size of the JVM memory is affected by the server configuration. For example, for a server with 2 cores and 4G of memory, the memory allocated to the JVM process is approximately 2G. This is because the server itself also requires memory, and memory needs to be reserved for other processes. This 2G memory also needs to be allocated to stack memory, heap memory and meta space. Therefore, the available heap memory is approximately 1G.

The configuration of Tomcat itself: accept-count: This is the maximum waiting number. When the number of HTTP requests reaches the maximum number of threads of Tomcat, if a new HTTP request arrives, Tomcat will put the request in the waiting queue. This acceptCount refers to the maximum number of waits that can be accepted, and the default value is 100. If the waiting queue is also filled, new requests will be rejected by Tomcat (connection refused).
maxThreads: This is the maximum number of threads. Whenever an HTTP request arrives at the Web service, Tomcat will create a thread to handle the request. maxThreads determines how many requests the Web service container can handle at the same time. The default value of maxThreads is 200, and it is recommended to increase it. However, adding threads will have costs. More threads will not only bring more thread context switching costs, but also consume more memory. By default, the JVM allocates a thread stack size of 1M when creating a new thread, so more threads means more memory is required. The experience value for the number of threads is: 1 core, 2g memory, 200 experience value for the number of threads; 4 cores, 8g memory, the experience value for the number of threads, 800.
maxConnections: This is the maximum number of connections. This parameter specifies the maximum number of connections that Tomcat can accept at the same time. For Java's blocking BIO, the default value is the value of maxthreads; if a custom Executor is used in BIO mode, the default value will be the value of maxthreads in the executor. For Java's new NIO mode, the default value of maxConnections is 10000. For APR/native IO mode on Windows, the default value of maxConnections is 8192.
If set to -1, the maxconnections function is disabled, indicating that the number of connections to the tomcat container is not limited. The relationship between maxConnections and accept-count is: when the number of connections reaches the maximum value maxConnections, the system will continue to receive connections, but will not exceed the value of acceptCount.