רידוסינג סערווער מאַסע

אין דעם אַרטיקל, מיר וועלן דעלוו אין וואָס געוואקסן סערווער מאַסע אַקערז און דיסקוטירן פאַרשידן וועגן צו אַפּטאַמייז הויך-מאַסע פּראַסעסאַז. ספּעציעלע ופמערקזאַמקייט וועט זיין געגעבן צו קאָד אַפּטאַמאַזיישאַן אין Apache / Nginx און MySQL, מיר וועלן רעדן וועגן קאַטשינג ווי אַ אַגזיליערי געצייַג, און אויך באַטראַכטן מעגלעך פונדרויסנדיק טרעץ, אַזאַ ווי DDOS אנפאלן, און וועגן צו פאַרמייַדן זיי.

פארוואס סערווירער לאָדן אַקערז

איידער פּראַסידינג צו סערווער אַפּטאַמאַזיישאַן, עס איז נייטיק צו דורכפירן אַ גרונטיק אַנאַליסיס פון די קראַנט מאַסע אויף רעסורסן. דאָס כולל מעסטן קפּו מאַסע, באַראַן באַניץ, נעץ טעטיקייט און אנדערע שליסל פּאַראַמעטערס. פארשטאנד פון די דינאַמיק און שפּיץ לאָודז אַלאַוז יידענאַפייד באַטאַלנעקס און אָפּטימיזינג מיטל אַלאַקיישאַן, אַזוי ינקריסינג די פעסטקייַט און פאָרשטעלונג פון די סערווער ינפראַסטראַקטשער.

פארן ערשטן פראבלעם-לייזן פון הויכע סערווער לאסט, רעקאמענדירן מיר דורכצופירן אן אלגעמיינע סערווער דיאגנאסטיקס . אויב דאס איז נישט גענוג, איז נויטיג א מער דעטאלירטע אנאליז פון רעסורסן . אלס א הילפס-געצייג, קען אויספארשן די לאגס פון די לינוקס סערווער זיין נוצלעך, ווייל דאס איז וואו די מקור פון די פראבלעם געפינט זיך אין רוב פעלער.

אָפּטימיזינג אַפּאַטשי / נגינקס סערווירער

געוואקסן סערווירער לאָוד רעכט צו ינדעקסינג

געוואקסן מאַסע רעכט צו ינדעקסינג אויף די סערווער קענען פּאַסירן, פֿאַר בייַשפּיל, ווען זוכן ענדזשאַנז יבערקוקן אַ גרויס נומער פון בלעטער אויף דיין פּלאַץ. דאָס קען פירן צו אַ געוואקסן נוצן פון סערווער רעסורסן און, דעריבער, פּאַמעלעך די פאָרשטעלונג פון די פּלאַץ. ידענטיפיצירן די סיבה איז לעפיערעך פּשוט; איר דאַרפֿן צו עפענען די טעקע ליגן אין:

/var/www/httpd-logs/sitename.access.log

ווען ינדעקסט דורך זוכן ענדזשאַנז, דער באַניצער וועט זען איינסן פון די פאלגענדע נאַטור:

11.22.33.44 - - [Date and Time] "GET /your-page-path HTTP/1.1" 200 1234 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

אלס א ערשטע לייזונג צו רעדוצירן די לאסט, קענט איר ניצן די סעטינג פון מעטא טעגס "noindex" און "nofollow" אויף בלעטער וואס דארפן נישט אינדעקסירט ווערן. די צווייטע לייזונג איז די .htaccess טעקע, וואו איינטראגעס וואס קארעספאנדירן צו ספעציפישע זוכמאשינען דארפן צוגעגעבן ווערן, למשל, צו באהאלטן פון יאנדעקס און גוגל:

SetEnvIfNoCase User-Agent "^Yandex" search_bot
SetEnvIfNoCase User-Agent "^Googlebot" search_bot
Order Allow,Deny
Allow from all
Deny from env=search_bot

אזוי אויך, דארפן רעדאקטירונגען געמאכט ווערן פאר אנדערע זוכמאשינען. עס איז וויכטיג צו באמערקן אז די מעגלעכקייטן פון .htaccess זענען נישט באגרענעצט צו נאר בלאקירן אינדעקסירונג. מיר רעקאמענדירן צו ווערן מער באקאנט מיט זיינע הויפט אייגנשאפטן אין דעם ארטיקל.

ניצן קאַטשינג סעטטינגס

אומרעכטע קעשינג סעטינגס אויפן סערווער קענען אויך פירן צו הויכע לאסט. כדי צו אפטימיזירן דעם פאראמעטער, דארפן קארעספאנדירנדע ענדערונגען געמאכט ווערן אין די קאנפיגוראציע טעקעס אדער .htaccess . אין פאל פון Apache, איז די לעצטע אפציע בעסער, פאר Nginx – די ערשטע.

אויף אַן אַפּאַטשי סערווער, דאַרפֿסטו עפֿענען די .htacess טעקע און אַרײַנשטעלן דעם פֿאָלגנדיקן קאָד:

<FilesMatch ".(flv|gif|jpg|jpeg|png|ico|swf|js|css|pdf|doc|docx)$">
Header set Cache-Control "max-age=2592000"
</FilesMatch>

דערנאך, אַקטיווירן די Expires מאָדול מיטן באַפֿעל:

sudo a2enmod expires

נאָך וואָס, ריסטאַרט די וועב סערווער:

sudo service apache2 restart

און אַקטאַווייט די מאָדולע דורך ספּעציפיצירן:

ExpiresActive On

אויף אַ Nginx סערווער, איז עס גענוג צו לייגן דעם פאלגנדן קאָד צו דער קאָנפיגוראַציע טעקע:

location ~* .(jpg|jpeg|gif|png|ico|css|swf|flv|doc|docx)$ {
root /var/www/yoursite.com;
}

און דורכפירן אַ סערוויס רילאָוד:

sudo service nginx restart

באַמערק אַז מיט די סעטטינגס, וועלן די "Allow" און "Deny" דירעקטיוון ווערן בייפּאַסט.

ניצן דאַטאַ קאַמפּרעשאַן

אקטיוויזירן דאטן קאמפרעשאן ניצנדיק Gzip אויף Apache און Nginx וועב סערווערס העלפט רעדוצירן די צאל דאטן וואס ווערט טראנסמיטירט צווישן דעם סערווער און דעם קליענט, וואס פארבעסערט די פערפארמאנס און פארקלענערט די לאודינג צייט פון וועבזייטל.

כדי צו אקטיוויזירן Gzip אויף Apache , דארפט איר אקטיוויזירן דעם mod_deflate מאדול:

sudo a2enmod deflate

דערנאָך, ריסטאַרט די וועב סערווער:

sudo service apache2 restart

און לעסאָף, לייגן די פאלגענדע בלאָק צו די קאַנפיגיעריישאַן טעקע אָדער .htaccess:

<IfModule mod_deflate.c>
# Configure compression for specified file types
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/javascript application/javascript application/x-javascript application/json

# If the browser matches the specified pattern, apply compression only to text/html files
BrowserMatch ^Mozilla/4 gzip-only-text/html

# If the browser matches the specified version patterns of Mozilla 4.0.6, 4.0.7, 4.0.8, disable compression
BrowserMatch ^Mozilla/4\.0[678] no-gzip

# If the browser is MSIE (Internet Explorer), disable compression for all files except text/html
BrowserMatch \bMSIE !no-gzip !gzip-only-text/html

# If the request contains the specified pattern (extensions of image files), disable compression
SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png)$ no-gzip
</IfModule>

די קאַנפיגיעריישאַן ינייבאַלז קאַמפּרעשאַן פֿאַר זיכער טייפּס פון טעקעס און דיסייבאַלז עס פֿאַר בילדער.

אין פאַל פון Nginx , קאָנפיגוראַציע פּאַסירט אין דעם http בלאָק פון דער קאָנפיגוראַציע טעקע. דער פאלגענדער קאָד דאַרף צוגעגעבן ווערן:

gzip on;
gzip_disable "msie6";

# Adds the Vary header, indicating that the response may change depending on the Accept-Encoding header value
gzip_vary on;

# Enables compression for any proxy servers
gzip_proxied any;

# Sets the compression level. A value of 6 provides a good balance between compression efficiency and resource use
gzip_comp_level 6;

# Sets the size of the buffer for compressed data (16 buffers of 8 kilobytes each)
gzip_buffers 16 8k;

# Specifies that data compression should be used only for HTTP version 1.1 and higher
gzip_http_version 1.1;

# Sets the file types that can be compressed
gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

ענלעך צו Apache , דא ווערן די קאמפרעסיע פאראמעטערס פאר געוויסע טיפן טעקעס איינגעשטעלט. נאכדעם וואס מען מאכט ענדערונגען צו איינע פון ​​די וועב סערווערס, איז א סערוויס רילאוד נויטיג:

sudo service apache2 restart

Or

sudo service nginx restart

DDOS אַטאַק אויף די סערווירער

הויך סערווער מאַסע קענען פּאַסירן ווי אַ רעזולטאַט פון אַ DDoS באַפאַלן. ידענטיפיצירן דעם בייַזייַן פון אַ DDoS באַפאַלן קענען זיין געטאן דורך מאָניטאָרינג אַ פּלוצעמדיק פאַרגרעסערן אין פאַרקער, אַבנאָרמאַל ריקוועס און סערווער פאָרשטעלונג טראפנס. ריוויוינג לאָגס פֿאַר ריפּיטיד ריקוועס פֿון איין IP אַדרעס אָדער פּאָרט סקאַנינג קענען אויך אָנווייַזן אַ מעגלעך DDoS באַפאַלן. עס זענען פילע שוץ מיטלען, אָבער מיר וועלן נאָר דיסקוטירן די באַסיקס.

ניצן אַ CDN (קאָנטענט דעליווערי נעטוואָרק) . אַ CDN קען דינען ווי אַ פֿאַרמיטלער צווישן דיין וועב סערווער און באַניצער, פֿאַרטיילן טראַפיק און קאַשן אינהאַלט צו פֿאַרמינדערן די ווירקונג פֿון אַ DDoS אַטאַק. CDNs קענען אויך האָבן איינגעבויטע DDoS שוץ מעקאַניזמען, אַרייַנגערעכנט לאָוד פֿאַרטיילונג און טראַפיק פֿילטערינג.

קאָנפיגורירן פיירוואַלס און איינדרינגונג דעטעקציע סיסטעמען (IDS/IPS) . פיירוואַלס קענען זיין קאָנפיגורירט צו פילטערן טראַפיק באַזירט אויף פֿאַרשידענע קריטעריעס, אַזאַ ווי IP אַדרעסן און פּאָרטן. IDS/IPS קענען דעטעקטירן אַבנאָרמאַל טראַפיק נאַטור און בלאָקירן סאַספּישאַס קאַנעקשאַנז. די מכשירים קענען זיין עפעקטיוו אין טראַקינג און בלאָקירן פּאָטענציעל בייזוויליק טראַפיק.

קאַנפיגיער אַפּאַטשי און Nginx וועב סערווערס צו פאַרמינערן די פּראַל פון DDoS אנפאלן.

אלס א לייזונג פאר אפאטשי, אקטיוויזירן מיר דעם mod_evasive מאדול. כדי דאס צו טון, נעמט ארויס די קאמענטן אדער לייגט צו די פאלגנדע שורה אין דער httpd.conf אדער apache2.conf קאנפיגוראציע טעקע:

LoadModule evasive20_module modules/mod_evasive.so

אין דער זעלביקער טעקע, איר דאַרפֿן צו לייגן אַ סעטטינגס בלאָק:

<IfModule mod_evasive20.c>
# Hash table size for storing request information
DOSHashTableSize 3097

# Number of requests to one page before activating protection
DOSPageCount 2
DOSPageInterval 1

# Number of requests to all pages before activating protection
DOSSiteCount 50
DOSSiteInterval 1

# Blocking period in seconds for IP addresses
DOSBlockingPeriod 10
</IfModule>

אזוי אויך, מיר אקטיוויזירן דעם mod_ratelimit מאדול:

LoadModule ratelimit_module modules/mod_ratelimit.so

און לייג די קאַנפיגיעריישאַן:

<IfModule mod_ratelimit.c>
# Setting the output filter for rate limiting (Rate Limit)
SetOutputFilter RATE_LIMIT

# Beginning of the settings block for the location "/login"
<Location "/login">

# Setting the environment variable rate-limit with a value of 1
SetEnv rate-limit 1

# Ending of the settings block for the location "/login"
</Location>
</IfModule>

די קאָנפיגוראַציע פֿאַר Nginx איז ענלעך צו Apache . אין דער nginx.conf קאָנפיגוראַציע טעקע, דאַרפֿן די פֿאָלגנדיקע דירעקטיוון געניצט ווערן:

http {
...
# Defining a zone for connection limits
limit_conn_zone $binary_remote_addr zone=addr:10m;

# Defining a zone for request limits
limit_req_zone $binary_remote_addr zone=req_zone:10m rate=1r/s;

server {
        ...
        # Configuring connection limits
        limit_conn addr 10;

        # Configuring request limits
        limit_req zone=req_zone burst=5;

        ...
    }
}

נאָך ענדערונגען צו יעדער פון די סערוויסעס, זיי דאַרפֿן צו זיין רילאָודיד:

sudo systemctl restart apache2

אָדער:

sudo systemctl restart nginx

די ביישפילן צושטעלן בלויז אַ יקערדיק קאַנפיגיעריישאַן, וואָס קענען זיין צוגעפאסט נאָך דיפּענדינג אויף ספּעציפיש רעקווירעמענץ און די נאַטור פון אנפאלן.

אָפּטימיזינג MySQL קוויריז

אָפּטימיזירן MySQL דאַטאַבייס פֿראַגעס אויף אַ וועב סערווער קען מען דערגרייכן אין פֿאַרשידענע וועגן, און איינער פֿון זיי איז די ריכטיקע קאָנפֿיגוראַציע פֿון דער קאָנפֿיגוראַציע טעקע. טיפּישערווײַז הייסט די טעקע my.cnf אָדער my.ini און געפֿינט זיך אין דער /etc/ אָדער /etc/mysql/ דירעקטאָריע. איר דאַרפֿט עס עפֿענען און מאַכן די פֿאָלגנדיקע ענדערונגען:

[mysqld]
# Location of the file for recording slow queries. Be sure to replace it with your path
log-slow-queries = /var/log/mariadb/slow_queries.log

# Threshold time for considering slow queries (in seconds)
long_query_time = 5

# Enabling recording of queries that do not use indexes
log-queries-not-using-indexes = 1

# Disabling query caching
query_cache_size = 0
query_cache_type = 0
query_cache_limit = 1M

# Size of temporary tables
tmp_table_size = 16M
max_heap_table_size = 16M

# Size of the thread cache
thread_cache_size = 16

# Disabling name resolving
skip-name-resolve = 1

# Size of the InnoDB buffer pool. Set to 50-70% of available RAM
innodb_buffer_pool_size = 800M

# Size of the InnoDB log file
innodb_log_file_size = 200M

לאָמיר אויך באַטראַכטן נאָך רעקאַמאַנדיישאַנז וואָס קענען פאַסילאַטייט ינטעראַקשאַן מיט די סערווער דאַטאַבייס:

1. ניצן די דערקלערן באַפֿעלן איידער אַ SQL אָנפֿרעג צו פונאַנדערקלייַבן זייַן דורכפירונג. דאָס אַלאַוז איר צו באַקומען אַן דורכפירונג פּלאַן פֿאַר די אָנפֿרעג און באַשליסן וואָס ינדעקסיז זענען געניצט, וואָס טישן זענען סקאַנד, אאז"ו ו.
2. ינדעקסיז פאַרגיכערן דאַטן זוכן, אַזוי רעכט דיזיינד ינדעקסיז קענען באטייטיק פֿאַרבעסערן אָנפֿרעג פאָרשטעלונג. באַצאָלן ופמערקזאַמקייַט צו שפאלטן וואָס זענען אָפט געניצט אין וואו or פאַרבינדן conditions.
3. ויסמיידן ניצן SELECT *. ספּעציפיצירן בלויז די שפאלטן וואָס זענען באמת נייטיק פֿאַר דיין אָנפֿרעג, אַנשטאָט פון סאַלעקטינג אַלע שפאלטן אין אַ טיש.
4. ויסמיידן ניצן פאַנגקשאַנז אין וואו באדינגונגען. ניצן פאַנגקשאַנז (אַזאַ ווי נידעריקער, UPPER, לינק, רעכט) אין וואו טנאָים קענען מאַכן ינדעקסיז אַרויסגעוואָרפן. פּרוּווט צו ויסמייַדן זייער דירעקט נוצן אין באדינגונגען.
5. נוצן INNER JOIN ווו מעגלעך, ווי עס איז יוזשאַוואַלי מער עפעקטיוו. אויך, ענשור אַז די קאָראַספּאַנדינג שפאלטן פֿאַר דזשוינינג האָבן ינדעקסיז.
6. נוצן באַגרענעצן צו באַגרענעצן די נומער פון אומגעקערט ראָוז אויב איר דאַרפֿן צו באַקומען בלויז אַ זיכער נומער פון רעזולטאַטן.
7. באַטראַכטן קאַטשינג אָנפֿרעג רעזולטאַטן, ספּעציעל אויב זיי ראַרעלי טוישן, צו רעדוצירן סערווער מאַסע.

די מעיל סערווירער קריייץ הויך מאַסע אויף די סערווירער

אין דעם אָפּטייל וועלן מיר אויספאָרשן ווי אַזוי צו באַשטימען צי דער פּאָסט סערווער ליידט פון אַ הויכער לאָוד און וואָסערע טריט מען קען נעמען צו אָפּטימיזירן זיין אָפּעראַציע, אַרייַנגערעכנט קאָנטראָלירן די מעסעדזש קיו און קאָנפיגורירן סערווער פּאַראַמעטערס. אָנהייבן מיט קאָנטראָלירן די מעסעדזש קיו. די mailq יוטיליטי קען העלפֿן מיט דעם, צו אַקטיוויזירן עס, אַרייַן די קאָרעספּאָנדירנדיקע באַפֿעל אין טערמינאַל:

mailq

דאָס וועט ווייַזן אַ רשימה פון אַרטיקלען אין דער ריי, אויב קיין. יעדער אָנזאָג וועט זיין געוויזן מיט זיין יינציק ידענטיפיער און אינפֿאָרמאַציע וועגן די שיקט סטאַטוס. א ענלעך רעזולטאַט קענען זיין באקומען דורך ריוויוינג די פּאָסט קליענט לאָגס.

אין רובֿ פאלן, הויך מאַסע אַקערז אין די געשעעניש פון סערווער קאָמפּראָמיס ווען עס סטאַרץ שיקט ספּאַם. אָבער, אויב נאָך קאָנטראָלירונג דער אַדמיניסטראַטאָר איז זיכער אַז דער סערווער איז נישט אַטאַקירט פון די אַרויס און די יוזערז טאָן ניט פאַרלאָזן ספּאַם, עס איז צייט צו אַפּטאַמייז די פּאָסט סערווער. דאָ זענען די סטעפּס וואָס וועט העלפן:

1. פאַרזיכערן אַז די DNS רעקאָרדס פון דיין פעלד זענען ריכטיק קאַנפיגיערד, אַרייַנגערעכנט SPF, DKIM, און DMARC רעקאָרדס צו פֿאַרבעסערן פּאָסט עקספּרעס און באַשיצן קעגן ספּאַם. די ריכטיק קאַנפיגיעריישאַן פון פּאַראַמעטערס קענען זיין געפֿונען אין דעם אַרטיקל אויף פּאָסט סערווער דיאַגנאָסטיקס.
2. קאָנטראָלירן נעץ סעטטינגס, אַרייַנגערעכנט פיירוואַל קאַנפיגיעריישאַן און רוטינג כּללים, צו ויסמיידן בלאַקס און פאַרגיכערן פּאָסט עקספּרעס.
3. קאַנפיגיער אָנזאָג ריי פּאַראַמעטערס לויט צו סערווער מאַסע. דאָס קען אַרייַננעמען באַשטעטיקן די מאַקסימום ריי גרייס און טיימאַוץ.
4. באַטראַכטן די סאַלושאַנז וואָס מיר דיסקאַסט אין דעם אַרטיקל פריער. פּיריאַדיקלי אַפּטאַמייז די פּאָסט סערווער דאַטאַבייס צו פֿאַרבעסערן פאָרשטעלונג, נוצן קאַטשינג מעקאַניזאַמז צו פאַרגיכערן דאַטן זוכן און פּראַסעסינג, אַזאַ ווי דנס קוויריז.
5. אויב די פּאָסט סערווער נאָך קעסיידער ינקאַונטערז הויך מאַסע, באַטראַכטן סקיילינג אָפּציעס, אַזאַ ווי ניצן אַ קנויל פון פּאָסט סערווערס אָדער וואָלקן סאַלושאַנז.

סאָף

געוואקסן סערווער מאַסע גלייך אַפעקץ די לאָודינג גיכקייַט פון וועבזייטל, און לעסאָף ימפּאַקטינג באַניצער דערפאַרונג און שעם אין זוכן ענדזשאַנז. אזוי, יפעקטיוולי אָנפירונג דעם מאַסע פיעסעס אַ שליסל ראָלע אין ינשורינג קעסיידערדיק פאַנגקשאַנאַליטי פון די מיטל און ינקריסינג זייַן אַקסעסאַביליטי פֿאַר וויזאַטערז.