Наша команда активно использует nginx как самостоятельный веб-сервер. Мы с легкостью отказались от apache, и призываем к этому всех наших клиентов.

Для всех неравнодушных к хостингу Livestreet и производительности их сайтов публикуем конфиг для nginx:

root /home/{username}/domains/{parent_domain};

location / {
try_files $uri $uri/ /index.php?q=$uri&$args;
}

location ~* /templates/.*\.(tpl|php)$ {
deny all;
}

location /tmp {
deny all;
}

location ~ /\. {
deny all;
}

location ~ \.(tpl|xml|log|sql)$ {
deny all;
}

location ~*  \.(jpg|jpeg|png|gif|ico|css|js)$ {
expires 7d;
}

location ~ \.php$ {
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_intercept_errors on;
fastcgi_pass unix:/var/run/php5-{domain}.sock;
}

Для ваших PR всегда доступен репозиторий: github.com/elasticweb/nginx-configs

Добрый день, ребят! Моему сайту постепенно становилось все хуже и хуже… И вот… Сегодня я открываю главную страницу и ужасаюсь от скорости прогрузки сайта. Загрузка страницы — 28.9 сек., Полная прогрузка страницы с контентом на ней — 46.9 сек.

Вот информация с footer-а:


Шаблон сайта:
Atlass

Список плагинов:

aceAdminPanel: v.2.0.392 — Ok
Admvote: v.1.2
Attachments: v.1.4.1
@User: v.0.2.1
Audio records light version: v.1.3.1
AutoCut: v.0.0.4
AutoOpenID: v.2.1.1
Smiles: v.1.0
Blocktop: v.1.2.0
Тэги для блогов (Blog tags): v.1.0.4
Информирование пользователя об упоминании в тексте: v.1.0.0
Commentreport — сообщения о нарушениях в комментариях: v.1.0
Config Engine: v.1.3.0
Поздравления: v.1.1.0
Настройки приватности контактов: v.1.0.0
Cross linker: v.3.0.0
Delete Comment: v.1.0.0
Черновики: v.1.0.2
Dropbox: v.1.0.0
Edit comment: v.1.0.4
Expanded Poll: v.1.1.2
Fastls: v.1.0.0
Обратная связь: v.2.0.2
File Archive: v.1.0.3
Форум: v.1.0.3
Greeting new user: v.0.3.1
HideSpoiler: v.0.1
Last guests: v.1.0.3
LSSettings: v.0.1.0
Main preview topic: v.1.1
Mobile template: v.1.0
Native: v.1.2
Публикация от чужого имени: v.1.0.2
NiceURL: v.2.8
Static page: v.1.3.2
Payment: v.1.3.1
Popup info: v.1.3.1
Публикация топиков в группы: v.1.2.2
Quote Comment: v.1.0.1
Бонусный рейтинг: v.1.0.1
Read before comment: v.1.1.1
RusUrls: v.1.0
Search: v.0.1
Search Auto Completer: v.1.2.0
SEO: v.0.3.0
Seolib: v.1.6
История сессий: v.1.0
Sidebar rating: v.1.0
Похожие записи: v.0.3.0
Similar topics in popup: v.1.2.2
Sitemap: v.0.4.0
Sktc. Замена облака тегов: v.1.0.0
Skubs. Статистика активности в блогах: v.1.0.0
StickyTopics v2: v.2.0.1
Stop words: v.1.1.0
Topic info: v.1.0.4
Источник новости: v.1.1
TopicUp: v.0.2
UserTop: v.1.1.0
Viewcount: v.1.0.0

p.s. Звонил хостеру, он утверждает что с серваком все норм.

Так в чем тогда дело?
Прошу, помогите разобраться! Спасибо

Ребята, на одном из сайтов на выделенном сервере такие показатели внизу главной страницы:

MySql
query: 70
time: 0,013

Cache
query: 301
— set: 12
— get: 289
time: 0,00147

PHP
time load modules: 0,149
full time: 2,824

Memory
memory limit: 4096M
memory usage: 35.217 M
peak usage: 49.500 M

Подскажите кто разбирается это нормально или нужно что то оптимизировать? О чем вообще говорят эти цифры? Наверняка есть гуру кто знает что все это означает:)) Посещалка так себе — около 300 в сутки.

Здравствуйте!

Немного лирики.

Имеется сайт на WP с посещаемостью 35-40к хостов в сутки. В пиковые часы идет порядка 200 Mysql запросов в секунду, в такие часы сайт потребляет больше половины процессора. Сильно жрущих плагинов нет, WP оптимизирован, добавлено много своих хаков и модулей. Время генерации страниц — порядка 0.5-1 секунда. Установлен на сервере в связке с nginx + php-fastcgi + eaccelerator + memcached + mysql. Все более-менее настроено и работает :) В некоторые дни (праздники, каникулы) посещаемость вырастает раза в 1.5, в связи с чем проц начинает захлебываться, тогда я просто включаю плагин кэширования WP-super-cache, который раза в 3 уменьшает нагрузку на сайт. Постоянно держать включенным не хочется, ибо не работают некоторые плагины из-за него.

Есть желание поменять парадигму сайта, увеличив его социальность и вовлеченность пользователей в создание контента. Плагины к WP смотрел, все же это костыли. В результате склоняюсь к варианту переехать на движок LS, полностью переделав сайт. Смущает меня только отсутствие знания о производительности движка. В частности, интересует возможность полного кэширования страниц при резко возросшей посещаемости в короткие промежутки времени. Интересует задел для оптимизации — скажем, некий тюнинг руками кода, либо отказ/замена некоторых плагинов. Вообще, насколько гибок движок для оптимизации? Есть ли у кого-нибудь похожие числа по посещаемости, откликнитесь, пожалуйста.

Заранее спасибо!

Ища пути ускорения движка я постоянно спотыкаюсь об класс конфига (/engine/lib/internal/ConfigSimple/Config.class.php), а именно — меня беспокоит авто замена ключей в конфиге. Такой код мы можем найти в дистрибутиве:

static public function KeyReplace($cfg,$sInstance=self::DEFAULT_CONFIG_INSTANCE) {
  if(is_array($cfg)) {
    foreach($cfg as $k=>$v) {
      $k_replaced = self::KeyReplace($k, $sInstance);
      if($k==$k_replaced) {
        $cfg[$k] = self::KeyReplace($v,$sInstance);
      } else {
        $cfg[$k_replaced] = self::KeyReplace($v,$sInstance);
        unset($cfg[$k]);
      }
    }
  } else {
    if(preg_match('~___([\S|\.|]+)___~Ui',$cfg))
      $cfg = preg_replace_callback(
        '~___([\S|\.]+)___~Ui',
        create_function('$value','return Config::Get($value[1],"'.$sInstance.'");'),
        $cfg
      );
  }
  return $cfg;
}

Читать дальше →

Смысл этого топика не в том что бы изменить ход развития LiveStreet или отметить его недостатки — нет. LiveStreet была и будет системой ориентированной на широкие массы, поэтому требовать от нее большего я не в праве, но я могу изменять свои проекты, делать свои решения и предоставлять их на суд.

В данный момент мне бы хотелось поделится своими мыслями по поводу реализации части любимого движка работающей с данными и то как эту часть можно оптимизировать и привести к более производительному и логичному виду.

Всё это подается как новые темы к изучению для разработчиков проектов, которые возможно о них не знаю и как новая информация для пользователей, которые считаю что находятся на гребне технологий.

Redis(а может и Node.js)

Первое изменение которой я бы сделал в своем проекте — использовал Redis для хранения событий пользователей. Использование MySQL для таких вещей не самоубийсво, но все таки очень тормознутое решение нежели Redis, для которой шустрость второе имя. Ко всему прочему можно добавить возможность publish/subscribe, позволяющая в купе с node.js выводить уведомления такие же как в Вконтакте. Размышляя в этом направлении можно расширить границы использования этой БД. Для осуществления работы можно использовать библиотеку Rediska, разработанную с подачи нашего соотечественника.

Тем кто заинтересовался темой будет уютнее почитать подробности тут, чем читать обрывки вырезанных из текста абзацев — Redis.

MongoDB

Данных у нас много и все они хранятся в реляционной базе данных. Что если нам координально изменить парадигму хранения данных и использовать MongoDB. Выиграем мы и в скорости запросов и в скорости работы с данными продолжая использовать ORM, потому как в MongoDB оно организованно на уровне C++, а не эмулируются как сделанно в данный момент в LiveStreet. Но за это разработчикам стоит сказать отдельное спасибо, т.к это было действительно ценное решение ускоряющее разработку.

Подробности в виде презентации — Mongodb.

PS
Я просто показываю вам что вы можете сделать со своим LiveStreet и какой космос открыт перед вами :)

Если вы в этом шарите думаю все будут только рады перенять ваш опыт :)

Случилось так, что на одном из проектов full time стал переваливать за 1,5 сек и при этом сжирался весь проц. При этом все остальные показали были в норме: база — 0,002 сек, кеш — 0,01 сек.

Пришлось прикручивать профайлер и смотреть, в чем дело.

Виноват оказался Smarty, который из 1,5 секунд работал 1,2 (шаблон, на проекте, используется стандартный с легкими изменениями).

Копаясь дальше нашел самый сложный шаблон comments_tree.tpl, который выполняет в цикле инклюд шаблона comment.tpl.

Проблема решилась отказом от инклюда и переносом содержимого из comment.tpl в comments_tree.tpl.

full time на топиках с 400+ комментариев не превышает 0,4 сек.

Надеюсь кому-то поможет.

Кто-нибудь занималься плотной работой над производительностью LS?
На небольшой посещаемости отключение кэша делает сайт гораздо шустрее. Но дальше-то так не получится.
Может, кто-то экспериментировал со статическим кэшем? То бишь сохранением результата парсинга шаблона в файл, и потом загрузкой этого файла, если пользователь неавторизован?

В SVN обновил механизм пользовательских сессий. Теперь сессии хранятся в отдельной таблице и содержат данные о последней дате активности пользователя и его IP. Это позволит снять нагрузку с запроса на получения списка онлайн юзеров, который раньше приходилось делать ко всей таблице пользователей.
Также появилась новая фишка — теперь сессия авторизованного юзера обновляется в БД не при каждом запросе к сайту, а с интервалом в 10 минут. Т.е. каждый раз она сохраняется в кеше и каждые 10 минут сбрасывается в БД. Это позволит избавиться от большого числа UPDATE запрос при значительном онлайне пользователей, что должно сказаться на производительности, особенно у обладателей MyISAM, т.к. это engine полностью лочит таблицу при записи в неё.
Надеюсь на вашу помощь в тестирование этого нововведения :)

ЗЫ Забыл добавить, т.к. обновление в БД происходит минимум раз в 10 минут, то при отображении списка онлайн юзеров возможна погрешность в сортировке, которая составляет примерно 10 минут

Заметил некую закономерность, если долго (сутки) не заходить на сайт, то при при первом открытии сайта есть существенные подтормаживания. Возможно виной этому хостер (хт-системс)
Сайт пустой (0,3 версия постовлена)

MySql
query: 12
time: 0,41

Cache
query: 0
set: 0
get: 0
time: 0

PHP
time load modules:0,751
full time:2,126

Исходя из данных видим что MySql+PHP=0,41+0,751=1,161
НО
full time:2,126

FullTime-(MySql+PHP)= примерно 1 секунда. На что потрачена эта секунда? В статистике этого нет.

Сам имею довольно большой опыт работы с различными КМС, но не являюсь программером. За 2 года была разработана своя КМС (не соц.сеть), в которой на производительность системы было уделено огромное внимание.

Дело в том что когда на сайте появилось около 30тыс. страниц и около 2тыс посетителей в сутки, время загрузки страницы было около 30 секунд. Затем было пол года работ и уволен не один десяток программеров… В итоге получили на сайте с посещаемостью 15000 в сутки и 100000 страниц время загрузки около 0,4 сек

Зачем я это все пишу?
Причина:
Если время, за которое хостинг отдает страницу поисковой системе, более 4-х секунд то поисковый бот уходит с этой страницы и она будет не проиндексирована.

Пустой ЛС на тестовом домене (нет посетителей кроме меня) выдает время 2 секунды, то это не есть хорошо, к сожелению, и над этим нужно работать и работать…

Чтобы не быть голословным, привожу время работы своей старой КМС, на разработку которой было убито полтора года (статейный движек).

Рабочее время 0,347727 sec, 6 запросов к базе (0,021895 Сек), gzip OFF
На сайте около 50 тыс. страниц, 1000 уникальных посетителей в сутки. Работает наобычном хостинге (200руб. в месяц)

Итог:
Мне очень понравился ЛС, но пугают проблемы которые могут возникнуть в будущем… если проект развить и он будет отдавать страницы более чем за 4 секунды то поисковый трафик может сойти на нет… печальная перспектива.

Вопросы:
1. Время работы ЛС зависит от объема сайта?
2. Существуют большие сайты с серьезной посещаместью на движке ЛС на обычном хостинге? (т.е. не выделенный сервер)
3. На что тратится та секунда, которая приведена в моих расчетах выше