How to take the load off the north with one byte and a logarithmic function
It is likely that you noticed that your north often performs work that, strictly speaking, can hardly be called a payload. Usually, these are the cases when the client performs certain actions that require server work, but not directed to the result you have planned.
In conditions when correctly written code does not cause significant loads on the existing equipment with excessive resources, such phenomena may not attract much attention. However, in non-ideal conditions, this behavior may already, at a minimum, distract server time and interfere with other clients, but at a maximum - entail financial costs. And if you consider the preamble to be relevant for yourself, let's designate actions within the framework of the described phenomenon as negative, and let all the rest be positive.
And if you decide to neutralize similar, unworthy of a gentleman, deviations of client behavior, let's define what we are going to attribute to the negative manifestations of his nature. And here everything is pretty simple: 3r3r14. a set of repetitive actions, united on the basis of the absence of a semantic load [/i] , we will call negative 3r3147. . However, hereinafter, as part of an individual project, you are free to concretize and expand the definitions that I submit.
Now we need to learn how to highlight the sign of the absence of semantic load in the client's request. But before that, to be able to track the totality of such actions, we need to use a client session.
Now I will assume that you are sure to manage client sessions. One way or another, we will need it. As is known, in general, a client session has a unique identifier, as well as a certain set of conditional data necessary for management within an individual project. Of course, obviously, this data set is strictly verified and defined solely for your needs. With proper planning, such data is brief, concise and, at the same time, have more than one purpose. As a rule, the session contains the time stamp of the last client request. This value is primarily used to identify and delete obsolete sessions, it can be used to determine user activity and for some other functional features. One of these features will be the implementation of our functionality. However, it will not do without the introduction of a new component. But, as promised at the very beginning, all we need is to add just one byte to your data set. But more on that later.
The semantic load of the query
Now consider the behavior of your client. After successful connection and establishment of a communication channel, the client sends a request to the server, receives data, on the basis of which forms the next request. Let us single out the information we are interested in, on the basis of which we will make a decision:
The time spent by the client on receiving data from the last request, making a decision, forming and sending the next request;
The level of trust in customer requests. As a rule, the value of this attribute determines the connection between the session and the account, the account level and the like;
The nature of the request: does the request imply the possibility of an immediate response from the client, or requires a conscious analysis of the data obtained to make a decision;
Reference form of client behavior for a transmitted request.
This information is quite enough. Now it remains for us to express them in certain numerical representations for further calculation.
The first paragraph, call it "TIME" , is calculated as the difference in seconds between the current time and the time of the last request.
The second paragraph, call it "SAFE" conditional. Let it be a value in the range from 0 to ? increasing from a guest session to a very trusted user session.
The third point, let it be "AUTO" , answers the question "YES" or "NO." Its shape is obvious.
The fourth point, called 3r3146. "NORM" , we need to assign a reference form of behavior. Since the actions of the client in our set of information are characterized by time, then we will set this parameter along the time scale.
The logic of behavior
So, we have expressed our idea of the current query in numerical equivalent. Now it is time to calculate, based on the available data, the conditional value of the semantic load of the current query. But before that, a little more theory.
To make a request meaningful, a person definitely needs time. Sometimes more, sometimes less. A decrease in the analysis time of the server response to an increase in the number of requests reduces the semantic load of such requests in a progression, while an increase in the decision time to a decrease in the number of requests indicates the opposite. Along with this, too long periods of time indicate a lack of attention from the client, which is why they are limited to a conditional time limit.
This behavior can be expressed through a graph of the logarithmic function.
Thus, knowing the point of reference "NORM" for every 3r3146. "TIME" [/b] we have the possibility of obtaining a signed value characterizing the presence or absence of the semantic load in the request. From now on we will call it “RATE” 3r3147. .
Having calculated the load value of an individual query, we will determine whether the user's actions in time are positive, or whether his actions should be limited.
It should be noted here that not everyone interpreted as negative, requests in aggregate, have the appropriate coloring. We have no right to exclude cases when the client, through a series of short requests, seeks to reach the location of the information of interest. It is for this reason that we need to evaluate the actions of the client in time.
For this purpose, we introduce a certain counter of the “points” of the client, let's call it [b] "LOAD" . The range of values can be perfectly placed in one byte, that is, from 0 to 255. With each client request, we will add to it the sign value of the semantic load of the query 3r3146. “RATE” 3r3147. . Thus, the following inquiries with a short interval will significantly increase 3r3146. “LOAD” 3r3147. , after which, requests with a long interval will decrease this value.
In the case when the client's behavior is clearly contrary to good tone, his session will quickly become a leader in the parameter 3r3146. “LOAD” 3r3147. . And here are also options for behavior.
We introduce two more values: warning and limiting. When reaching the parameter 3r3146. “LOAD” 3r3147. conditionally "dangerous" values, may be partially limited processing of customer requests. However, if the request interval does not decrease, when the limit value is reached, it will be logical to block the client’s address.
Imagine a sample session repository in the form of the following table in the MySQL dialect.
3r3161. CREATE TABLE `sess_info`
`Time` INTEGER UNSIGNED COMMENT 'Session last request time',
` User` INTEGER UNSIGNED COMMENT 'Session account id',
Load` TINYINT UNSIGNED COMMENT 'Session loading value',
`Ipv4` INTEG UNSIGNED COMMENT 'Session remote ipv4 or ipv6 signature',
`Name` CHAR (64) COMMENT 'Session name',
COMMENT = 'Sessions list' ROW_FORMAT = FIXED;
To calculate the meaningfulness of an individual request, we select a separate function “sess_rate” (for brevity, the implementation will use PHP): 3r-3261.
3r3208. //* $ show = "TIME" - the difference in seconds between the current time 3r-3270. //* and the time of the last request
//* $ base = "NORM" is the reference form of behavior in
seconds. //* $ soft = "SAFE" - level of trust in client requests, 3r-3270. //* the softness of the distribution of the result values
function sess_rate ($ show, $ base = 2? $ soft = 4)
//* Restrict the input value to one hour.
//* We assume that if the user is
//* does not respond for more than an hour, meaning
//* request load will not change
$ show = min (max ($ show, 0), flTIME_HOUR);
//* Consider the semantic load of the request
//* and limit the possible result to the range
return min (max ((int) (-log ((($ show + 1) * 1 /($ base + 1)), ??? + (??? * $ soft)), -128), 128);
The following function “sess_wait” is called along with the server sending a response to the client and storing the information in the session repository: 3r-3261.
3r3208. function sess_wait ()
//* The current time is
$ time = microtime ();
//* Sign of AJAX request. Such requests imply the possibility of
//* quick reaction of the client, the parameter “AUTO”
$ ajax = is_ajax_request ();
//* The parameter "TIME" - the difference in seconds between the current time 3r-3270. //* and the time of the last request
$ show = ($ time - $ sess['time']);
//* “NORM” is the reference form of behavior in seconds
$ norm = $ ajax? 10:20;
//* "SAFE" - the level of confidence in client requests
$ soft = ($ sess['user']> 0)? 6: 4;
//* "RATE" - the sign value of the presence of the semantic load (range: -128128) 3r-3270. $ rate = sess_rate ($ show, $ norm, $ soft);
//* The semantic load of the session (range: 0255)
$ load = max (? min (($ sess['load']+ $ rate), 255));
//* Next, write the value of $ load to the session and
//* save it to the database
The result is
In conclusion, I will give as an example of the work the returned values (or the semantic load factor of the “RATE” query) for “TIME” from 0 to 59 seconds, with “NORM” = 20 seconds: 3r-3261.
0 = 35; 1 = 27; 2 = 22; 3 = 19; 4 = 16; 5 = 14; 6 = 12;
7 = 11; 8 = 9; 9 = 8; 10 = 7; 11 = 6; 12 = 5; 13 = 4;
14 = 3; 15 = 3; 16 = 2; 17 = 1; 18 = 1; 19 = 0; 20 = 0;
21 = 0; 22 = -1; 23 = -1; 24 = -2; 25 = -2; 26 = -2; 27 = -3;
28 = -3; 29 = -4; 30 = -4; 31 = -4; 32 = -5; 33 = -5; 34 = -5;
35 = -6; 36 = -6; 37 = -6; 38 = -7; 39 = -7; 40 = -7; 41 = -8;
42 = -8; 43 = -8; 44 = -8; 45 = -9; 46 = -9; 47 = -9; 48 = -9;
49 = -10; 50 = -10; 51 = -10; 52 = -10; 53 = -10; 54 = -11; 55 = -11;
56 = -11; 57 = -11; 58 = -11; 59 = -12; 60 = -12;
It may be interesting
Situs QQ Online
Situs QQ Online