Оптимізація сервера для роботи з MediaWiki

</syntaxhighlight>

Перевірити середній розмір PHP-FPM процесу:

</syntaxhighlight>

~*/Special: 1;

Slowlog допоможе знайти реальну причину повільної роботи. Часто там видно Parser, LinksUpdate, SpecialPage, SyntaxHighlight, api.php, RecentChange або JobQueue.; # Збільшити proxy_read_timeout і fastcgi_read_timeout до 300s.; }

1. Увімкнути APCu.; # Увімкнути slow query log.; sudo nano /etc/nginx/nginx.conf

1. Додати кешування статичних файлів.; ~*(^|&)(diff=|oldid=|curid=) 1;

expires 30d;

4.1 Повний блок для http { }

1. Налаштувати real_ip на backend Nginx.; # Оптимізувати індекси або проблемні сторінки.; }:

access_log off;

server reached pm.max_children setting

<syntaxhighlight lang="nginx">
log_format realip_debug '$host client=$remote_addr proxy=$realip_remote_addr '

fastcgi_connect_timeout 60s;

 ~*BLEXBot 1;

 include fastcgi_params;

У конфігу сайту, як ілюстрація:
<syntaxhighlight lang="bash">
User-agent: SemrushBot
proxy_set_header X-Forwarded-Proto $scheme;
</div>
У <code>LocalSettings.php</code>:

 fastcgi_connect_timeout 60s;

 fastcgi_connect_timeout 60s;
 ~*Special: 1;
<div style="border-left: 6px solid #ff9800; background: #fff4e5; padding: 12px; margin: 12px 0;">

Якщо все добре:

</syntaxhighlight> </syntaxhighlight>

limit_req zone=bot_slow burst=20 nodelay;

21.; Рекомендований порядок впровадження

X-FastCGI-Cache: HIT
або:
Після зміни:

opcache.memory_consumption=256

 fastcgi_send_timeout 300s;

'''Якщо 504 виникає при збереженні сторінки, потрібно перевірити:'''

~^1:1:0:GET$ $binary_remote_addr;

default "";

pm.max_spare_servers = 30 </syntaxhighlight> Причина: у конфігу застосовується $mw_heavy_uri, але не оголошено відповідний map.;== 2.; Діагностика навантаження ==

як ілюстрація: </syntaxhighlight> pm.max_requests = 500

3.1 Frontend Nginx

~*AhrefsBot 1;

sudo tail -n 100 /var/log/nginx/error.log

У файлі:

proxy_read_timeout 300s;

location ~ \.php$ {
<syntaxhighlight lang="sql">
<div style="border-left: 6px solid #ff9800; background: #fff4e5; padding: 12px; margin: 12px 0;">

</div>

 ~^1:1:1:GET$ $binary_remote_addr;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

Цей блок потрібно вставити у:

gzip_min_length 1024;

</syntaxhighlight>

sudo systemctl restart php8.4-fpm

2.1 Перевірка процесів

pm.start_servers = 10

Disallow: /*action=history

Або:
<div style="border-left: 6px solid #2b7cff; background: #eef5ff; padding: 12px; margin: 12px 0;">
}

<div style="border-left: 6px solid #ff9800; background: #fff4e5; padding: 12px; margin: 12px 0;">

Створити каталог:
Перевірити кількість кодів відповідей:
 include fastcgi_params;

}

Особливо важкі запити для MediaWiki: $wgJobRunRate = 0;

$wgMainCacheType = CACHE_ACCEL;

</syntaxhighlight>

~*meta-webindexer 1;

Це небезпечно, бо клієнти зможуть підробляти IP через HTTP-заголовки.;</syntaxhighlight>

20.; Діагностика 504 Gateway Timeout

На frontend Nginx у блоці, який прокидує запити на backend, повинно бути:

send_timeout 300s;

include /etc/nginx/conf.d/*.conf;

sudo nano /etc/nginx/sites-available/wiki.erp.kyiv.ua

} </syntaxhighlight>

Disallow: /*diff=

Перегляд: User-agent: PerplexityBot

додатково істотно, щоб обмеження не зачіпали POST, бо збереження сторінок MediaWiki виконується саме через POST.; proxy_connect_timeout 60s; </syntaxhighlight> Помилка:

18.; Перевірка MySQL / MariaDB

limit_req zone=bot_slow burst=20 nodelay;

fastcgi_read_timeout 300s;

</syntaxhighlight>

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

proxy_set_header Host $host;

limit_conn bot_conn 5;

↓

</syntaxhighlight>

</syntaxhighlight>

<syntaxhighlight lang="nginx">
Встановлення:

15.; FastCGI cache в Nginx для анонімних GET

Додати cron від користувача www-data:

• оновити розширення SyntaxHighlight;
• уникати дуже великих блоків <syntaxhighlight>;
• закешувати сторінки з великими блоками коду;
• обмежити ботам швидкість доступу до oldid, diff, history;
• перевірити PHP-FPM slowlog.; # Перевірити OPcache.; Перегляд:

ps aux | grep php-fpm | sort -k3 -nr | head -20

Crawl-delay: 10
'''Перевага цього блоку:''' обмежуються тільки боти, тільки GET/HEAD-запити.; # Перевірити довгі запити.; ~*SemrushBot 1;
sudo nano /etc/php/8.4/fpm/pool.d/www.conf

$wgShowIPinHeader = false;
 proxy_set_header Host $host;

sudo nginx -t

pm.max_children = 60

proxy_set_header X-Real-IP $remote_addr;

 limit_req zone=bot_slow burst=20 nodelay;

~*PetalBot 1;

Очікуваний заголовок:

Рекомендовані параметри:

User-agent: CCBot

add_header Cache-Control "public";

php8.4-fpm

default "";

Frontend Nginx
потрібно збільшити <code>pm.max_children</code>.; }</code>:
<syntaxhighlight lang="bash">

} </syntaxhighlight>

</syntaxhighlight>

MediaWiki apc.ttl=3600

'xff="$http_x_forwarded_for" '

~*anthropic-ai 1;

~^1:0:1:GET$ $binary_remote_addr;

$wgParserCacheType = CACHE_ACCEL; sudo nano /etc/nginx/nginx.conf set_real_ip_from 192.168.20.225;

$wgSessionCacheType = CACHE_ACCEL;

<syntaxhighlight lang="bash">

У backend Nginx:

'''Не можна робити так:'''
<syntaxhighlight lang="text">
Пошук старих або неповних правил:

 fastcgi_cache MEDIAWIKI;

 ~*Amazonbot 1;
== 7.; Перевірка Nginx ==
<syntaxhighlight lang="bash">

• * * * * /usr/bin/php /var/www/wiki.erp.kyiv.ua/maintenance/runJobs.php --maxjobs 100 --maxtime 50 > /dev/null 2>&1

pm.min_spare_servers = 10

limit_req zone=bot_heavy_slow burst=5 nodelay;

set_real_ip_from 192.168.20.225;

<syntaxhighlight lang="text">

Crawl-delay: 30

action=raw
sudo tail -n 5000 /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -nr
pm.max_spare_servers = 20
Перевірка:
client=192.168.20.225

=== 9.2 Як порахувати pm.max_children ===

'''Увага:''' якщо PHP-FPM у вас слухає TCP, як ілюстрація <code>127.0.0.1:9000</code>, не змінюйте <code>fastcgi_pass</code> на socket.; sudo nginx -t
<syntaxhighlight lang="text">
 proxy_send_timeout 300s;

map $request_uri $mw_heavy_uri {
У PHP location:
=== Етап 3.; MediaWiki ===

Nginx має змогу затримувати зайві запити в черзі.; # Збереження сторінок не повинно потрапляти під bot limit.; api.php

 set $skip_cache 1;

== 12.; APCu для кешу MediaWiki ==

Правильний результат:

 set $skip_cache 1;

}

access_log /var/log/nginx/wiki_realip_debug.log realip_debug;
</div>
User-agent: Bytespider
sudo systemctl reload nginx
sudo grep -R "bot_heavy_key\|mw_heavy_uri\|bot_limit_key\|is_heavy_bot\|limit_req" /etc/nginx/
opcache.interned_strings_buffer=32
Подивитися конкретні URL з 504:

map $http_user_agent $is_heavy_bot {
sudo tail -f /var/log/mysql/mysql-slow.log
 ~*CCBot 1;
sudo tail -n 50000 /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -nr | head -50

 ~*(^|&)(hidebots=|limit=|from=|target=|namespace=|offset=|dir=) 1;

=== 3.2 Backend Nginx ===
<syntaxhighlight lang="bash">
Якщо основне навантаження створюють процеси:

sudo chown -R www-data:www-data /var/www/wiki.erp.kyiv.ua/cache істотно: збільшення timeout не лікує причину повільної роботи, але дає довгим операціям, як ілюстрація збереженню великої сторінки, завершитися без 504.; Основна ідея оптимізації MediaWiki: не без ускладнень збільшити кількість PHP-FPM воркерів, а зменшити кількість важких запитів, які доходять до PHP.; # Обережно впровадити FastCGI cache для анонімних GET.; # Використати nodelay.; pm.max_requests = 500 }

Crawl-delay: 30
Конфігурація:
User-agent: Amazonbot
 fastcgi_pass unix:/run/php/php8.4-fpm.sock;

if ($request_method != GET) {

apc.user_ttl=3600
<div style="border-left: 6px solid #2b7cff; background: #eef5ff; padding: 12px; margin: 12px 0;">
sudo nano /etc/php/8.4/fpm/php.ini

<syntaxhighlight lang="bash">

<syntaxhighlight lang="text">

pm = dynamic

Загальний статус: diff= </syntaxhighlight>

~^1:1:1:HEAD$ $binary_remote_addr;

pm.max_children = 60

Це одна з найважливіших оптимізацій для збереження сторінок. MediaWiki jobs не повинні виконуватись у звичайному веб-запиті користувача.; Неправильний результат: opcache.enable=1 </syntaxhighlight>

~*Bytespider 1;

17.; Кешування статичних файлів

Етап 1.; Безпечні термінові дії

include /etc/nginx/sites-enabled/*; location ~* \.(css|js|png|jpg|jpeg|gif|ico|svg|webp|woff|woff2)$ { php-fpm: pool www

limit_conn_zone $bot_limit_key zone=bot_conn:20m;


##
# Limit only bot GET/HEAD requests.; }</code> додати:

Crawl-delay: 30
apc.gc_ttl=3600
opcache.max_accelerated_files=20000

У PHP location:

<syntaxhighlight lang="nginx">

Рекомендований стартовий варіант:
if ($query_string != "") {
 ~*/wiki/Special: 1;
Файл:
limit_req_zone $bot_heavy_key zone=bot_heavy_slow:20m rate=10r/m;
<div style="border-left: 6px solid #ff9800; background: #fff4e5; padding: 12px; margin: 12px 0;">
<div style="border-left: 6px solid #d32f2f; background: #ffebee; padding: 12px; margin: 12px 0;">
sudo mkdir -p /var/cache/nginx/mediawiki

$wgUseFileCache = true;

php -m | grep -i apcu

<syntaxhighlight lang="nginx">

<syntaxhighlight lang="bash">

== OPcache для PHP 8.; 11.4 ==
limit_req zone=bot_heavy_slow burst=5 nodelay;
sudo nano /etc/php/8.4/fpm/pool.d/www.conf

Crawl-delay: 30

 proxy_pass http://BACKEND_IP;

'''robots.txt не є собою захистом від агресивних ботів.''' Але коректні боти можуть враховувати <code>Crawl-delay</code> і не сканувати важкі URL.; Перезапуск:
<syntaxhighlight lang="bash">
 ↓
limit_req zone=bot_slow burst=20;

'x_real_ip="$http_x_real_ip" '

Crawl-delay: 30

6.; Чому потрібен nodelay

Файл має змогу бути:

fastcgi_cache_bypass $skip_cache;
add_header X-FastCGI-Cache $upstream_cache_status always;
default 0;

return 429 "Too many requests.;=== Типові помилки ===

real_ip_recursive on;

9.1 Перевірка нестачі воркерів

</syntaxhighlight> Перевірка: </syntaxhighlight>

request_terminate_timeout = 300s </syntaxhighlight>

</syntaxhighlight>

User-agent: *
<syntaxhighlight lang="bash">
У <code>LocalSettings.php</code>:

↓

set_real_ip_from 0.0.0.0/0;

set $skip_cache 1;

це означає, що навантаження йде через PHP / MediaWiki.; User-agent: ClaudeBot

1. Збільшити pm.max_children.; # Проаналізувати важкі розширення.; # Додати rate limit тільки для ботів і тільки для GET/HEAD.; }:

proxy_read_timeout 300s;

</syntaxhighlight>

У server { ...;== robots.; 16.txt без повного блокування ==

всередині server { ...;

2. Heavy MediaWiki URI detection

Перевірка:

 fastcgi_pass unix:/run/php/php8.4-fpm.sock;
=== 3.3 Перевірка real IP ===
<syntaxhighlight lang="bash">
<syntaxhighlight lang="text">


##
# Limit only bots + heavy GET/HEAD requests
##

}

request_slowlog_timeout = 5s

fastcgi_cache_valid 404 1m;

<syntaxhighlight lang="text">
location @rate_limited {
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
map $query_string $mw_heavy_query {


##
# Rate limit zones
##

real_ip_header X-Real-IP;
$wgFileCacheDirectory = "$IP/cache";
 "1:GET" $binary_remote_addr;
<syntaxhighlight lang="bash">

'''Якщо в slow query log багато запитів до таблиць <code>page</code>, <code>revision</code>, <code>text</code>, <code>recentchanges</code>, <code>logging</code>, потрібно окремо аналізувати індекси, розмір таблиць і проблемні сторінки.'''
map "$is_heavy_bot:$mw_heavy_query:$mw_heavy_uri:$request_method" $bot_heavy_key {
Увімкнення slow query log:

pm.start_servers = 12

 ~*Applebot 1;

<syntaxhighlight lang="nginx">
<syntaxhighlight lang="nginx">
sudo nano /etc/php/8.4/fpm/conf.d/10-opcache.ini

<div style="border-left: 6px solid #2b7cff; background: #eef5ff; padding: 12px; margin: 12px 0;">

Backend Nginx
sudo systemctl restart php8.4-fpm

</syntaxhighlight>

fastcgi_cache_valid 200 301 302 10m;

Поточні запити: gzip on; User-agent: GPTBot

19.; SyntaxHighlight та інші важкі розширення

Шукати:

real_ip_header X-Real-IP;

send_timeout 300s; </syntaxhighlight>

slowlog = /var/log/php8.4-fpm-slow.log
set $skip_cache 0;
sudo tail -n 50000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -30

slowlog = /var/log/php8.4-fpm-slow.log Не варто віддавати всю RAM під PHP-FPM. Потрібен запас для MySQL/MariaDB.; } потрібно додати:

</syntaxhighlight>

• чи POST не потрапляє під rate limit;
• чи достатній proxy_read_timeout на frontend Nginx;
• чи достатній fastcgi_read_timeout на backend Nginx;
• чи не впирається PHP-FPM у pm.max_children;
• чи не виконуються MediaWiki jobs під час веб-запиту;
• що показує PHP-FPM slowlog.; default 0;

~*ChatGPT-User 1;

pm.max_children = RAM, доступна для PHP-FPM / середній розмір одного PHP-FPM процесу

~^1:1:0:HEAD$ $binary_remote_addr;

sudo crontab -u www-data -e

Disallow: /w/index.php?title=Special:

Якщо є собою:

У <code>LocalSettings.php</code>:

location ~ \.php$ {

<syntaxhighlight lang="php">

limit_req_status 429;
<syntaxhighlight lang="bash">
 proxy_set_header X-Forwarded-Proto $scheme;

 ↓

 ~*facebookexternalhit 1;
<syntaxhighlight lang="nginx">
sudo systemctl restart php8.4-fpm
<syntaxhighlight lang="bash">

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
##
# Real client IP from frontend nginx
##

sudo tail -f /var/log/nginx/wiki_realip_debug.log
Рекомендації:
== конфігурація php8.; 9.4-fpm ==


##
# Bot detection
##

З <code>nodelay</code>:
sudo nginx -t

apc.shm_size=256M
це означає, що сторінки з підсвіткою коду можуть створювати велике навантаження.;

request_slowlog_timeout = 5s limit_req zone=bot_slow burst=20 nodelay; </syntaxhighlight> pm = dynamic opcache.validate_timestamps=1

Найважливіші зміни:

додати або перевірити:
sudo systemctl reload nginx
proxy_connect_timeout 60s;
<syntaxhighlight lang="bash">

2.3 Топ User-Agent

~^1:0:1:HEAD$ $binary_remote_addr;

}

2.4 Топ URL

Мета статті: зменшити навантаження на сервер MediaWiki, стабілізувати роботу php8.4-fpm, обмежити агресивних ботів за швидкістю, але не закривати їм доступ в цілому.; Окремо варто відзначити Nginx, системи, файлового кешу і службових задач MediaWiki.; fastcgi_cache_path /var/cache/nginx/mediawiki levels=1:2 keys_zone=MEDIAWIKI:200m inactive=60m max_size=5g; Crawl-delay: 30

'"$request" $status "$http_user_agent"';

limit_req_zone $bot_limit_key zone=bot_slow:20m rate=1r/s;
Після впровадження цих змін сервер має краще витримувати активність ботів, не створюючи проблем для звичайних користувачів і редакторів MediaWiki.; Please slow down.\n";

}

<syntaxhighlight lang="bash">
Це має змогу викликати 429, затримки або навіть 504.; '''Якщо backend Nginx бачить тільки IP frontend-проксі, то limit_req буде рахувати всіх користувачів і ботів як одного клієнта.'''
pm.min_spare_servers = 12

<syntaxhighlight lang="text">

Crawl-delay: 30
<syntaxhighlight lang="bash">
curl -I https://wiki.example.com/wiki/Main_Page

Тоді можна поставити:

sudo tail -n 5000 /var/log/nginx/access.log | awk '$9 == 504 {print $1, $6, $7, $9, $12}' | tail -50 Disallow: /*action=raw </syntaxhighlight> SET GLOBAL long_query_time = 1;

fastcgi_cache_key "$scheme$request_method$host$request_uri"; sudo tail -n 50000 /var/log/nginx/access.log | awk -F\" '{print $6}' | sort | uniq -c | sort -nr | head -30

14. File cache MediaWiki

~*PerplexityBot 1;

Disallow: /*action=edit

Висновок

error_page 429 = @rate_limited;

map "$is_heavy_bot:$request_method" $bot_limit_key {

~*Baiduspider 1;

mysqladmin processlist

Етап 4.; Кешування Nginx

4.; Обмеження швидкості ботів без повного блокування

</syntaxhighlight>

sudo systemctl restart php8.4-fpm unknown "bot_heavy_key" variable

~*MJ12bot 1;

== 13.; Винесення MediaWiki Job Queue з веб-запитів ==
Створити каталог:

де <code>192.168.20.225</code> — IP frontend Nginx.;<div style="border-left: 6px solid #d32f2f; background: #ffebee; padding: 12px; margin: 12px 0;">
Приклад:
if ($http_cookie ~* "UserID|Token|session|mediawiki") {

</syntaxhighlight> Приклад: Приклад:

add_header Retry-After 30 always;

}

8.; Таймаути для уникнення 504

mysqladmin status

Етап 5.; База даних

8.2 Backend Nginx

 "1:HEAD" $binary_remote_addr;

action=edit

10. PHP-FPM slowlog

дозволені запити проходять одразу, а зайві швидше отримують:

proxy_send_timeout 300s; </syntaxhighlight>

sudo chown -R www-data:www-data /var/cache/nginx/mediawiki </syntaxhighlight>

У PHP location додати:

У <code>http { ...; # Перевірити повідомлення <code>server reached pm.max_children</code>.; ##

htop
 limit_req zone=bot_heavy_slow burst=5 nodelay;
<syntaxhighlight lang="bash">
 ↓

2. Heavy MediaWiki query detection

</syntaxhighlight>

1.; Типова схема роботи

}

proxy_set_header X-Real-IP $remote_addr;

python3 ...; php -i | grep -i opcache

 fastcgi_send_timeout 300s;

 ~*ClaudeBot 1;

oldid=

</syntaxhighlight>

fastcgi_read_timeout 300s;

8.1 Frontend Nginx

sudo systemctl reload nginx користувач системи / бот

3.; Коректне визначення реального IP через два Nginx

</syntaxhighlight> Crawl-delay: 30 </syntaxhighlight>

sudo nano /var/www/wiki.erp.kyiv.ua/robots.txt Повний приклад PHP location: Disallow: /*oldid=

Без <code>nodelay</code>:

</div>
gzip_comp_level 5;

504 Gateway Timeout означає, що Nginx не дочекався відповіді від upstream.; Помилка:

</syntaxhighlight>

У location з <code>proxy_pass</code>:
12000 MB / 180 MB = 66
apc.enabled=1
<syntaxhighlight lang="nginx">
<syntaxhighlight lang="bash">
всередину секції <code>http { ...; POST-запити, тобто збереження сторінок, не повинні потрапляти під цей rate limit.; }</code> можна тимчасово додати:

MySQL / MariaDB
Якщо в <code>htop</code> видно процеси:
opcache.revalidate_freq=60

gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;

opcache.save_comments=1
Після змін:
<syntaxhighlight lang="bash">

upstream timed out while reading response header from upstream

<syntaxhighlight lang="text">

<syntaxhighlight lang="nginx">

істотно: якщо перед MediaWiki стоїть ще один Nginx, backend-сервер повинен бачити реальні IP користувачів, а не тільки IP frontend-проксі.; default 0;

Етап 2.; PHP-FPM

client=92.222.104.195 proxy=192.168.20.225

5.; конфігурація server-блоку MediaWiki

unknown "mw_heavy_uri" variable

Special:

</syntaxhighlight> </syntaxhighlight> </syntaxhighlight> pm.max_children = 80

~*YandexBot 1;

~*GPTBot 1;

</syntaxhighlight> Рекомендація: для захисту живих користувачів краще використовувати nodelay, щоб Nginx не накопичував довгу чергу запитів.; задача — не забороняти ботам доступ через 403, а зменшити швидкість їхніх запитів.; # Rate limit має діяти тільки на GET/HEAD, не на POST.; }, бажано до рядків:

У http { ...;

<syntaxhighlight lang="bash">
ps aux | grep "php-fpm: pool" | awk '{sum+=$6; n++} END {if (n>0) print "avg:", sum/n/1024, "MB", "count:", n}'

</div>
<syntaxhighlight lang="ini">

'''Увага:''' FastCGI cache потрібно впроваджувати обережно, щоб не кешувати сторінки авторизованих користувачів.; # Перевірити, що <code>POST</code> не лімітується.; # Увімкнути slowlog.; # Винести Job Queue в cron.; extensions/SyntaxHighlight_GeSHi/...; # POST is not limited, so MediaWiki save actions are not affected.; Залишайте свій робочий варіант.; Перезапуск:

Перевірка:

location / {
<syntaxhighlight lang="bash">
SET GLOBAL slow_query_log = 'ON';

sudo journalctl -u php8.4-fpm | grep -i "max_children" | tail -20

Файл pool-конфігурації:

429 Too Many Requests sudo nano /etc/php/8.4/fpm/conf.d/20-apcu.ini

<syntaxhighlight lang="bash">

sudo tail -f /var/log/php8.4-fpm-slow.log
На backend Nginx у файлі:
у секції <code>http { ...; # OPcache, APCu і кешування анонімних сторінок суттєво зменшують навантаження.; # Поставити <code>request_terminate_timeout = 300s</code>.; # MediaWiki jobs краще виконувати через cron.; # Ботів потрібно обмежувати за швидкістю, а не блокувати в цілому.; Формула:
=== 2.2 Топ IP за кількістю запитів ===

У розглянутій конфігурації сайт функціонує приблизно так:

 ~*DotBot 1;
$wgMessageCacheType = CACHE_ACCEL;
<syntaxhighlight lang="bash">
<syntaxhighlight lang="bash">
real_ip_recursive on;

sudo apt install php8.4-apcu

</syntaxhighlight>

Причина: у location застосовується limit_req zone=bot_heavy_slow, але в http { } не оголошено $bot_heavy_key.; # Перевірити, що авторизовані сторінки не кешуються.; # Увімкнути файловий кеш.; User-agent: AhrefsBot

sudo mkdir -p /var/www/wiki.erp.kyiv.ua/cache Перезапуск:

fastcgi_no_cache $skip_cache;

</syntaxhighlight>

У потрібному server { ...; # PHP-FPM має мати достатньо воркерів.;</syntaxhighlight>

index.php?title= } fastcgi_read_timeout 300s;

1. Backend Nginx має бачити реальний IP клієнта.; # Slowlog PHP-FPM і slow query log MySQL потрібні для пошуку реальної причини затримок.; ~*(^|&)(action=edit|action=history|action=raw|action=info|action=purge) 1;

action=history fastcgi_send_timeout 300s;