Долго генерируется html страница

vip-moto, потому что шарид-хостинг - это полноценный мощный сервер. И если он не перегружен, то логично будет быстрее VDS, который использует лишь часть ресурсов сервера.

Ну все равно разница в 6 раз?😮

Это нормально. На шаред-хостинге скрипту доступны все вычислительные ресурсы сервера, но на короткое время (долго вам занимать вычислительные ресурсы не дадут). А на ВДС вам выделяется только часть ресурсов, но на продолжительное время. Плюс к тому шаринг-хостинг часто настроен более профессионально.

Но в конкретном случае надо смотреть, где узкое горлышко. Обычно тормозит файловая система, так что лучше выбирать ВДС на ssd дисках. Также многие хостинг-компании грешат оверселлингом.

Да суть, в том что раньше было все нормально, и вот не могу понять какие настройки наковырял, что такой результат дало. Может кто знает что копать

Наиболее вероятен затык в дисковой подсистеме. Это может быть из-за оверселлинга, или из-за того, что некоторые соседские ВДС-ы диск много юзают, например тяжелыми запросами к БД.

конфигурацию впс покажите. nginx стоит?

подключитесь по ssh сделайте скрин команды top... посмотрим не предположение соседнего оратора

Я вот прямо на днях затык ликвидировал. Обнаружил такую проблему: если одновременно на сайт налетают более 2000 посетителей, то сайт практически переставал отвечать. Команда TOP показала, что систему сильно грузит MySQL.

Детальный анализ запросов показал, что при формировании менюшек и ссылок "след.материал-пред.материал" SQL-запросы заставляли mysql формировать временную таблицу и производить сортировку в файловой системе. Причиной этого была сортировка в запросе "ORDER BY". Тогда я пробежался по коду и убрал сортировку в SQL-запросах, заменив ее на сортировку в массиве (после получения результата SQL-запроса). В результате нагрузка упала в 5-10 раз.

user apache;

worker_processes 2;



error_log  /var/log/nginx/error.log warn;

pid        /var/run/nginx.pid;



events {

  worker_connections 2048; # increase for busier servers

  use epoll; # you should use epoll here for Linux kernels 2.6.x

  multi_accept on;

}



timer_resolution 100ms;

worker_priority -5;

worker_rlimit_nofile 10096;



http {

    server_name_in_redirect off;

    server_names_hash_max_size 10240;

    server_names_hash_bucket_size 1024;

    include       /etc/nginx/mime.types;

    default_type  application/octet-stream;



    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '

                      '$status $body_bytes_sent "$http_referer" '

                      '"$http_user_agent" "$http_x_forwarded_for"';



    access_log off;

    

    server_tokens off;

    sendfile on;

    tcp_nopush on;

    tcp_nodelay on;



    # Timeout for keep-alive connections. Server will close connections after this time.

    keepalive_timeout 20;

    # Number of requests a client can make over the keep-alive connection.

    keepalive_requests 100000;



    gzip on;

    gzip_vary on;

    gzip_static	on;

    gzip_proxied     any; 

    gzip_disable "MSIE [1-6]\.";

    gzip_http_version 1.1;

    gzip_min_length 1000;

    gzip_comp_level  5;

    gzip_buffers  64 8k;

    # You can remove image/png image/x-icon image/gif image/jpeg if you have slow CPU

    gzip_types

    application/atom+xml

    application/javascript

    application/json

    application/rss+xml

    application/vnd.ms-fontobject

    application/x-font-ttf

    application/x-web-app-manifest+json

    application/xhtml+xml

    application/xml

    font/opentype

    image/svg+xml

    image/x-icon

    text/css

    text/plain

    text/x-component;



    ignore_invalid_headers on;



    send_timeout 5;

    reset_timedout_connection on;

    large_client_header_buffers 4 256k;

    client_body_timeout   3m;

    client_header_timeout 3m;

    client_header_buffer_size 3m;

    client_body_buffer_size  128k;

    client_body_in_file_only clean;

    output_buffers  1 1m;



    proxy_buffers 8 2m; 

    proxy_buffer_size 10m; 

    proxy_busy_buffers_size 10m;



    request_pool_size  32k;

    postpone_output  1460;



    # Caches information about open FDs, freqently accessed files.

    open_file_cache max=99000 inactive=60m;

    open_file_cache_valid 60m;

    open_file_cache_min_uses 2;

    open_file_cache_errors on;



    limit_conn_zone $binary_remote_addr zone=addr:10m;

    limit_req_zone $binary_remote_addr zone=one:10m  rate=10r/s;



    proxy_cache_path /var/cache/nginx/proxy_cache levels=1:2 keys_zone=hrportal:10m inactive=3d max_size=1024m;

    proxy_cache_key "$scheme$request_method$host$request_uri";

    proxy_cache_use_stale error timeout invalid_header http_500;

<IfModule worker.c>

StartServers       3

MaxClients         256

MinSpareThreads     15

MaxSpareThreads     35

ThreadsPerChild     64

MaxRequestsPerChild  4096

</IfModule>

Ну что, никто не подскажет в чем беда?

У вас главная страница, например, генерируется сравнительно быстро - около 0.1-0.15 секунд. Это в принципе допустимо. Другое дело, что там еще 6.8 Мб различного рода файлов и под 160 запросов. Только две png-картинки с постерами - это уже 3 Мб. Если сервер подключен по 100 Мбит/с каналу и он весь ваш, то только на передачу этого всего счастья уйдет около 1 секунды.