Часть контента не грузится с ошибкой ERR_CONNECTION_TIMED_OUT

verfaa

Профессор
Регистрация
29 Янв 2007
Сообщения
416
Реакции
49
Приветствую всех.
Есть сайт, который с недавнего времени стал очень долго грузиться.
При запросе страницы часть контента отдается практически мгновенно, затем загрузка как бы подвисает и оставшаяся часть контента выдается через 10-30 секунд, а на часть контента google chrome пишет ошибку Net::ERR_CONNECTION_TIMED_OUT.
Такое продолжается уже неделю, ранее все работало хорошо, пользователи стали жаловаться.

Сервер выделенный, проект самопис.

На сервере установлен nginx/1.0.15 и PHP: 5.5.29

Вот скрины:
3e11339317b8a0f6c633b5bd0789f04e.png


Картинки которые не загрузились с ошибкой ERR_CONNECTION_TIMED_OUT на сервере есть, напрямую грузятся очень быстро.
Если рефрешить страницу, часть контента будет отдаваться быстро - 30-60 мс, часть очень долго 10-20 сек, а часть (причем случайная - картинки, css и js файлы) вообще не будет подгружаться с ошибкой ERR_CONNECTION_TIMED_OUT. Итоговое время загрузки страницы - долго до нескольких минут, причем получается она неполной из-за недогрузки части контента.

Прошу помочь.
 
1. а как в других броузерах работает?
2. логи сервера что говорят?
3. обращались ли к разработчику неведомого скрипта?
4. экстрасенсы в отпуске
5. хрустальный шар не помогает
6. проверить комп на вирусы
7. проверить файл hosts
 
Как вариант - в nginx некоректно настроены ограничения.
 
Попробую дать больше информации:
Вот скрин команды top:
e7455c32bf2582b3ee1fba4e82ae67e2.png

Говорит о том, что свободных ресурсов на сервере предостаточно (сайт на выделенном сервере).
-----------------
Далее, результаты проверки на сервисе webopulsar.ru
a259f49d79897a25f48ddd709b813a29.png

говорит о том, что время ожидания ответа сервера (Зависит от скорости выполнения серверной логики, запросов к базе данных.) - предпоследняя колонка находятся в допустимых пределах, следовательно проблема не на стороне PHP+MySQL - они генерируют контент очень быстро.

Проблема я так понимаю находится где-то в nginx. Пересмотрел его ещё раз, добавил сжатие gzip, скорость загрузки страниц немного выросла, однако проблему совсем не решило. Вот часть конфига, комментарии делал когда-то для себя.


Код:
user              nginx;
worker_processes  8;

# Уменьшает число системных вызовов gettimeofday(),
# что приводит к увеличению производительности
timer_resolution 100ms;

worker_rlimit_nofile 100000;

# Директива задаёт приоритет рабочих процессов от -20 до 20
# (отрицательное число означает более высокий приоритет).
# Тут будьте осторожны, так как другие сервисы могут начать заметно тормозить.
# На наших серверах этот параметрт установлен в -5.
# Чем меньше значение — тем выше приоритет для nginx
worker_priority -5;

error_log  /var/log/nginx/error.log;
#error_log  /var/log/nginx/error.log  notice;
#error_log  /var/log/nginx/error.log  info;

pid        /var/run/nginx.pid;


#----------------------------------------------------------------------
# Events Module
#
#   http://wiki.nginx.org/NginxHttpEventsModule
#
#----------------------------------------------------------------------

events {
    worker_connections  2048;
    use epoll;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    fastcgi_buffers 8 1024k;
    fastcgi_buffer_size 1024k;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for" "$gzip_ratio"';

    # access_log off;  # Отключаем логирование
    access_log  /var/log/nginx/access.log  main;



    charset utf-8; # Заставляем nginx принудительно отдавать в заголовках кодировку utf-8 для всех сайтов. ВАЖНО поставить, иначе гугл может индексить кракозяблы вместо русских букв

expires    240h;

# Задаёт максимально допустимый размер тела запроса клиента, указываемый в поле “Content-Length”
# заголовка запроса. Если размер больше заданного, то клиенту возвращается ошибка 413 (Request Entity Too Large).
# Следует иметь в виду, что браузеры не умеют корректно показывать эту ошибку. Установка аргумента размер в 0
# отключает проверку размера тела запроса клиента.
    client_max_body_size 32m;

# размер буфера для чтения тела запроса клиента. Если тело запроса больше заданного буфера,
# то всё тело запроса или только его часть записывается во временный файл. По умолчанию
# размер одного буфера равен двум размерам страницы. На x86, других 32-битных платформах и
# x86-64 это 8K. На других 64-битных платформах это обычно 16K.
    client_body_buffer_size    128k;


# Включить sendfile(). Использование sendfile() экономит
# системные вызовы, уменьшает число копирований данных,
# позволяет использовать меньше физической памяти.
    sendfile        on;
    tcp_nopush     on;
    tcp_nodelay     on;
    server_tokens   off;
gzip            on;
gzip_min_length 1000;
gzip_proxied    any;
gzip_types      *;



# При значении 0 конфиг максимально готов к ddos. тут механизм таков, что ddos на сервер может идти не путем запроса всех страниц и получение страницы,
# а просто отправкой пакетов на запрос и разрыв соединения. А при keepalive_timeout 65;  Nginx еще 65 секунд будет держать порт за пользователем.
# т.е. 100 посетителей в секунду и через 65 секунд кончатся все порты.
    keepalive_timeout 0; # не стоит держать соединение, если оно прервалось. клиент может и обновить страничку, а серверу приходится держать лишний порт.
#   keepalive_timeout  65; # Было такое значение раньше, во многих конфигах из нета стоит именно оно
 

limit_zone   myzone  $binary_remote_addr  10m;

 
# зная размер и примерное количество одновременно отдаваемых файлов, можно подобрать более подходящие значения
    output_buffers   4 64k; # настройка для одного клиента, т.е. ему одному 4 буфера по 64 килобайта

# если строка запроса или поле заголовка запроса не помещаются полностью в этот буфер, то выделяются буферы большего размера,
# задаваемые директивой large_client_header_buffers
client_header_buffer_size 8k; # размер буфера для чтения заголовка запроса клиента.

# максимальное число и размер буферов для чтения большого заголовка запроса клиента. Строка запроса не должна превышать размера
# одного буфера, иначе клиенту возвращается ошибка 414 (Request-URI Too Large). Поле заголовка запроса также не должно превышать
# размера одного буфера, иначе клиенту возвращается ошибка 400 (Bad Request).
large_client_header_buffers  4 16k;

proxy_temp_file_write_size 64k;

# Load config files from the /etc/nginx/conf.d directory
# The default server is in conf.d/default.conf
include /etc/nginx/conf.d/*.conf;


### Nginx permanent (301) redirect from www.domain.com to domain.com
server {
     listen MY_IP:80;
     server_name   ~^(www\.|ns1\.|ns2\.)(?<domain>.+)$;
     rewrite ^ $scheme://$domain$request_uri? permanent; #301 redirect
}

server {

listen MY_IP:80;

    server_name ~^(www\.)?(.+)$;

    location / {
        root   /home/domen.com/site;
        index  index.php index.html index.htm;
    }

    error_page  404              /404.html;
    location = /404.html {
        root   /home/domen.com/site/cssjs/404;
    }

    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

    location /nginx_status { # Получаем информацию по текущему состоянию nginx
        # Active connections — количество открытых соединений
        # server accepts handled requests — Сервер принял 96296 соединения, обработал 96296 соединения и обработал 170563 запроса (1.77 запросов/соединение)
        # Reading — количество запросов, заголовки которых nginx читает в данный момент
        # Writing — количество запросов, тело которых читает nginx + количество запросов для которых nginx отдает данные
        # Waiting — количетсво keep-alive соединений, расчитывается как: waiting = active — reading — writing
        stub_status on;
        access_log   off;
    }

    ######### 301 permanent redirect (i.e. from /faq.php to /faq/) #########

    # 301 redirect from /index.php to /
    if ( $request_uri ~ "^/index.(php|html?)" ) {
        rewrite ^ /$1 permanent;
    }

    location ~ \.php$ {
        root           /home/domen.com/site;
        try_files $uri =404;
        fastcgi_pass   unix:/tmp/php5-fpm.sock;
        fastcgi_index  index.php;
        fastcgi_read_timeout 3600; ## 1 час
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include /etc/nginx/fastcgi_params;
    }

    location ~ /\.ht {
        deny  all;
    }

    rewrite ^/en/?$ /?language_code=1&$args last;
    rewrite ^/ru/?$ /?language_code=2&$args last;

сервер Xeon E3-1220 Quad Core 3.1GHZ

На моем ПК вирусов нет, позавчера переустановил виндовс, предварительно отфарматировав диск С
 
что в логах по файлам 1.jpg sprite.png ??
 
В /var/log/nginx/error.log только ошибки вида
Код:
2015/09/27 15:50:25 [error] 1866#0: *4912 open() "/home/domen.com/images/gyuu.png" failed (2: No such file or directory), client: 185.26.180.153, server: ...
причём попробовал поискать в этом файле свой IP - не нашёл, хотя страницы рефрешил и сообщения об ошибках получал в браузере.

у меня были мысли, может с каналом на сервере что-то не так. Или у моего провайдера проблемы с доступом до голландии
Короче, вот сайт, Для просмотра ссылки Войди или Зарегистрируйся если интересно, в хроме жмете f12 - вкладка network и рефрешите, может проблема у меня только, хз
 
всё нормально загружается в разных броузерах. без ошибок.
Скрытое содержимое для пользователя(ей): verfaa


еще раз вопрос:
1. в других броузерах есть ошибки?

адблоки и прочие "радости" в броузере?
 
да, адблок стоял, т.к. писал функцию детекта этого плагина для сайта.
Неужели он и есть причина проблем с загрузкой сайта??
Он уже месяца полтора точно стоит, и все нормально было, а потом резко пошли проблемы.
В других браузерах визуально грузилось быстрее, особенно в IE.
В любом случае, сегодня у меня уже быстро грузится во всех браузерах.
Что сделал:
добавил сжатие gzip в nginx
убрал адблок
добавил в конфиг nginx expires 240h;
сжал картинки сервисом optimizilla.com
тяжелые css js оптимизировал в PageSpeed

Кстати, а насколько оправданно включать gzip в nginx?
Где-то читал что вреда (в виде повышенной нагрузки на процессор) больше чем пользы.
И какой уровень компрессии ставить оптимальнее всего?
 
добавил в конфиг nginx expires 240h;
Кстати, а насколько оправданно включать gzip в nginx?
Где-то читал что вреда (в виде повышенной нагрузки на процессор) больше чем пользы.
И какой уровень компрессии ставить оптимальнее всего?

Вместо expires 240h; можно писать expires 10d;. Есни не ошибаюсь, Гугл рекомендует 7d.

При степени сжатия 1, нагрузку на прочессор заметить можно только скурпулезными измерениям. Дальше просто ссылки:
Для просмотра ссылки Войди или Зарегистрируйся
Для просмотра ссылки Войди или Зарегистрируйся
Для просмотра ссылки Войди или Зарегистрируйся
Для просмотра ссылки Войди или Зарегистрируйся

---
Виктор
 
Назад
Сверху