Комментарии 407
все по делу, надеюсь, благодарность вашего клиента не ограничилась суммой «большое спасибо».
ИНтересно почему вместе с 8 ядерным процессором(ми) было всего 2 гига оперативной памяти?
вообще этот сервак клиенту продала хостинговая компания, когда закрывалась. я на свой тоже бы столько не поставил. у многих коллокаторов такой объём — это один из стандартных вариантов.
Хостер специально предоставляет такие убогие конф-ции, чтобы можно было заработать на доп. услугах +2, +4, +8 Гб RAM
прогресс на лицо, молодец, поучительно!
но 2-3 секунды все-равно многовато!
согласен. но это днём, с учётом подгрузки в iframe. сейчас например меньше секунды.
какая кстати посещаемость портала, о каких нагузках речь?
До 60к просмотров в сутки.
Не так уж и много…

Сложилось ощущение что автор впервые задумался о настройке высоконагруженного проекта.
Именно автор.
Как уже заметили, «тонкой настройкой» в статье и не пахнет.
Одни предположения о принципах работы, необоснованные выводы.
Итог вообще убил…
результат есть. в оптимизации вообще почти всегда так. одна вещь даёт 80% эффекта. правило паретто
на самом деле 20% чего либо дают 80% результата, стало быть в 20% может попасть сколько угодно правильных вещей, все зависит от ОБЩЕГО количества. )
Скажем я бы еще десяток пунктов добавил к вашей оптимизации.
Эти пункты бы в общей сложности дали бы минимум 10% снижения нагрузки на диски.
Это без добавления ОЗУ.

Оптимизация занятие комплексное, если 80% прироста дает один пункт, то того кто изначально настраивал систему нужно исключить из естественного отбора админов, т.к. это откровенная ошибка.
Тому, кто изначально настраивал систему, такие нагрузки в ТЗ могли не даваться даже в виде теоретически возможных.
Ну так напишите топик, к чему пустые коммента «а я бы».

Было бы интересно почитать
> Через день подвезли память и после её установки сервер по настоящему вздохнул свободно — страницы стали загружаться за 2-3 секунды.

А потом пришёл лесник… Если процессы вистя на I/O, то сразу надо начинать с этой оптимизации, остальное не очень осмысленно оптимизировать, пока не устранена главная проблема. Единственный разумный момент из «тонких» настроек я увидел, это ограничение скорости одного потока, остальное можно было не трогать до добавления памяти, и смотреть уже после что же нужно оптимизировать дальше и нужно ли. Редиректы вполне имеют право на жизнь, вопрос, возможно, в содержании самих страниц, не содержат ли ссылки на картинки в своих URL имя сайта, при этом без www. Иначе, редирект должен происходить при первом обращении к странице, после этого весь сайт должен стать сразу «правильным», без лишних редиректов.
Если не делать редирект www.host -> host (или наоборот), то нужно вешать cookies на домен .host, иначе www.host и host будут работать с разными наборам cookies.
так можно поставить только с host, а вот попытка поставить с www.host куку на *.host фейлится.
Вот и тема для новой статьи.
Ко мне обратился владелец ресурса ****. Ряд пользователей его сайта жаловались, что их разлогинивает во время серфинга.

Я настроил хранение сессий в БД.
Изменил время жизни кук.
Задал красивое имя идентификатору сессий.

А потом админ сайта из больницы с мобильного добавил редирект.
следуя такой логике, я возьму и с site.com поставлю кук на несколько мб на .com) пусть клиент всем рассылает эти куки)
На .com нельзя поставить, т.к. куки ставятся только на домены с двумя компонентами.

Установка на example.com с www.example.com будет работать — у самого так делает сайт: одна авторизация на все субдомены.
С .com — это была ирония.
С www практика показывают, что некоторые браузеры ставят, а некоторые нет.
RFC 2109

Examples:
* A Set-Cookie from request-host y.x.foo.com for Domain=.foo.com
would be rejected, because H is y.x and contains a dot.
* A Set-Cookie from request-host x.foo.com for Domain=.foo.com would
be accepted.
* A Set-Cookie with Domain=.com or Domain=.com., will always be
rejected, because there is no embedded dot.
* A Set-Cookie with Domain=ajax.com will be rejected because the
value for Domain does not begin with a dot.


Установка кук для домена .domain.com с www.domain.com работает
На практике у некоторых клиентов не срабатывает почему-то :(
Почему — не смог разобраться, вернул обратно редиркт на www
впрочем, яндекс и гугл делают также
Можете объяснить, зачем вообще нужны эти www? Какой в них смысл? Практическая польза? Или может так сложилось исторически?
Как минимум нужны, если www (выдача html документов) не основная функция домена, а, например, лишь веб-морда или документация к ней.
Для некоторых людей www ассоциируется с интернетом, т.е. типа если есть www то это однозначно сайт.
Если реклама сайта дается по радио/телевизору/в печатных изданиях www в начале адреса помогает идентифицировать это как 100% сайт.
Но вообще все зависит от аудитории сайта.
Куки на .host доступны со всех поддоменов, а поэтому не всегда уместны. Например, когда на поддоменах работают какие-либо партнерские программы.
у меня есть партнёрские программы на других поддоменах на askfor.info. Просто дал имена кукам разные и проблема решена в зародыше)
Проблема в том, что недобросовестный партнер может воспользоваться куками твоего сайта. Что из этого может получиться зависит исключительно от фантазии злоумышленника.
если он сможет изменить куки, то только те, что лежат у него на компе. а это он сможет сделать в любом случае, к какому бы домену они не относились
Зачем менять, если ими можно воспользоваться? Стащить авторизационную куку, к примеру.
стащить куку он сможет только у самого себя — куки хранятся на стороне клиента
Я имею в виду недобросовестную партнерскую программу, которая скрыто занимается сбором данных ресурса верхнего уровня.
если мы, например, поставим партнёрские ссылки на что угодно, то они никак не смогут посмотреть куки на компьютере пользователя.

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

site.com и www.site.com — ваши сайты, на которых есть авторизация. Вы ставите куку на хост .site.com.
friends.site.com — сайт вашего партнера. Ему приходят куки авторизации ваших пользователей.

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

Одними из первых этой дырой в имидже воспользуются конкуренты.

И разбираться из ФСБ придут со мной.
у меня партнёры не имеют доступа к коду партнёрских программ
Разговор же не про вас, а про общий случай. В общем случае нужно подумать, прежде чем ставить куки на .site.com.
А между тем так делать не хорошо. Если вы не видите и не знаете — не надо трогать, надо разобраться. Для помощи перетащили бы эти редиректы в конфиг nginx и успокоились. Потом Иван Усачев придет к оптимизатору и спросит, почему поисковые системы считают сайт с www и без двумя разными сайтами. А откуда оптимизатору знать, что админ не видит в этих редиректах смысла.
Или часть рекламы не оплачивается.

Всё правильно чувак сделал. Оптимизатору тоже будет теперь чем заняться.
поисковики очень хорошо разбираются в идеентичности сайтов без всяких редиректов
Это не ваша зона ответственности и ваши догадки.
help.yandex.ru/metrika/?id=1036894#1053660
Ключевая фраза:
Чтобы правильно настроить web-сайт, рекомендуем обратиться к вашему системному администратору или самостоятельно отредактировать файл .htaccess на вашем web-сервере.
о пользе контекста:

перед этим идёт:

Почему объединяется статистика по доменам с www и без www?

Наши исследования показали, что некоторые владельцы не могут правильно настроить свой web-сайт, и в интернете их сайт представлен как www.domain.ru, так и domain.ru. Случаи, когда это делается владельцами сайтов умышленно, крайне редки, поэтому мы решили объединять статистику по таким доменам.


Т.е. c практической точки зрения, а именно с точки зрения ТиЦ, PR и метрики домен с www и без него (если контент одинаков) — одно и тоже.

А то, что касается «правильности» с точки зрения яндекса — это вещь чисто теоретическая и не относящаяся и никак не влияющая на реальность.

В принципе одна переадресация сайт почти не замедлит, но в моём случае их было несколько (ещё на картинках с полными путями — я сайт не разрабатывал!), поэтому это был разумный шаг.
как тогда объянить то, что pr у моих сайтов (без редиректов) с www и без него одинаковый?

www.askfor.info
www.inetstar.ru/
www.moneyorder.ru/

Приведите контпример хоть одного сайта неиспользующего редиректы, имеющего одинаковый контент и имеющий разный pr у версии с www и без него.
Google/Yandex склеивают домен с www и без если по обоим адресам одинаковый контент. Это происходит не сразу, а по прошествии некоторого времени после попадания сайт в базу поисковика.
Кстати, если бы редиректы раздавал Nginx то это не дало бы почти никакой нагрузки, но там Nginx обращался к апачу, апач уже на основе htaccess возвращал редирект, что на порядок медленнее и нагружает бэкенд
Скорость потока ограничили скорость потока ограничили…

Следите за руками. Контент у нас все ещё отдаёт апач. Так я высасываю ролик за 10 секунд, а с ограничением скорости почти две минуты.

То есть многомеговый воркер апача работает на меня много дольше, чем мог бы.

С какого момента это становится оптимизацией?
воркер отрабатывает быстро, нгинкс быстро всасывает, а вот отдаёт медленно. воркеров апача там 50 штук.
воркеров апача там 50 штук.
Вам нужно застрелиться, срочно. 50 воркеров с нагрузкой 1,7 запросов в секунду. Мама дорогая.
так это, картинки же ресайзятся налету, вот они то и воркеры нагибают
Кстати, скорее всего Nginx считает с апача весь видеофайл так быстро как сможет и положет во временный файл на диске (если в памяти в буфере не поместится).
А потом уже из этого временного файла/буфера будет медленно отдавать см sysoev.ru/nginx/docs/http/ngx_http_proxy_module.html#proxy_buffering
nginx не пытается считать весь ответ проксируемого сервера, максимальный размер данных, который nginx может принять от сервера задаётся директивой proxy_buffer_size.

Самый конец того параграфа.

Я 5 лет проксирование не делал и могу ошибаться, но вроде стало хуже по вышеозвученным причинам.
Самое начало того параграфа: «Если буферизация выключена, дальше ваш текст». По-умолчанию она включена.
Но, в любом случае, тот факт, что Nginx считывает видеоролик у апача и записывает его во временный файл, уже практически удваивает нагрузку на диск (ну, минус файловый кеш и прочие мелочи)
Ну щас я буду мазаться, что теперь возросли шансы того, что памяти для файлокэша не хватит с некоторого момента.
всё зависит от величины этого буфера. срелний размер ролика 1,5-2 мб.
При 50 клиентах это всего лишь 100 мегабайт. Даже если всё загнать в буфера. У меня бууфер достаточен, чтобы вместить ролик
Но в вашей статье о размере буфера прокси нет ни слова!

Опять же не уверен, т.к. не C-программист, но вроде при большом размере буфера Nginx для ЛЮБОГО ответа от бэкенда будет резервировать оперативку такого размера. Может это и не так существенно, но все равно оверхед.
нет. данную директиву нужно указывать только для location, которое совпадает с тяжёлыми файлами.
у меня в проекте был форум с поиском через лайк-два процента.
сервер ужасно тормозил… решили докупить оперативки
после подвоза оперативки с 4 до 16 сервер вздохнул свободно.
но только на два дня. Через два дня — снова стал безбожно тормозить.

С переписыванием этой части функционала и переходом на сфинкс — показание аптайма с 25 упало до 3-5.
Вообще под uptime обычно понимается число дней, которые сервер работал без перезагрузки.
Вы имели ввиду load average?
я думаю можно ещё поработать над load average. у очевидца сейчас 0.09, 0.23, 0.29

Сколько ядер у сервака?
Читал и надеялся, что Вы своими руками все же спасете сервер, а спасла память в итоге :)
НЛО прилетело и опубликовало эту надпись здесь
Спасибо, очень познавательно, нельзя ли пояснить вот эту фразу:

В добавок как я узнал из вывода команды free из 8 гб кеша использовалось 300 мб, что само по себе очень плохой знак.

Т.е. на сервере 8 гиг свободной памяти отдано под кэш? и Вы еще доставляете 8? o_O и как определить сколько из кэша используется?
хм своп это своп, вот например:

Mem: 4046.227M total, 3867.219M used, 179.008M free, 61.445M buffers
Swap: 4000.551M total, 188.000k used, 4000.367M free, 2133.922M cached

на сервер 4Gb Оперативки + 4Gb свопа, из которых 2Gb RAM знаято приложениями, 4Gb свопа не используются и 2Gb отдано под кэш…

как узнать сколько из этих 2Gb используется? o_O я думал все 2Gb и используются…
Я имел ввиду, что автор, похоже, назвал своп кешем:
>В добавок как я узнал из вывода команды free из 8 гб кеша использовалось 300 мб, что само по себе очень плохой знак. Запись и подгрузка страниц из свопа может конкретно убивать производительность.
нужно использовать команду не free, а cat /proc/meminfo, и смотреть — inactive — кэш.
а… вижу своп с кешем перепутали, тогда беру слова обратно — своп так можно смотреть :) но free всеравно не информативная, т.к. ничего по сути не показывает.
proxy_pass подразумевает обращение к бекенду, а смысл в этом в случае раздачи статики?
location ~* ^/.+\.flv$ { flv; } — и nginx стримит flv без обращения к апачу…
Все верно, сразу палево заметил, когда какой-то .htaccess начал влиять на первычный nginx для статик файлов.
я не мог сделать все настройки сразу. изначально сервер был настроен под нескольких клиентов. если поручить в такой конфигурации раздавать nginx всю статику всех клиентов, то мы имеем дыру в безопасности.

если заказчик оплатит, то я перенастрою nginx как надо, т.к. остальные клиенты уже уехали с сервера
ну на отдельный айпишник домен и nginx повесить…
хотя если трафик приличный — может все же имеет смысл отдельный сервер под проект выделить? )
Ну зачем всю и сразу?.. Можно самое грузящее передать в первую очередь:
location ~* ^/(content|static)/.+\.(jpg|gif|png)$ { }
location ~* ^/video/.+\.(flv)$ { flv; }

(ну а если сайт не сильно мудреный, так и до «всей статики» недалеко)

Да и причем тут остальные клиенты? location ведь используется в контексте server {}.
то nginx ругается:
[emerg]: «proxy_pass» may not have URI part in location given by regular expression, or inside named location, or inside the «if» statement, or inside the «limit_except» block
По тексту статьи не видно было, что оптимизация nginx была из первых 3х статей найденных в гугле? Чего пристал к человеку?

Ему еще ошибки править и на очередной хайлоэд конференции выступать.
спасибо. нашёл как обойти эту ошибку или фичу nginx
нужно было убрать слэш в конце proxy_pass
Вообще не нужно многомегабайтные файлы гонять через апачь (читай, через диск). proxy_pass в локейшене ^/video/.+\.(flv)$ не нужен.
согласен. я об этом написал уже. это предстоит ещё настроить
>Я записал себе в список дел настроить nginx раздавать статику напрямую. В этом посте я касаться этого не буду.
обычно это делается в первую очередь и именно для этого ставится фронтенд в виде nginx
не всегда для этого. если это хостинговый сервер (много клиентов), то нгикс ставится, чтобы разгрузить апач
не всегда для этого… то нгикс ставится, чтобы разгрузить апач


а где здесь противоречие с
обычно это делается в первую очередь и именно для этого ставится фронтенд в виде nginx

?
противоречие возникает, если не выкидывать кусок моей фразы «если это хостинговый сервер (много клиентов), ».

Если вы сделаете у всех пользовательских файлов права 666, то пользователи смогут подглядывать друг у друга, например, пароли к базам в php-скриптах.

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

Т.е. при одном просмотре одной странице со списком из 10 превьюшек, сервак считывал 10 больших картинок и конвертировал их на лету? Это не могло породить большее кол-во чтений чем скачивание видео? Если не больше, то порядок, наверное, тот же. Странно ещё, что проц не был загружен.
Встречал такую проблему. Когда большее количество первый затык возникает в количестве воркеров апача. Во-первых такие превьюшки налетают на апач, забивают доступные воркеры и простаивают ожидая загрузки (удаленной или локальной) и конвертации. Клиенты которые пытаются загрузить страницу при этом ждут освобождения… Если воркеры апача не лимитировать, то их количество дико распухает, а ведь это тоже жрет память и процессорное время.
в принципе apache + php их генерит быстрее, чем nginx раздаёт, если у сервака много оперативки, но если мало — то своп всёё рушит.

но в данном случае динамическая генерация неопраданна
это каким таким хитрым способом? упрощенно…
nginx:
1) запрос картинки
2) отдача клиенту

nginx+apache+php:
1) запрос картинки
2) проброс на апач
3) чтение картинки
4) конвертирование на лету
5) отдача нгинксу
6) отдача клиенту
я имел ввиду следущее:
генерация картинки — 0.05 секунды, передача нгинксу — 0.001 секунды, скачивание клиентом картинки — 0.7 секунды
Только перед «генерация картинки 0.05 сек» Вы забыли написать «Чтение большой картинки, которая возможно весит 500кб — 1мб».
И это надо сделать 10 раз для одного отображения одного списка.

Я не сисадмин, а php-прогер и для меня это выглядит мега ужасно. Гораздо ужаснее, чем все остальные (не понятные мне пляски с бубном) вокруг iotop. Может быть именно это чтение больших картинок и создавала основную нагрузку на чтение?
нет, не основную. но какую-то существенную безусловно.
после установки памяти (и тюнингов) всё залетало. с картинками я уже после памяти разобрался. удивительно, но для мощного сервера динамическая генерация превью не та проблема, что ложит на лопатки
Почему Вы уверены, что не основную? Вы в top видели «тяжелые» раздачи видео, потому что они долгие. Вы могли там не видеть процессов апача, которые ждали отработки скриптов генерации превью, потому что они достаточно быстрые для top, но их реально могло быть очень много.
Веб-разработчику руки бы поотрывать за такое.
Расскажите штангисту, который берет рекордный вес, что лишний килограмм — это фигня, раз он 150 поднимает.

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

В любом случае, превью должно генерироваться только один раз. И не при показе клиенту, а при загрузке ролика/большой картинки.
НЛО прилетело и опубликовало эту надпись здесь
на самом деле в идеале лучше сносить апач совсем, а реврайты переписать в конфиг nginx-а.
Ну и соответственно php-fpm использовать.
По опыту что обычно делаем для сайтов с отдачей видео (по типу тубов) (допустим что там еще есть немного статики по объему (которая кроме видео) и скриптов и mysql с нагрузкой):
— ОС + mysql + скрипты и статика (короче все кроме видео) ставим на SSD диск (можно MLC интеловский, они не дорогие и достаточно надежные)
— под видео из SATA дисков сооружаем striped RAID (использую ZFS под FreeBSD обычно), ну грубо на гигабит трафика где-то штук 7 дисков SATA2 современных для комфортной отдачи с запасом, и сюда как раз вписывается 8-портовый контроллер Adaptec.
— в очень больших обемах памяти потребности здесь обычно нет, все видео все равно не закэшировать ) а мелкие файлы с SSD и так бысто читаются. 4 гига в принципе вполне достаточно.
— естественно, чистый nginx с php-fpm без всяких апачей.
если есть возможность кстати эффективнее будет не объединять диски в рейд, а равномерно распихать видеофайлы по ним
по моему эффект будет аналогичным аппаратному рейду за минусом надёжности
видеофайлы большие и последовательным чтением считываются долго, грубо говоря…
в случае RAID0 головки дисков будут синхронно дергаться по запрашиваемым файлам (скажем, одновременно читается 32 файла с 8 дисков в RAID0 — на всех дисках головки бегают по 32 файлам)…
в случае если раскидать эти файлы по дискам — на каждом диске головки дергаться будут только по 4 файлам, что естественно скажется в лучшую сторону на производительности.
Как-то так )
На самом деле размер блока в рейде настраивается. Если поставить его, скажем, 8мб — то на одно видео будет в среднем полтора-два чтения. Три — очень редко.
Головки синхронно не двигаются при чтении ни в RAID0, ни в RAID1.
В ZFS размер блока динамический, так что это как раз должно помочь
MySQL на SSD? хмм… Хотя если только запись и чтение, без регулярных UPDATE и DELETE…
SLC любых производителей и интеловские MLC не мрут )
Дешевые MLC разных производителей — да, быстро так убиваются.
mod_php у apache обрабатывает скрипты на порядок лучше и временами быстрее чем php-fpm, так что это очень спорное утверждение что чистый nginx+php-fpm окажется лучше. Оно так же может быть и узким местом.
Что значит «на порядок лучше»? Может я поспешил с переходом на nginx…
Не поспешили. И nginx при правильной настройке работает прекрасно.

Просто меня добивает что люди упорно считают что всякие fcgi и прочие быстрее старого доброго mod_php.
Скрипты работать быстрее не стали (медленнее вроде тоже), но стали меньше памяти есть и, как следствие, сервер выдерживает бОльшую нагрузку.
Ок. Для сравнения на моей VDS'ке: nginx+php-fpm съедали овер 450МБ, nginx+apache+mod_php — ещё не поднималось выше 300Мб. Я не спорю, может я как-то не так готовлю php-fpm, но мне хватило того, что он периодически из-за своих глюков дропал сессии, что на скорости ну никак положительно не отражалось.
У меня цифры практически противоположные, и это при чистом apache+mod_php (без nginx). Но я вообще ничего не готовлю, настройки дефолтные :)
В этом и дело. К тому же никто не говорит про дефолтные настройки ;)
В чём? :) А, вообще, я не админ, но вот приходится совмещать с тех пор как shared хостинга стало мало, а на managed (V)DS, а, тем более, штатного квалифицированного админа ещё не заработали. Играю настройками без особого понимания, что они дают :(
В настройках дефолтных ;)

Все настройки довольно неплохо расписаны в гугле ;) На русском языке в том числе видел пару статей. Думаю, если захотите разобраться — найдёте :)
Расписаны-то они расписаны, но вот понимания как они повлияют на потребление ресурсов (cpu/mem) нет, приходится экспериментировать на живую в режиме «что-то поменяли, недельку отработало, посмотрели как»
Собственно по другому и никак. Надо на своей шкуре сначала опробовать…
если nginx+php-fpm это такая панацея при больших нагрузках почему же тогда многие крупные проекты все-равно используют апач в качестве веб-сервера?
не знаю ) многих клиентов переводили с апача на такую связку — всегда только улучшение наблюдалось.
неудобство только в переписывании правил из .htaccess в nginx
Многие готовые продукты заточены под Apache, в частности для них есть примеры конфигов и файлы .htaccess (последние к тому же позволяют производить конфигурацию, включая конфигурацию php на лету, без перезагрузки сервера). А вот конфигов для nginx в поставке обычно не бывает, а те что гуглятся далеко не всегда идеальны, да и вообще рабочие.
ZFS сам по себе память весьма любит, а вы ещё и MySQL с www-серверов громоздите в 4Гб?!
вполне хватает на несколько сотен мегабит трафика )
От размера mysql баз конечно тоже зависит. Хотя конкретно по этим примерам — базы полностью в память не влезают насколько я помню… поэтому обычные диски mysql забивает операциями чтения, а с SSD все отлично
Будем знать про .htaccess, не знал что он может как то тормозить сервер


Когда давным давно делал тесты (тупо с помощью ab) мне не удалось заметить разницу (была в рамках погрешности). Разумеется влияние есть, но это уже стоить делать когда всё остальное пофиксено, а при времени генерации в 2-3 секунды, там еще пилить и пилить автору.

Кстати, если уж там мускул стоит, то не помешало-бы slow log начать писать и explain поделать, ну а всю остальное уже в комментариях озвучили.
этот момент я забыл описать. но стоит ли говорить об оптимизации долгих SQL запросов?
Да нет, пожалуй не стоит, как бы там других дело у вас должно быть полно, если комментарии к статье все прочитали :)
Все дело в их количестве, вложенности папок, сложности конфигурации в .htaccess и т.п.
Чем более глубоко запрятан файлик по папочкам — тем больше тормозит, ибо при AllowOverride All апач перечитывает ВСЕ файлы .htaccess по указаному пути.
Хех. Что ли о своих баталиях написать пост?) Со среднего времени генерации страницы в 3000-4000мс снизил чисто оптимизациями (без докупки железа) до 120-200мс и то 110мс отьедает запрос к стороннему геосервису. Список тэгов: постоянная инвалидация данных, геотаргетинг и временной таргетинг данных, 1 сервер, 500к показов в сутки.
Очень интересно, так как есть несколько проектов, которые работают именно на отдачу контента и достаточно сильно нагружают сервер, готов поделиться решениями, которые были нами найдены и увидеть Ваши, я думаю всем будет это полезно.
напишите в личку координаты. поразмыслим что и как)
Но в моём случае это не прошло. Дело в том, что на сервере Ивана nginx выполняет роль легковесного фронтенда, а все файлы и запросы всё равно идут через apache.

Я записал себе в список дел настроить nginx раздавать статику напрямую. В этом посте я касаться этого не буду.Я даже не могу выразить всю бурю чувств, которые испытал, когда прочитал ЭТО. Бля, nginx берет видео от апача, кладет его на диск и меддленно отдает клиенту, а вы докупаете память. Вы феерический долбаеб. А еще отзовы «полезная статья, все по делу». Вы хоть iotop запускали, чтобы посмотреть кто что читает, а кто пишет с диска? Кто вас пустил «оптимизировать» сервер и кто те люди, кто это делал до вас?
айрони
Ну забил человек гвозди микроскопом, ну с кем не бывало.
/айрони

p.s. интересно, а статья «Как я исправил свои ошибки» у топикстартера будет или нет?
знает. только для iotop нужны специальные фишки в ядре подключать. перекомпилированное ядро уже загрузилось с ними, но уже стало всё ок
НЛО прилетело и опубликовало эту надпись здесь
оскорблять не зная подробностей о ситуации — глупо.

в данном случае мне нужно было за ограниченный бюджет(=краткое время) настроить сервер.

перенастройка всего сервера с nginx + apache + mod_php в nginx + php не уложилась бы в бюджет

что такое iotop я знаю. видимо нужно было дописать об этом в статью.

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

перенастройка всего сервера с nginx + apache + mod_php в nginx + php не уложилась бы в бюджет
Вы феерический долбоеб в квадрате. Одна строчка конфига не уложилась бы в бюджет.
приведите мне одну строчку конфига, которая переведёт весь сервак с nginx + apache + mod_php на nginx + php и я признаю вашу правоту.

а иначе вы феерический дебил в кубе)
Я думаю, речь шла о том, что
Я записал себе в список дел настроить nginx раздавать статику напрямую.


говорит о несколько невысоком уровне квалификации, потому-что от главной проблемы тысячелетия (отдача килобайтной цсс несколькомегабайтным процессом апача) не избавились в первую очередь.
1 кб пофиг, он как раз в proxy_buffer_size влезет. Когда многие мегабайты через диск гоняют — это страшно.
Вам говорят о прямой раздаче видеофайлов через nginx, минуя апач. Это действительно стоило бы сделать в самую первую очередь, сэкономили бы процентов 80-90 памяти только этим.
я прекрасно понимаю что мне говорят. только это не одна строчка конфига.

а я бесплатно на заказчиков не работаю. это был обычный заказ на настройку с ограниченным временем и бюджетом.
Полчаса. Посмотреть на это и сказать: ещё оперативы.
В 200 рублей за консультацию уложились. Результат аналогичный.
Остальное за нормальные деньги и адекватные сроки.
за 200 рублей уважающий себя специалист даже смотреть не будет. а неуважающему себя сервер не доверят
Извините, я с замкадья. У нас 400 рублей в час — нормальная ставка.

Сколько у вас стоит полчаса работы специалиста по тонкой настройке сервера?

Это как раз то время, которое должно было у вас уйти перед согласованием бюджета. Посмотреть, что да как. И раз вы так себя уважаете, а предлагаемый бюджет мал, то: 200 рублей и расходитесь.
Знаете… у нас 725 рублей в час — ставка работы наших админов на хостинге… ну в смысле, если клиент просит что то хитрое на своём сервере.

Я сейчас читаю автора и сам офигеваю хД В Москве работаю на одном из самых деньгокушательных хостингов (М9 и всё такое).
сурово у вас, в нашем чудесном городе Красноярске 500 рублей это час работы эникейщика (настроить adsl модем например). А знаете почему для вас 400 рублей это нормально? потому, что вы не цените свой же труд. За 400 рублей я сложнее чем adsl модем точно настраивать ничего не буду, а вы же даже 50 рублей настроить open vpn сервер.

p.s.
отдача статики это 1 строчка (3 строчки в случае если скобочки выносить на отдельные строчки) без тонкой настройки, или ~5 с подгонкой).
Я рад за красноярских эникейщиков, зарабатывающих по 80 000 рублей в месяц.

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

Или фишка в том, что больше двух модемов в день не настроишь, за каждый вызов по 400 рублей, а оставшееся время в дороге?
расскажи мне об этом больше. В день они могут настроить около 5 модемов если на автобусе, и ~10 на машине. Итог: 2500-5000 в день при полной занятости. Средняя статистика заказов — 80 в месяц. Итого 3х эникейщиков достаточно, что бы все заказы выполнялись в течении 24 часов после поступления зявки.

> Мне страшно представить, сколько стою я в Красноярске.

Нисколько ты не стоишь. Ты же ничего не умеешь и не ценишь свой себя.
>Месяц поработал и год в Таиланде отдыхаешь.

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

Удачи в настройке.

Попробуйте модемы уже настроенными привозить. Тогда хватит одного водителя и одного эникейщика.
Внезпно! Я не занимаюсь настройкой модемов. А живу в Калифорнии и работаю тоже где хочу и когда хочу.

>Попробуйте модемы уже настроенными привозить. Тогда хватит одного водителя и одного эникейщика.

Не получится, эникейщик не знает данных до прибытия на место. А модем уже у клиента в 70% случаев.

>при этом занимаясь более интересными делами

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

Вы знаете стоимость часа работы проститутки? Знаете. Значит вы проститутка?
>Вы знаете стоимость часа работы проститутки? Знаете. Значит вы проститутка?

Нет, но вероятно пользуетесь их услугами.

>Внезапно! Я не писал нигде чем занимаюсь и цену своего часа. Так что ваши выводы как минимум забавны.

Я предположил.
Ну я не знаю во сколько вы там оцениваете такую работу. Может и целой жизни не хватит статику на nginx перевести;) Зачем же статья на хабре о том, как вы сделали тривиальную операцию неверным образом?
Кстати, в вашем случае действительно одна строка — видео раздается без антилича. Вам ее ниже привели.
Зачем мне так отвечать? Я ж не заказчик, которого вы на деньги разводите;)
У вас видеофайы без права на чтение, но при этом доступные напрямую по http?
их читает апач запущенный из-под пользователя владельца сайта. а нгикс из под nobody проксирует и отдаёт файлы
А как влияет на безопасность 644 права на flv, js, css, jpg, gif ну это вот первый вопрос который мне пришел в голову?
при избирательной установке прав на ролики — никак. в итоге я так и сделал
На мой вопрос вы из соображений безопасности не отвечаете?=)

Если у вас файлы доступны напрямую по http, то смысла убирать для них права на чтение любым пользователем нет потому, что любой пользователь их и так сможет прочитать по http. А значит можно сделать файлы доступными для чтения всем и запускать nginx из под любого пользователя и та одна строчка будет себе хорошо работать.
на этот вопрос я ответил в другом комменте. кратко: если есть несколько пользователей и мы включим их в одну группу, то они начнут видеть все файлы друг друга
Так пользователей трогать вообще не надо. Почему бы не поставить просто файлам права на чтение всем, если их и так могут прочитать все?
это касается только статики. пользователей хостинга трудно заставить ставить права избирательно.

в итоге оказалось, что прогер на статику ставит 644 и я подключил nginx как нужно (nobody nogroup) к этой папке
Вы же понимаете, что человек который это посоветовал не за бесплатно работает. Или верните как было или переводите ему часть заработка.
rwxr--r-- на папку с видео и на сами ролики вполне достаточно. Владельцем файла при этом может быть любой пользователь.
сейчас выяснится, что автор не знал различий флага x для файлов и директорий)
приведите мне одну строчку конфига, которая переведёт весь сервак с nginx + apache + mod_php на nginx + php
Я что, сказал, что нужно все переводить на nginx + php? Вы еще и читать не умеете. Просто не нужно огромную статику гонять через жесткий диск. Это одна строчка:

location /video/ { root /home/feericheskiy-debil/www; }
вы ответили фразой про одну строчку конфига на мою фразу о перенастройке всего сервера.

если я дам nginx права на доступ к файлам в одной папке (изначально он работает из под nobody nogroup), а это значит мне или нужно давать права на файлы пользователю nobody или группе nogroup, что некошерно.

Или запускать nginx из под другого пользователя или группы, у которой есть права на пользовательскую папку.

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

При всём при этом есть ещё пара других пользователей, поэтому лучше решать проблему поэтапно, не размашивая шашкой…

Это совсем не 5 минут и не одна строчка конфига. Всё не так просто…
Не беспокойтесь, и так ясно как божий день, что вы обосрались.
А вот тут вы не правы, благодаря автору, я в шесть утра по новосибирскому времени еще не сплю :-) а беседую с умными людьми.
И я с Новосиба.
Спасибо, что вы с homm есть. Это тот самый случай, когда комменты полезнее топика.
я решил задачу, а вы тратите своё время на повышение самооценки за счёт обсирания других. гениально!
Боюсь к обеду по Маскве, это будет как в истории с bolgenos: Простите. Я сделал это ради лулзов.
Проблему вы не решили. Вам выше дали дельные советы как стоит делать.
Esc, homm, alfa… читайте их камменты и делайте выводы.
сервер работает быстро. проблема решена. будут деньги — донастрою всё остальное
Деньги, что платили другие пользователи сервера (которых не стало), тоже вернулись после проведенных работ?
пользователь unix это совсем не означает реальное физическое лицо
Ну да.
Насмотрятся ещё всякие демоны видях и восстание затеют.

Закрою-ка я тоже на своих серваках доступ им к развлекаьельному контенту.
если хоть один из таких демонов взломают, то можно испортить всю систему. я осторожно отношусь к потенциальным дырам
Злобные хацкеры не смогут смотреть видео прямо с сервера. Жестоко! После этого, как я понимаю, они помрут со смеху и в этом ваш коварный план.
С целью оживить беседу.

А не спать в 6:41 это сегодня фишка такая по Новосибирску? А то я грешил на то, что кофе с коньяком зря набодяжил, а может это в воздухе чего витает.
Да блин, это же уже даже не смешно! Ну признайтесь уже в своих ошибках или там недостатке знаний, никто-же не осудит. А то настоящий сенсей не должен так себя вести.

И да, хидеры картинок проще смотреть не на веб-сервисах а-ля be1.ru/stat/, а с помощью curl -I
это не ошибки, а недоделки.

статью я уже изменил, главному злодею отписался и поработал бесплатно над серваком. теперь всё как нужно
И жмот ваш Усачов.
Я тут вижу троих, кто за два дня гарантированно бы настроил всё, как нужно а не ноготки у воробьев подстригал.

Сколько стоит два дня работ… Ну 7 000 рублей.

Вроде и времени было у вас до появления оперативки столько-же.

Пожопить 7 000 рублей, когда у тебя страницы по 5 минут грузятся…

Да он на кликах по рекламе больше потерял.
Вы смешной, два дня работы специалиста 7000…
Русоникс за своих админов просит 3000 рублей в час.
У админов как и у проституток есть разные виды, есть индивидуалки, вокзальные, а есть эскорт :-)
Будут деньги — купите еще оперативы? Даю совет для феерического дебила — добить оперативки до 32Гб и засунуть в нее и кеш и своп. Оптимизация — это не для уважающих себя специалистов.
понятно почему у вас карма -50.
видимо за ценные комментарии
Чесно говоря, мне пофиг, что вы решили. Я разное повидал за время общения с собственными серверами организаций, которые решили что им недостаточно обычного хостинга или vds. Видел и 20 сайтов, конектящихся к мускулю под рутом, на котором нет пароля. И 10-и гигабайтный access лог без ротации со всей статикой, когда паралельно админ мне говорил, что у него место на серваке заканчивается. Что самое интересное, это все настраивали специалисты с полной ставкой, которые уважают себя и «за 200 рублей даже смотреть не будет».

Но когда вы, голубчик, лезете рассказвать о том, какой вы Д`Артаньян, как вы все круто настроили за «ограниченный бюджет», прикупив тонну дорогущего жлеза — извольте принять ушат говна на голову.
2 планки памяти — это не тонна.
И я и не говорю, что я д.Артаньян.
Я поделился опытом, а вы вместо конструктивной критики начали гавно разводить.

Я извлёк и из этого плюс. Хоть мне и не платили за дальнейшую настройку сервера я проверил все права, убедился что всё ок, и заставил nginx отдавать статику напрямую. изменения внесены в статью
а вот это возмутительно.
вы вносите правки в статью, не отмечая что это правки. в итоге, контент изменился, благодаря комментаторам, статья не выглядит такой провальной, авторы комментариев, которые оказали вам большую помощь, никак не отмечены.

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

цель статьи — дать информацию другим. хорошую.

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

з.ы. тут уже за 200 камментов. как думаете, много ли народу прочитает больше пары десятков камментов в начале?
Вы, кстати, не правильно написали в топике, нужно было пользоваться копи-пастом.

location /video/ {
    root /home/ochev/html/ochevidets.ru/video/;
}

Директива root указывает, где лежит корневая папка для данного запроса. Т.к. у вас уже location равен /video/, то файл /video/1.flv будет искаться по адресу ochevidets.ru/video/video/1.flv.

Об этом написано в справке nginx. Вы бы знали, если бы читали её.
Дать права на чтение ведеофайла группе nobody это жутко некошерно.

Права пользователей должны быть более ущемлены, чем права веб-пользователей. Это брутально.
Ну там может быть скрипт при inotify / IN_ACCESS, меняет права, а потом возвращает их в «кошерное» состояние? :)))
добаляйте плз тег /ирони а то начинающие путаются после 200+ комментов )
Как, правда, серьезно? Вы не можете дать всем права на чтение публичных файлов, которые раздаются любому ананимусу по протоколу http? О-хо-хо.
Или вам просто страшно признать, что вы выбрали не ту профессию?
в рамках хостинга если дать права на чтение всем файлов всех, то туда попадёт многое из того, что не нужно видеть другим
Это видно и так всем! не только тем. кто на сервере, но вообще всем по http! Если там и есть что-то, что не нужно видеть другим, то его все равно видно.
Зачем всех файлов? Вас никто не просит скрипты давать читать всем желающим.

И вроде рамки единственного юзверя на сервере, если не всю статью позабыл.
1) вроде как у вас уже свой выделенный сервер стал а не хостинг?
2) не обязательно всем файлам давать одинаковые права. Ставьте php скриптам 600 а видео и статике 644
я ж не программист сайта. а он может и забыть об этом. лучше сделать так, чтобы он чтобы не выставил то это не создало бы никаких проблем
вообще знаешь, мне страшно. 69 человек добавили в избранное, плюсуют.
года 3 назад слили бы со свистом такой материал. и автора в придачу.
Ох-хо-хо, как-же это похоже на другой уважаемый ресурс, ну хоть в ПГ автора не выберут :-)
Здесь же не филиал, чтобы это обсуждать, право слово.
я добавил из-за комментариев — сам пост слабый, но комментарии вытягивают :)
Вы бы поинтересовались для чего взялись правила с www

Убедились бы, что оно срабатывает в одном случае из 1000, если все остальное в норме. (То есть пользователя (не каждого) редиректнет при первом посещении, а дальше в ссылках, адресах картинок, и т.п. всегда будет www и никаких больше переадресаций).

А то, что было сломал и оптимизации пшик поимел…

Если не знать, зачем её туда добавили.
Жду поста: а потом боты поисковиков неожиданно стали делать в два раза больше запросов и мы купили ещё 8 гигов оперативы.

Кстати вам повезло с разрядностью предустановленной оси, не находите?
так и приходится работать, когда первоначальные разработчики испарились.
сервер собирался (давно) по моим пожеланиям, так что это не везение, а расчёт)
если у вас 2-3 секунды генерируется страница, то это, простите, ппц.
реально повлияло на скорость добавление памяти и то, что превьюшки больше не создаются при каждой загрузке страницы (ОМГ!!!).
Я думаю если бы вы не делали остального, результат получился бы примерно тот же.
Кстати, про превьюшки, а почему так мало народа использует ngx_http_image_filter_module? Почему-то программисты считают ресайз своей прерогативой :-) (когда можно будет накладывать варермарки, nginx отберет у них последний аргумент).
Мое мнение — делать ресайз картинок (блокирующая, ресурсоемкая операция) в асинхронном сервере — неправильный подход.
Ну в теории, если контента много, а вариантов превьюх тоже много, то не создавая сразу стотыщьмиллионов картинок, а создавая их первых раз по запросу мы можем поберечь свои ресурсы.

Хотя, на одном из проектов, когда умер диск с превьюхами, то бот images.yandex.ru прошедший по всему архиву систему нагрузил, да.
Можно сделать что то в стиле
try_files $uri @image_resizer
а в @image_resizer уже запрос к какому то внешнему ресайзеру (апач, PHP etc)

Просто Nginx это в первую очередь асинхронный прокси — сервер. Так что если его загружать ресайзом картинок, то асинхронный поток может часто блокироваться… А плодить много воркеров для Nginx не принято. Если заняты все бекенды (апачи, php-fcgi) то это в общем то штатная ситуация, а если заняты все воркеры Nginx…
Я не думаю, что Игорь писал бы модуль делающий всё то-же самое, что phpшный ресайззер, только «долго, дорого и х… во» :-) В обычной работе я проблем не видел с нагрузкой, хотя конечно нужны нормальные тесты.
Да, согласен. Возможно, в принципе, что там ресайз идет в отдельном потоке либо он какой то хитрый потоковый. Нужны тесты.
Ну поиск по рассылке на www.lexa.ru/nginx-ru/ не показал проблемы, это не значит, что её нет, но уже о чём-то говорит. Попробую на выходных тесты сделать.
Игнорь советует ставить 2 nginx'a — 1й с proxy_cache и proxy_pass на 2й nginx, который уже будет делать ресайз. В этом случае воркеры 1го блокироваться не будут, и кэш будет поддерживаться внутренними средствами.
sysoev.ru/nginx/

Nginx заявляет ресайз картинок как одну из своих ключевых возможностей
Основная функциональность HTTP-сервера:

# модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, XSLT-фильтр, SSI-фильтр, преобразование изображений; несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно.
да ладно. 1 раз сконвертить картинку и 1к раз показать куда проще чем 1к раз сконвертить ее и тем самым тратить процессорное время и отвлекать воркеры.
немного не понял про «1к сконвертить», при image_filter + try_files?
картинки то налету генерятся. лучше сконвертить в нужный размер 1 раз и потом отдавать. без всяких преобразований на лету.
Что такое «на лету» в вашем понимании?

Допустим, сервис имеет 4 размера превьюшек. Что быстрее, аплоад и показ какой-то одной (на странице загрузки) или вообще никакой (если там тупо ОК пишется), чем аплоад и создание этих четырех превьюх, одна из которых (для каких-нить экранов мобильных) запрошена будет вообще не скоро. Я конечно описал очень частный случай, но всё-же.
Мне кажется, WoZ просто не поял, что nginx умеет складывать результат на диск.
ngx_http_image_filter_module только конвертирует. какими способами результат преобразования писать на диск?
замечу, кэшировать и писать результат на диск это разные вещи.
ок, соглашусь. правда следить становится сложнее за удаленными/обновленными файлами.
Ну для обновления достаточно генерировать каждый раз уникальное имя, что в общем-то не сложно. С удалением несколько сложнее конечно.
Как я понял там имеется в виду превьюшка видео, т.е. из видео вырезается случайный (или определенный) кадр и отдается как превьюшка.

Хотя могу ошибаться.
кхм.
для улучшения времени загрузки на комп клиента обычно работают над всякими вещами, вроде css-спрайтов, объединением и сжатием js-файлов и тд.

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

За час-два можно было убрать апач к чертям и на этом закончить.
Да апач не плохой, как бы без него дров больше наломает автор, с php-fpm вопросов больше же будет. (ну или с реврайтами, если уж отдачу статики на nginx автор почему-то не осилил с наскока).
Но учитывая то, что при обычном просмотре каталогов из mc наблюдалось торможение проблема была явно в дисковой подсистеме.
Надеюсь не после запуска mc по ssh данный вывод был сделан.
Результат обслуживания запроса: Возможно, запрашиваемый Вами сайт не отвечает или время запроса истекло. Проверьте правильность написания адреса или попытайтесь повторить запрос.
Для владельцев сайта:
Сайт перегружен или заблокирован.

Звоните: +7 495 943-11-23, +7 495 978-43-49
Пишите:
Администратор

Here is result of your request:Probably the requested site doesn't answer or it timed out. Check the address or try again.
Administrator

01:48 МСК
02,12,2010
Да боже-ж мой, как может сайт падать от хаброэффекта? Как он тогда гугл с яндексом переживает?
честно говоря я этого падения не видел. зашёл — работает быстро. видимо в какой-то момент у апача воркеры закончились
А все разглядели что загрузка страницы подвисает на загрузке скриптов бегуна и им подобным.

Все молчу. Мне кажется тут комментариев дали на большую сумму чем работа автора стоила.
> Самый красивый способ, который я знаю, закешировать огромное количество данных это рейд карта с поддержкой технологии Max IQ. К аппаратному рейд-контроллеру подключается SSD Drive на 64 и более ГБ. И вуа-ля! Мы имеем кеш 64 Гб! Красиво — но дорого для начала нужен сам контроллер с поддержкой Max IQ ($500) и специальный SSD Drive (от $1000).

Что за контроллер вы использовали, диски и SSD?
Это адаптековская фишка. И ssd продаётся в комплекте специальный.
Мне нужны конкретные модели дисков и контроллеров, их пропускная способность. Может 3Ware 6Гб с SAS дисками будет дешевле, быстрее и масштабируемее, чем этот adaptec.

Хотя я 100% не стал бы использовать их контроллеры :)
и как это поможет узнать модель диска, которую использовал автор?
Вам чисто на постебаться нужно знать, или вы не можете даже найти аббреивиатуру SSD для вышеприведённом pdf?
Чувак, ты читал начало ветки? Можешь рассказать что использовал человек — скажи, хочешь пальцы погнуть — можешь прям под этим постом поучить жизни.
Ам… эм… чё-та я пропустил это. :)

SATA2 с SSD под ZFS, полагаю, дадут как раз нужную производительность.
Ого, у нас уже ведущие занимаются проблемами быстродействия сайта
Продолжим за оптимизацию.
Зачем в БД отдельная ячейка для превью.
Вроде всю жизнь хватало структуры папок и единственного имени файла в БД.
Для имени превьюшки можно использовать айдишник записи в базе, зачем лишняя запись?
незачем. я дал избыточные рекомендации кодеру с тем, чтобы гарантированно он грохнуд превьюшку при удалении ролика, даже если он сделает имена у превьюшек случайными.
Добавлю свою лепту…
— стоит избавится от апача вообще, настроить nginx через spawn-cgi, зачем лишние ресурсы тратить
— статику раздавать через другой порт, на котором будет висеть squid, как кеширующий прокси, у которого будет выделено несколько гигов оперативки под кеш мелких файлов (например до 15-20мб), при правильной настройке в кеше будут сидеть в основном превьюшки и самые популярные ролики, таким образом жестко уменьшаем соличество операций с диском
— ничего не было сказано про кеширование опкода, поэтому стоит проверить используется там какой-либо оптимизатор (в последнее время пользуюсь APC)
Напишите, пожалуйста, подробнее про второй пункт (другой порт и squid). Довольно интересно решение. Как по-вашему, насколько оно лучше кэширования статики средствами nginx?
По-поводу сквида надо целую статью писать, но суть в том, что проски это основная его задача, поэтому он намного гибче в настройке чем nginx или lighttpd
Не вижу, в чём должно проявлятся преимущество его гибкости для простой задачи кеширования всех файлов.
Другими словами, по прежнему неясно, чем здесь squid будет лучше nginx
Когда объем файлов на 2-3 порядка превышает максимально возможный объем оперативной памяти которую является возможным выделить под кеш, то задача эффективного кеширования уже не такая простая. Вероятность попадания в кеш в дефолтном режиме порядка 5%-10%, что не является сколь-либо приемлемым результатом, после некоторых оптимизаций(путём подбирания настроек) удалось поднять эту цифру до порядка 70-75%.
Контетном было порядка 80,000 видеофайлов общим размером ~3.5Тб + по 3 картинки на каждое.
Не думаю что тянет на отдельную статью:
кеширование производилось в RAM и отдельный винт (HDD), хранилище данных 4х1,5Tb RAID5
— картинки с возрастом не более недели в RAM, на несколько дней (точно не помню на сколько)
— видео с возрастом не более суток и размером не более 20Мб в RAM, ttl 12часов (свежак появлялся на главной и был самым востребуемым)
— видео которое смотрели несколько раз (>= 3) размером в HDD (часто всплывало
несвежее видео которое рассылается всему контакт листу какого-либо), ttl 12ч
— шейпинг скорости отдачи видео с RAID-массива на уровне 4Мбит, т.к. часто смотрели большое видео которое в кеш не попадало
Под кеш выделялось всего 2Gb оперативки, и 30Gb HDD.
>видео которое смотрели несколько раз (>= 3) размером в HDD
размером до 50Мб
И всё же заметкой это было бы интересно.

P.S. Кстати, никогда не понимал, зачем использовать RAID5 на конфигурации из 4 винтов. RAID10 для них будет существенно быстрее и надёжнее на «половину HDD». А уж потерей пространства с нынешними ценами за гигабайт можно просто пренебречь и купить ещё пару винтов.
Ну во-первых он был хардварным, во-вторых RAID5 уже работал, оптимизации проводились на готовом проекте, который в силу неприбыльности просто продолжали поддерживать на плаву и денег под него выбить было нереально.

P.S. repka.tv, аминь
что за панацея с cgi у всех?

нет никакого прироста скорости у всех типов cgi. php_fpm ещё как то экономит память, но не время.

это миф, который распространяют те, кто вообще не пытался настроить mod_php. Он вполне быстр, если не использовать дефолтный конфиг.
Об оптимизации скорости отрабатывания php вообще речь не шла ни в комментах, ни в «статье».

Так что причем тут ваш прирост скорости…
widowmaker предлагает избавиться от mod_php в сторону fcgi и ему подобных механизмов. я к этому.
Практика же показывает, что в очень многих случаях никакого прироста ни в чём это не даст.
И не нужно говорить о том, что «в cgi меньше времени тратится на инициализацию». Для любого более или менее современного процессора, это такие копейки, что на них оглядываться не стоит.
Время на компиляцию php на современных процах уже давно пришло к чему то вроде «0.0хх секунд». Так что, если сайт не написан изначально с использованием фич fcgi — то ничего особенного в скорости не случится.
Люто, бешено плюсую. Не понимаю вообще с чего взяли что php-fpm быстрее mod_php. При правильной настройке и памяти меньше потребуется и работать шустрее будет.
Из-за особенностей nginx, он будет ждать пока скрипт выполнится и освободит воркер, т.е. если количество выполняемых php скриптов и воркеров nginx будет одинаковым, то все новые соединения будут становится в очередь и ждать освобождения воркеров. Поэтому mod_php использую для апача, FPM для nginx и lighttpd.
Хочется уточнить, «nginx будет ждать пока скрипт выполнится и освободит воркер» в слуае proxy_pass? А при fastcgi_pass не будет? Почему различия в столь схожих механизмах (у них даже многие диррективы дублируются)?

К тому же у меня есть обратный опыт, при большом наплыве посетителей на слабой машине, когда nginx ждал каждого ответа от апача по 30+ секунд, статика летала будь здоров. Да и вроде нагрузка между воркерами апача была равномерной, хотя их количество было 7, а nginx — 2.

Кстати, могу даже картинку приложить:

Это я искуственно сделал ab -n 1000 -c 20
epoll/kqeue вам на что?

Да и не будет воркер ничего ждать. Воркеры — многопоточны. Затык будет только тогда, когда буду заняты все чайлды — пользователь увидит Bad Gateway, если вы всё правильно настраивали.
А вот время занятости чайлдов апача нужно снижать, да.
Воркеры Nginx не многопоточные а асинхронные насколько мне известно. Хотя сути это особо не меняет.
debian.pro -> lamp, 5 частей + nginx в условиях ограниченных ресурсов.

Для midlle-load — самое то.

+ выключать ненужные модули и в mod_php и в apache.

Только количество воркеров подберите правильно.
Приятно когда приходит клиент с полностью убитым сервером и настройками «как заработало» — тогда любые найденные в гугле фишки убыстряют, особенно когда память в несколько раз подняли :)
На сайте этом ни одно видео не работает, флв файл не находит
Возможно дело вот в чем:
# один пользователь может смотреть одновременно 2 ролика
limit_conn one 2;
Я не любитель давать людям заочные оценки, но автор поступает как очень неумный и недальновидный человек, поправив изначальную статью без указания на авторов людей, которые в комментариях топикстартеру и разжевали всё, и в рот положили.

Я не делал diff c первоначальной публикацией, но

текущий текст:
Но ещё лучше заставить nginx отдавать статику напрямую. Например так:


разительно отличается от первоначального:
Я записал себе в список дел настроить nginx раздавать статику напрямую. В этом посте я касаться этого не буду.


Хотя автор просто не разобрались в плёвой проблеме, пока его не ткнули носом в конкретную ссылку.

Не говоря уж о добавленных впоследствии записях о slow log мускула и прочих.

Хреново поступаете «уважаемый».
я уже говорил о том, что если бы главный критикующий общался бы без мата, то я дал бы на него ссылку.

кроме того я говорил об ограниченном времени и бюджете из-за которых все нужные настройки не были сделаны сразу.

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

А насчёт slow — об этом был вопрос в комментах и я вспомнил соотвествующие детали.

Если статья изменяется и информация всё время остаётся актуальной — это очень хорошо.
Главный критикующий дал вам ценные советы, которые вы применили. Неумение признавать критику это очень печально.

Если статья изменяется и информация всё время остаётся актуальной — это очень хорошо.

Вы правда не понимаете разницу поправить статью на актуальную (там параметр в конфиге забытый какой-нибудь) или написать ахинею на 50%, расписаться в своём не профессионализме, а потом выехать за счёт дельных советов, в том числе, «главного критикующего»? Впрочем можете не отвечать, ответы и так понятны будут тем, кто осилит прочитать ветку.
начнём с того, что изначально я решил проблему клиента.
потом один матерщинник-перфекционист пристал со своей одной строчкой конфига, которую нужно поправить.

А статью безо всяких правок 50 человек отметило плюсом, а 70 занесло в избранное, так что у вас явно неверные критерии оценки её качества
А статью безо всяких правок 50 человек отметило плюсом
А если бы вы написали, что все пользователи хабар — пидарасы, плюсиков было бы намного больше, прецедент уже был.
кроме того я говорил об ограниченном времени и бюджете из-за которых все нужные настройки не были сделаны сразу.Ну зачем вы повторяетесь, я вам уже отвечал — единственная нужная настройка, которая бы снизила io в 3-4 раза, не требует ни времени ни бюджета.
а я уже говорил, что на тот момент у меня не было времени продумывать систему прав. и к тому же со мной за то что я сделал ещё полностью не рассчитались. зачем работать бесплатно?
Напоминает:

За такую зарплату нужно не только не работать, а еще немножечко вредить!
Вы продолжаете нести феерический бред. Неполностью заплатили? Вам заплатили за комментиирование строчек с редиректом? Вот это можно было не делать, а сделать раздачу видео nginx, по времени столько же выходит. Меня ваши работы и оплата вообще не касаются, я обсуждаю статью.

«Продумывать систему прав» — это что? Вам было сложно продумать, какие права должны быть на файл, чтобы его смог читать nobody? Вам даже это, кстати, ражевали в комментариях. Вы даже это не сообразили сами.
ну тогда и коменты обсуждай. у любого поступка есть основания. которые я объяснил.

я сделал и много другого, что не вошло в статью.

и вообще, если ты легкомысленен в вопросах прав пользователей, то я не должен быть таким.

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

Это видно уже по вашему ответу:
не могу сказать из соображенией безопасности


Как по вашему работают хостинги с фронтендами?

И сильно улыбнуло обвинение homm в заботах о упоминании в «статье».
в теме. я админю сервера уже 12 лет. и поэтому я стараюсь глубоко продумывать каждый шаг в этой сфере и не совершать легкомысленных телодвижений.
я админю сервера уже 12 лет
Вот тут я вам верю. Миф о сложности работы и нужности админа для каждого сервака поддерживается админами очень успешно.

я стараюсь глубоко продумывать каждый шаг
Я вижу, на сколько вы хоршо продумали раздачу статики через перезапись на диск. Действительно, до такого нужо было додуматься.
вам непременно нужно доказать кому-нибудь, что вы очень умный, поэтому вы вырываете слова из контекста и игнорируете комментарии, в которых я объясняю мотивы каждого своего решения.
Да нет у вас мотивов, вы каждый раз придумываете оправдания для своей глупости.
есть. а вам нужно доказать, что вы самый умный. в детстве мало хвалили? или есть комплекс сверхполноценности?
скорее это вам нетерпится доказать всем какой вы тупой безграмотный дилетант.
НЛО прилетело и опубликовало эту надпись здесь
Пионеры уже давно исчезли с горизонтов

mysql> show status like 'Threads%';
+-------------------+---------+
| Variable_name | Value |
+-------------------+---------+
| Threads_cached | 0 |
| Threads_connected | 2 |
| Threads_created | 1576627 |
| Threads_running | 1 |
+-------------------+---------+
4 rows in set (0,02 sec)

mysql> show variables like 'thread_cache_size';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| thread_cache_size | 0 |
+-------------------+-------+
1 row in set (0,03 sec)

mysql> show status like '%tables';
+-------------------------+--------+
| Variable_name | Value |
+-------------------------+--------+
| Com_lock_tables | 0 |
| Com_show_open_tables | 6 |
| Com_show_tables | 31 |
| Com_unlock_tables | 0 |
| Created_tmp_disk_tables | 689730 |
| Created_tmp_tables | 691381 |
| Open_tables | 64 |
| Opened_tables | 1477 |
| Slave_open_temp_tables | 0 |
+-------------------------+--------+
9 rows in set (0,00 sec)

Я вижу проблему в последнем запросе, как заказчик созреет — буду оптимизировать
НЛО прилетело и опубликовало эту надпись здесь
спасибо за совет!
а стоит ли ставить такое большое число?
Ведь запущенных всего 2 (правда сейчас не час пик).
Не много ли памяти это займёт?
НЛО прилетело и опубликовало эту надпись здесь
насколько я понимаю философию ядра linux данные всё-таки храняться. это, конечно, не код. а дата-сегмент для каждой копии одинакового кода. согласен, что этим часто можно пренебречь.

было бы инетерсно узнать какой объём данных в памяти отводится для каждой thread
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
У него чуть меньше двух гетов в секнду, зачем ему 32 треда.
НЛО прилетело и опубликовало эту надпись здесь
Я не по количеству подключений сужу, а по данным из этого комментария. Не знаю, правда, откуда DLag взял это число, но вроде никто ему не возразил.
НЛО прилетело и опубликовало эту надпись здесь
да, теперь слабым местом субд остается.
судя по всему, надо настраивать max_user_connections, max_connections и thread_cache_size

Простое тестирование одной и той же страницы ложит сервер БД.

$ siege http://www.ochevidets.ru/videos/0/882/all/views/ -c50 -r20 -d0

The server is now under siege..      done.
Transactions:		         347 hits
Availability:		       34.70 %
Elapsed time:		       25.82 secs
Data transferred:	        5.15 MB
Response time:		        1.99 secs
Transaction rate:	       13.44 trans/sec
Throughput:		        0.20 MB/sec
Concurrency:		       26.68
Successful transactions:         347
Failed transactions:	         653
Longest transaction:	        3.05
Shortest transaction:	        0.12
НЛО прилетело и опубликовало эту надпись здесь
добавлю момент — картинки лучше ресайзить средствами nginx с кеширование в файлы, незачем нагружать программиста )))
а сорри не прочитал.
в принципе могу выложить готовый конфиг nginx который у меня этим занимается
Да конфиг там простой, интересно было-бы протестировать на скорость и ресурсоёмкость image_filter по сравнению с пхпшными бекендами.
О, как раз хотел
location /video/ {
aio on;
directio 512;
output_buffers 1 128k;
}

посоветовать
На линуксе aio требует directio, что не есть хорошо с точки зрения кэширования ОС файлов. Имеет смысл только для файлов >100мб, которые всё равно в кэш особо не лягут. А тут мелкие ролики — топовые пусть лучше лежат в кэше, чем читаются постоянно с диска из-за directio.
Осилил… Редиректы зря убрали все-таки. Ни разу не слышал, что они могут хоть сколько-нибудь ощутимо нагружать сервер.
Так задача всегда не сервер разгрузить, а клиентов ускорить.
И все же. Время на редирект минимально, но он важен. Нужно просто посмотреть какой урл чаще используют и сделать его основным.
не сталкивался ещё со случаями, когда это имело значение. дажи тиц и pr показываются одинаковые для домена с www и без него
Могут быть проблемы со склейкой зеркал (у яндекса зеркальщик ужасный), с контекстной рекламой и вообще это мовитон)
они вызывались на всех картинках, которых на странице 30-40 (включая элементы дизайна)
Элементы дизайна должны быть прописаны в css. В любом случае поставьте редирект и посмотрите насколько измениться время загрузки. Я не думаю, что там будет ощутимая разница. Без редиректа другие проблемы вылезут, о которых уже писали выше.
да, по результатам тестирования разница незначительна. keep-alive видимо выручает.

этот сайт кодил не я, поэтому на нём такая вёрстка
Я правильно понимаю, что у вас там все пути абсолютные, да еще и не на тот домен?
Черт, правильно. Домены прописаны абсолютно и у разных картинок домены разные. Феерично.
Вставлю свои пару копеек:

— с этим gzip_types text/html nginx, вероятно, не стартанет из-за ошибки, ибо этот тип есть по дефолту в конфигурации, описывать его не надо.
— при отдаче flv не надо ограничивать скорость и количество потоков, это я понял по своему проекту, диск от ограничения скорости умирает намного быстрее и хуже, если этих потоков достаточно много (лучше быстрее отдать клиенту, чем занимать память кеша или постоянно по чуть-чуть читать с диска), если есть ограничения потоков — будут постоянные ошибки при просмотре flv в плеере, он не всегда правильно закрывает коннект во время seeking, в итоге — пару раз перемотал и получил 503.

А вообще, в таком деле память решает все, у меня на сервере 14 гигов оперативки и 4 ядра, а и он с легкостью раздает 600 мбит видеопотока и обычного файла. Хотя у меня настройки в nginx получше ваших :)
вот что бывает если школьники делают такой сайт. Серьёзно, order by rand(), неправильная ссылка на картинки без «www», отсутствие простейшего кэширования прьевьюшек — умный разработчик себе такого бы не позволил.

«В бд завести отдельную ячейку для превью» — зачем? Можно и так хранить в виде файла в отдельной папке, но с тем же именем.

Не озвучен размер базы, без этого не понятно, нужна ли была RAM или нет.
спасибо. закрыл. этой рабочей копии уже лет 8. и её код никому не нужен.

а вот все более поздние остальные проекты по этой дыре были хорошо закрыты изначально. и в список (который уже озвучивался на Хабре) не попали
Мелочь конечно, но можно так написать
server_name .ochevidets.ru;
Можете объяснить, зачем это нужно? Будут ли данные сжиматься, зависит от того, что послал клиент в заголовке Accept-Encoding, а не от его юзер-агента.
Видимо, ha2bj о проблеме сжатия http в ie6. При этом в заголовках http от браузера есть поддержка сжатия, но ошибка при обработке сжатого контента возникает.
По идее, все модули сжатия (для apache, nginx и для CMS) учитывают эту особенность. Но директива «gzip_disable msie6» всё равно отдельно есть.
резюмирую статью:

у меня был сервер, он тормозил. я в 5 раз увеличил количество памяти, и провёл тонкую настройку gzip-буферов у nginx.
теперь всё работает быстро — вот чего можно добиться с помощью тонкой настройки!
Даже такое, казалось бы простое, решение нужно уметь принять. Если бы после установки памяти всё осталось бы в тормозящем состоянии, то мне пришлось бы заказчику деньги за память из собственного кармана возвращать.

Проблема могла быть вполне в динамической генерации превью или в БД или старых винтах.

Есть притча как изобретатель за удар кувалдой получил 1000 долларов. Так вот тут из этой же серии.

И поскольку я не был на 100% уверен, чт