Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 407
все по делу, надеюсь, благодарность вашего клиента не ограничилась суммой «большое спасибо».
прогресс на лицо, молодец, поучительно!
но 2-3 секунды все-равно многовато!
но 2-3 секунды все-равно многовато!
какая кстати посещаемость портала, о каких нагузках речь?
До 60к просмотров в сутки.
Не так уж и много…
Сложилось ощущение что автор впервые задумался о настройке высоконагруженного проекта.
Не так уж и много…
Сложилось ощущение что автор впервые задумался о настройке высоконагруженного проекта.
не автор, а владелец)
Именно автор.
Как уже заметили, «тонкой настройкой» в статье и не пахнет.
Одни предположения о принципах работы, необоснованные выводы.
Итог вообще убил…
Как уже заметили, «тонкой настройкой» в статье и не пахнет.
Одни предположения о принципах работы, необоснованные выводы.
Итог вообще убил…
результат есть. в оптимизации вообще почти всегда так. одна вещь даёт 80% эффекта. правило паретто
на самом деле 20% чего либо дают 80% результата, стало быть в 20% может попасть сколько угодно правильных вещей, все зависит от ОБЩЕГО количества. )
Скажем я бы еще десяток пунктов добавил к вашей оптимизации.
Эти пункты бы в общей сложности дали бы минимум 10% снижения нагрузки на диски.
Это без добавления ОЗУ.
Оптимизация занятие комплексное, если 80% прироста дает один пункт, то того кто изначально настраивал систему нужно исключить из естественного отбора админов, т.к. это откровенная ошибка.
Эти пункты бы в общей сложности дали бы минимум 10% снижения нагрузки на диски.
Это без добавления ОЗУ.
Оптимизация занятие комплексное, если 80% прироста дает один пункт, то того кто изначально настраивал систему нужно исключить из естественного отбора админов, т.к. это откровенная ошибка.
> Через день подвезли память и после её установки сервер по настоящему вздохнул свободно — страницы стали загружаться за 2-3 секунды.
А потом пришёл лесник… Если процессы вистя на I/O, то сразу надо начинать с этой оптимизации, остальное не очень осмысленно оптимизировать, пока не устранена главная проблема. Единственный разумный момент из «тонких» настроек я увидел, это ограничение скорости одного потока, остальное можно было не трогать до добавления памяти, и смотреть уже после что же нужно оптимизировать дальше и нужно ли. Редиректы вполне имеют право на жизнь, вопрос, возможно, в содержании самих страниц, не содержат ли ссылки на картинки в своих URL имя сайта, при этом без www. Иначе, редирект должен происходить при первом обращении к странице, после этого весь сайт должен стать сразу «правильным», без лишних редиректов.
А потом пришёл лесник… Если процессы вистя на I/O, то сразу надо начинать с этой оптимизации, остальное не очень осмысленно оптимизировать, пока не устранена главная проблема. Единственный разумный момент из «тонких» настроек я увидел, это ограничение скорости одного потока, остальное можно было не трогать до добавления памяти, и смотреть уже после что же нужно оптимизировать дальше и нужно ли. Редиректы вполне имеют право на жизнь, вопрос, возможно, в содержании самих страниц, не содержат ли ссылки на картинки в своих URL имя сайта, при этом без www. Иначе, редирект должен происходить при первом обращении к странице, после этого весь сайт должен стать сразу «правильным», без лишних редиректов.
я не вижу смысла в подобных редиректах вообще
это проблема решается элементарно.
ставим куки на *.host
ставим куки на *.host
так можно поставить только с host, а вот попытка поставить с www.host куку на *.host фейлится.
Вот и тема для новой статьи.
Ко мне обратился владелец ресурса ****. Ряд пользователей его сайта жаловались, что их разлогинивает во время серфинга.
Я настроил хранение сессий в БД.
Изменил время жизни кук.
Задал красивое имя идентификатору сессий.
А потом админ сайта из больницы с мобильного добавил редирект.
Ко мне обратился владелец ресурса ****. Ряд пользователей его сайта жаловались, что их разлогинивает во время серфинга.
Я настроил хранение сессий в БД.
Изменил время жизни кук.
Задал красивое имя идентификатору сессий.
А потом админ сайта из больницы с мобильного добавил редирект.
а у меня не фейлится. тестировал в файрфоксе
следуя такой логике, я возьму и с site.com поставлю кук на несколько мб на .com) пусть клиент всем рассылает эти куки)
На .com нельзя поставить, т.к. куки ставятся только на домены с двумя компонентами.
Установка на example.com с www.example.com будет работать — у самого так делает сайт: одна авторизация на все субдомены.
Установка на example.com с www.example.com будет работать — у самого так делает сайт: одна авторизация на все субдомены.
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? Какой в них смысл? Практическая польза? Или может так сложилось исторически?
Как минимум нужны, если www (выдача html документов) не основная функция домена, а, например, лишь веб-морда или документация к ней.
Для некоторых людей www ассоциируется с интернетом, т.е. типа если есть www то это однозначно сайт.
Если реклама сайта дается по радио/телевизору/в печатных изданиях www в начале адреса помогает идентифицировать это как 100% сайт.
Но вообще все зависит от аудитории сайта.
Если реклама сайта дается по радио/телевизору/в печатных изданиях www в начале адреса помогает идентифицировать это как 100% сайт.
Но вообще все зависит от аудитории сайта.
Куки на .host доступны со всех поддоменов, а поэтому не всегда уместны. Например, когда на поддоменах работают какие-либо партнерские программы.
у меня есть партнёрские программы на других поддоменах на askfor.info. Просто дал имена кукам разные и проблема решена в зародыше)
Проблема в том, что недобросовестный партнер может воспользоваться куками твоего сайта. Что из этого может получиться зависит исключительно от фантазии злоумышленника.
если он сможет изменить куки, то только те, что лежат у него на компе. а это он сможет сделать в любом случае, к какому бы домену они не относились
Зачем менять, если ими можно воспользоваться? Стащить авторизационную куку, к примеру.
стащить куку он сможет только у самого себя — куки хранятся на стороне клиента
Я имею в виду недобросовестную партнерскую программу, которая скрыто занимается сбором данных ресурса верхнего уровня.
Вы поразительно тупы. Все просто как двважды два:
site.com и www.site.com — ваши сайты, на которых есть авторизация. Вы ставите куку на хост .site.com.
friends.site.com — сайт вашего партнера. Ему приходят куки авторизации ваших пользователей.
Об этом говорит dimoclus.
site.com и www.site.com — ваши сайты, на которых есть авторизация. Вы ставите куку на хост .site.com.
friends.site.com — сайт вашего партнера. Ему приходят куки авторизации ваших пользователей.
Об этом говорит dimoclus.
Мне такой идиотский ход даже в голову прийти не мог. если я даю полностью на откуп партнёрам имена третьего уровня, то я могу получить любую гадость: от порнографии до терроризма или финансовой пирамиды.
Одними из первых этой дырой в имидже воспользуются конкуренты.
И разбираться из ФСБ придут со мной.
Одними из первых этой дырой в имидже воспользуются конкуренты.
И разбираться из ФСБ придут со мной.
у меня партнёры не имеют доступа к коду партнёрских программ
А между тем так делать не хорошо. Если вы не видите и не знаете — не надо трогать, надо разобраться. Для помощи перетащили бы эти редиректы в конфиг nginx и успокоились. Потом Иван Усачев придет к оптимизатору и спросит, почему поисковые системы считают сайт с www и без двумя разными сайтами. А откуда оптимизатору знать, что админ не видит в этих редиректах смысла.
Или часть рекламы не оплачивается.
Всё правильно чувак сделал. Оптимизатору тоже будет теперь чем заняться.
Всё правильно чувак сделал. Оптимизатору тоже будет теперь чем заняться.
поисковики очень хорошо разбираются в идеентичности сайтов без всяких редиректов
Это не ваша зона ответственности и ваши догадки.
help.yandex.ru/metrika/?id=1036894#1053660
Ключевая фраза:
help.yandex.ru/metrika/?id=1036894#1053660
Ключевая фраза:
Чтобы правильно настроить web-сайт, рекомендуем обратиться к вашему системному администратору или самостоятельно отредактировать файл .htaccess на вашем web-сервере.
о пользе контекста:
перед этим идёт:
Т.е. c практической точки зрения, а именно с точки зрения ТиЦ, PR и метрики домен с www и без него (если контент одинаков) — одно и тоже.
А то, что касается «правильности» с точки зрения яндекса — это вещь чисто теоретическая и не относящаяся и никак не влияющая на реальность.
В принципе одна переадресация сайт почти не замедлит, но в моём случае их было несколько (ещё на картинках с полными путями — я сайт не разрабатывал!), поэтому это был разумный шаг.
перед этим идёт:
Почему объединяется статистика по доменам с www и без www?
Наши исследования показали, что некоторые владельцы не могут правильно настроить свой web-сайт, и в интернете их сайт представлен как www.domain.ru, так и domain.ru. Случаи, когда это делается владельцами сайтов умышленно, крайне редки, поэтому мы решили объединять статистику по таким доменам.
Т.е. c практической точки зрения, а именно с точки зрения ТиЦ, PR и метрики домен с www и без него (если контент одинаков) — одно и тоже.
А то, что касается «правильности» с точки зрения яндекса — это вещь чисто теоретическая и не относящаяся и никак не влияющая на реальность.
В принципе одна переадресация сайт почти не замедлит, но в моём случае их было несколько (ещё на картинках с полными путями — я сайт не разрабатывал!), поэтому это был разумный шаг.
Для Google www.host.com и host.com — это два разных сайта.
как тогда объянить то, что pr у моих сайтов (без редиректов) с www и без него одинаковый?
www.askfor.info
www.inetstar.ru/
www.moneyorder.ru/
Приведите контпример хоть одного сайта неиспользующего редиректы, имеющего одинаковый контент и имеющий разный pr у версии с www и без него.
www.askfor.info
www.inetstar.ru/
www.moneyorder.ru/
Приведите контпример хоть одного сайта неиспользующего редиректы, имеющего одинаковый контент и имеющий разный pr у версии с www и без него.
Кстати, если бы редиректы раздавал Nginx то это не дало бы почти никакой нагрузки, но там Nginx обращался к апачу, апач уже на основе htaccess возвращал редирект, что на порядок медленнее и нагружает бэкенд
Скорость потока ограничили скорость потока ограничили…
Следите за руками. Контент у нас все ещё отдаёт апач. Так я высасываю ролик за 10 секунд, а с ограничением скорости почти две минуты.
То есть многомеговый воркер апача работает на меня много дольше, чем мог бы.
С какого момента это становится оптимизацией?
Следите за руками. Контент у нас все ещё отдаёт апач. Так я высасываю ролик за 10 секунд, а с ограничением скорости почти две минуты.
То есть многомеговый воркер апача работает на меня много дольше, чем мог бы.
С какого момента это становится оптимизацией?
Так, что это вторая вещь, которой сделали хуже чем было.
воркер отрабатывает быстро, нгинкс быстро всасывает, а вот отдаёт медленно. воркеров апача там 50 штук.
Кстати, скорее всего Nginx считает с апача весь видеофайл так быстро как сможет и положет во временный файл на диске (если в памяти в буфере не поместится).
А потом уже из этого временного файла/буфера будет медленно отдавать см sysoev.ru/nginx/docs/http/ngx_http_proxy_module.html#proxy_buffering
А потом уже из этого временного файла/буфера будет медленно отдавать см sysoev.ru/nginx/docs/http/ngx_http_proxy_module.html#proxy_buffering
nginx не пытается считать весь ответ проксируемого сервера, максимальный размер данных, который nginx может принять от сервера задаётся директивой proxy_buffer_size.
Самый конец того параграфа.
Я 5 лет проксирование не делал и могу ошибаться, но вроде стало хуже по вышеозвученным причинам.
Самый конец того параграфа.
Я 5 лет проксирование не делал и могу ошибаться, но вроде стало хуже по вышеозвученным причинам.
Самое начало того параграфа: «Если буферизация выключена, дальше ваш текст». По-умолчанию она включена.
всё зависит от величины этого буфера. срелний размер ролика 1,5-2 мб.
При 50 клиентах это всего лишь 100 мегабайт. Даже если всё загнать в буфера. У меня бууфер достаточен, чтобы вместить ролик
При 50 клиентах это всего лишь 100 мегабайт. Даже если всё загнать в буфера. У меня бууфер достаточен, чтобы вместить ролик
у меня в проекте был форум с поиском через лайк-два процента.
сервер ужасно тормозил… решили докупить оперативки
после подвоза оперативки с 4 до 16 сервер вздохнул свободно.
но только на два дня. Через два дня — снова стал безбожно тормозить.
С переписыванием этой части функционала и переходом на сфинкс — показание аптайма с 25 упало до 3-5.
сервер ужасно тормозил… решили докупить оперативки
после подвоза оперативки с 4 до 16 сервер вздохнул свободно.
но только на два дня. Через два дня — снова стал безбожно тормозить.
С переписыванием этой части функционала и переходом на сфинкс — показание аптайма с 25 упало до 3-5.
Читал и надеялся, что Вы своими руками все же спасете сервер, а спасла память в итоге :)
Хорошая статья, спасибо
Спасибо, очень познавательно, нельзя ли пояснить вот эту фразу:
В добавок как я узнал из вывода команды free из 8 гб кеша использовалось 300 мб, что само по себе очень плохой знак.
Т.е. на сервере 8 гиг свободной памяти отдано под кэш? и Вы еще доставляете 8? o_O и как определить сколько из кэша используется?
В добавок как я узнал из вывода команды 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 и используются…
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 из 8 гб кеша использовалось 300 мб, что само по себе очень плохой знак. Запись и подгрузка страниц из свопа может конкретно убивать производительность.
нужно использовать команду не free, а cat /proc/meminfo, и смотреть — inactive — кэш.
это была описка. имелся ввиду своп
proxy_pass подразумевает обращение к бекенду, а смысл в этом в случае раздачи статики?
location ~* ^/.+\.flv$ { flv; } — и nginx стримит flv без обращения к апачу…
location ~* ^/.+\.flv$ { flv; } — и nginx стримит flv без обращения к апачу…
Все верно, сразу палево заметил, когда какой-то .htaccess начал влиять на первычный nginx для статик файлов.
я не мог сделать все настройки сразу. изначально сервер был настроен под нескольких клиентов. если поручить в такой конфигурации раздавать nginx всю статику всех клиентов, то мы имеем дыру в безопасности.
если заказчик оплатит, то я перенастрою nginx как надо, т.к. остальные клиенты уже уехали с сервера
если заказчик оплатит, то я перенастрою nginx как надо, т.к. остальные клиенты уже уехали с сервера
ну на отдельный айпишник домен и nginx повесить…
хотя если трафик приличный — может все же имеет смысл отдельный сервер под проект выделить? )
хотя если трафик приличный — может все же имеет смысл отдельный сервер под проект выделить? )
Ну зачем всю и сразу?.. Можно самое грузящее передать в первую очередь:
location ~* ^/(content|static)/.+\.(jpg|gif|png)$ { }
location ~* ^/video/.+\.(flv)$ { flv; }
(ну а если сайт не сильно мудреный, так и до «всей статики» недалеко)
Да и причем тут остальные клиенты? location ведь используется в контексте server {}.
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
[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 раздавать статику напрямую. В этом посте я касаться этого не буду.
обычно это делается в первую очередь и именно для этого ставится фронтенд в виде nginx
обычно это делается в первую очередь и именно для этого ставится фронтенд в виде nginx
сервер настраивал изначально не я
не всегда для этого. если это хостинговый сервер (много клиентов), то нгикс ставится, чтобы разгрузить апач
не всегда для этого… то нгикс ставится, чтобы разгрузить апач
а где здесь противоречие с
обычно это делается в первую очередь и именно для этого ставится фронтенд в виде nginx
?
противоречие возникает, если не выкидывать кусок моей фразы «если это хостинговый сервер (много клиентов), ».
Если вы сделаете у всех пользовательских файлов права 666, то пользователи смогут подглядывать друг у друга, например, пароли к базам в php-скриптах.
Поэтому в хостинговых серверах часто обходятся только проксирующей функцией nginx.
Если вы сделаете у всех пользовательских файлов права 666, то пользователи смогут подглядывать друг у друга, например, пароли к базам в php-скриптах.
Поэтому в хостинговых серверах часто обходятся только проксирующей функцией nginx.
Я как-то был уверен, что nginx это прежде всего proxy сервер и ставится в первую очередь для разделения процессов формирования контента и его отдачи.
> маленькие превьюшки всё время генерируются автоматически из больших
Т.е. при одном просмотре одной странице со списком из 10 превьюшек, сервак считывал 10 больших картинок и конвертировал их на лету? Это не могло породить большее кол-во чтений чем скачивание видео? Если не больше, то порядок, наверное, тот же. Странно ещё, что проц не был загружен.
Т.е. при одном просмотре одной странице со списком из 10 превьюшек, сервак считывал 10 больших картинок и конвертировал их на лету? Это не могло породить большее кол-во чтений чем скачивание видео? Если не больше, то порядок, наверное, тот же. Странно ещё, что проц не был загружен.
Встречал такую проблему. Когда большее количество первый затык возникает в количестве воркеров апача. Во-первых такие превьюшки налетают на апач, забивают доступные воркеры и простаивают ожидая загрузки (удаленной или локальной) и конвертации. Клиенты которые пытаются загрузить страницу при этом ждут освобождения… Если воркеры апача не лимитировать, то их количество дико распухает, а ведь это тоже жрет память и процессорное время.
в принципе apache + php их генерит быстрее, чем nginx раздаёт, если у сервака много оперативки, но если мало — то своп всёё рушит.
но в данном случае динамическая генерация неопраданна
но в данном случае динамическая генерация неопраданна
это каким таким хитрым способом? упрощенно…
nginx:
1) запрос картинки
2) отдача клиенту
nginx+apache+php:
1) запрос картинки
2) проброс на апач
3) чтение картинки
4) конвертирование на лету
5) отдача нгинксу
6) отдача клиенту
nginx:
1) запрос картинки
2) отдача клиенту
nginx+apache+php:
1) запрос картинки
2) проброс на апач
3) чтение картинки
4) конвертирование на лету
5) отдача нгинксу
6) отдача клиенту
я имел ввиду следущее:
генерация картинки — 0.05 секунды, передача нгинксу — 0.001 секунды, скачивание клиентом картинки — 0.7 секунды
генерация картинки — 0.05 секунды, передача нгинксу — 0.001 секунды, скачивание клиентом картинки — 0.7 секунды
Только перед «генерация картинки 0.05 сек» Вы забыли написать «Чтение большой картинки, которая возможно весит 500кб — 1мб».
И это надо сделать 10 раз для одного отображения одного списка.
Я не сисадмин, а php-прогер и для меня это выглядит мега ужасно. Гораздо ужаснее, чем все остальные (не понятные мне пляски с бубном) вокруг iotop. Может быть именно это чтение больших картинок и создавала основную нагрузку на чтение?
И это надо сделать 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 без всяких апачей.
Ну и соответственно 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 файлам, что естественно скажется в лучшую сторону на производительности.
Как-то так )
в случае RAID0 головки дисков будут синхронно дергаться по запрашиваемым файлам (скажем, одновременно читается 32 файла с 8 дисков в RAID0 — на всех дисках головки бегают по 32 файлам)…
в случае если раскидать эти файлы по дискам — на каждом диске головки дергаться будут только по 4 файлам, что естественно скажется в лучшую сторону на производительности.
Как-то так )
MySQL на SSD? хмм… Хотя если только запись и чтение, без регулярных UPDATE и DELETE…
mod_php у apache обрабатывает скрипты на порядок лучше и временами быстрее чем php-fpm, так что это очень спорное утверждение что чистый nginx+php-fpm окажется лучше. Оно так же может быть и узким местом.
Что значит «на порядок лучше»? Может я поспешил с переходом на nginx…
Не поспешили. И nginx при правильной настройке работает прекрасно.
Просто меня добивает что люди упорно считают что всякие fcgi и прочие быстрее старого доброго mod_php.
Просто меня добивает что люди упорно считают что всякие fcgi и прочие быстрее старого доброго mod_php.
Скрипты работать быстрее не стали (медленнее вроде тоже), но стали меньше памяти есть и, как следствие, сервер выдерживает бОльшую нагрузку.
Ок. Для сравнения на моей VDS'ке: nginx+php-fpm съедали овер 450МБ, nginx+apache+mod_php — ещё не поднималось выше 300Мб. Я не спорю, может я как-то не так готовлю php-fpm, но мне хватило того, что он периодически из-за своих глюков дропал сессии, что на скорости ну никак положительно не отражалось.
У меня цифры практически противоположные, и это при чистом apache+mod_php (без nginx). Но я вообще ничего не готовлю, настройки дефолтные :)
В этом и дело. К тому же никто не говорит про дефолтные настройки ;)
В чём? :) А, вообще, я не админ, но вот приходится совмещать с тех пор как shared хостинга стало мало, а на managed (V)DS, а, тем более, штатного квалифицированного админа ещё не заработали. Играю настройками без особого понимания, что они дают :(
если nginx+php-fpm это такая панацея при больших нагрузках почему же тогда многие крупные проекты все-равно используют апач в качестве веб-сервера?
не знаю ) многих клиентов переводили с апача на такую связку — всегда только улучшение наблюдалось.
неудобство только в переписывании правил из .htaccess в nginx
неудобство только в переписывании правил из .htaccess в nginx
Многие готовые продукты заточены под Apache, в частности для них есть примеры конфигов и файлы .htaccess (последние к тому же позволяют производить конфигурацию, включая конфигурацию php на лету, без перезагрузки сервера). А вот конфигов для nginx в поставке обычно не бывает, а те что гуглятся далеко не всегда идеальны, да и вообще рабочие.
ZFS сам по себе память весьма любит, а вы ещё и MySQL с www-серверов громоздите в 4Гб?!
Будем знать про .htaccess, не знал что он может как то тормозить сервер
Когда давным давно делал тесты (тупо с помощью ab) мне не удалось заметить разницу (была в рамках погрешности). Разумеется влияние есть, но это уже стоить делать когда всё остальное пофиксено, а при времени генерации в 2-3 секунды, там еще пилить и пилить автору.
Кстати, если уж там мускул стоит, то не помешало-бы slow log начать писать и explain поделать, ну а всю остальное уже в комментариях озвучили.
этот момент я забыл описать. но стоит ли говорить об оптимизации долгих SQL запросов?
Все дело в их количестве, вложенности папок, сложности конфигурации в .htaccess и т.п.
Чем более глубоко запрятан файлик по папочкам — тем больше тормозит, ибо при AllowOverride All апач перечитывает ВСЕ файлы .htaccess по указаному пути.
Чем более глубоко запрятан файлик по папочкам — тем больше тормозит, ибо при AllowOverride All апач перечитывает ВСЕ файлы .htaccess по указаному пути.
Хех. Что ли о своих баталиях написать пост?) Со среднего времени генерации страницы в 3000-4000мс снизил чисто оптимизациями (без докупки железа) до 120-200мс и то 110мс отьедает запрос к стороннему геосервису. Список тэгов: постоянная инвалидация данных, геотаргетинг и временной таргетинг данных, 1 сервер, 500к показов в сутки.
Действуйте! я бы почитал.
Блин, конечно, пишите!
Очень интересно, так как есть несколько проектов, которые работают именно на отдачу контента и достаточно сильно нагружают сервер, готов поделиться решениями, которые были нами найдены и увидеть Ваши, я думаю всем будет это полезно.
было бы интересно прочитать
Но в моём случае это не прошло. Дело в том, что на сервере Ивана nginx выполняет роль легковесного фронтенда, а все файлы и запросы всё равно идут через apache.
Я записал себе в список дел настроить nginx раздавать статику напрямую. В этом посте я касаться этого не буду.Я даже не могу выразить всю бурю чувств, которые испытал, когда прочитал ЭТО. Бля, nginx берет видео от апача, кладет его на диск и меддленно отдает клиенту, а вы докупаете память. Вы феерический долбаеб. А еще отзовы «полезная статья, все по делу». Вы хоть iotop запускали, чтобы посмотреть кто что читает, а кто пишет с диска? Кто вас пустил «оптимизировать» сервер и кто те люди, кто это делал до вас?
Я записал себе в список дел настроить nginx раздавать статику напрямую. В этом посте я касаться этого не буду.Я даже не могу выразить всю бурю чувств, которые испытал, когда прочитал ЭТО. Бля, nginx берет видео от апача, кладет его на диск и меддленно отдает клиенту, а вы докупаете память. Вы феерический долбаеб. А еще отзовы «полезная статья, все по делу». Вы хоть iotop запускали, чтобы посмотреть кто что читает, а кто пишет с диска? Кто вас пустил «оптимизировать» сервер и кто те люди, кто это делал до вас?
Хабр съел blockquote.
айрони
Ну забил человек гвозди микроскопом, ну с кем не бывало.
/айрони
p.s. интересно, а статья «Как я исправил свои ошибки» у топикстартера будет или нет?
Ну забил человек гвозди микроскопом, ну с кем не бывало.
/айрони
p.s. интересно, а статья «Как я исправил свои ошибки» у топикстартера будет или нет?
Есть подозрение что про iotop автор не знает…
оскорблять не зная подробностей о ситуации — глупо.
в данном случае мне нужно было за ограниченный бюджет(=краткое время) настроить сервер.
перенастройка всего сервера с nginx + apache + mod_php в nginx + php не уложилась бы в бюджет
что такое iotop я знаю. видимо нужно было дописать об этом в статью.
многие работы ещё по настройке предстоит сделать.
в данном случае мне нужно было за ограниченный бюджет(=краткое время) настроить сервер.
перенастройка всего сервера с nginx + apache + mod_php в nginx + php не уложилась бы в бюджет
что такое iotop я знаю. видимо нужно было дописать об этом в статью.
многие работы ещё по настройке предстоит сделать.
в данном случае мне нужно было за ограниченный бюджет(=краткое время) настроить сервер.В данном слуае вам не нужно было о своем подвиге рассказвать в прличном месте.
перенастройка всего сервера с nginx + apache + mod_php в nginx + php не уложилась бы в бюджетВы феерический долбоеб в квадрате. Одна строчка конфига не уложилась бы в бюджет.
приведите мне одну строчку конфига, которая переведёт весь сервак с nginx + apache + mod_php на nginx + php и я признаю вашу правоту.
а иначе вы феерический дебил в кубе)
а иначе вы феерический дебил в кубе)
Я думаю, речь шла о том, что
говорит о несколько невысоком уровне квалификации, потому-что от главной проблемы тысячелетия (отдача килобайтной цсс несколькомегабайтным процессом апача) не избавились в первую очередь.
Я записал себе в список дел настроить nginx раздавать статику напрямую.
говорит о несколько невысоком уровне квалификации, потому-что от главной проблемы тысячелетия (отдача килобайтной цсс несколькомегабайтным процессом апача) не избавились в первую очередь.
Вам говорят о прямой раздаче видеофайлов через nginx, минуя апач. Это действительно стоило бы сделать в самую первую очередь, сэкономили бы процентов 80-90 памяти только этим.
я прекрасно понимаю что мне говорят. только это не одна строчка конфига.
а я бесплатно на заказчиков не работаю. это был обычный заказ на настройку с ограниченным временем и бюджетом.
а я бесплатно на заказчиков не работаю. это был обычный заказ на настройку с ограниченным временем и бюджетом.
Полчаса. Посмотреть на это и сказать: ещё оперативы.
В 200 рублей за консультацию уложились. Результат аналогичный.
Остальное за нормальные деньги и адекватные сроки.
В 200 рублей за консультацию уложились. Результат аналогичный.
Остальное за нормальные деньги и адекватные сроки.
за 200 рублей уважающий себя специалист даже смотреть не будет. а неуважающему себя сервер не доверят
Специалист???
Извините, я с замкадья. У нас 400 рублей в час — нормальная ставка.
Сколько у вас стоит полчаса работы специалиста по тонкой настройке сервера?
Это как раз то время, которое должно было у вас уйти перед согласованием бюджета. Посмотреть, что да как. И раз вы так себя уважаете, а предлагаемый бюджет мал, то: 200 рублей и расходитесь.
Сколько у вас стоит полчаса работы специалиста по тонкой настройке сервера?
Это как раз то время, которое должно было у вас уйти перед согласованием бюджета. Посмотреть, что да как. И раз вы так себя уважаете, а предлагаемый бюджет мал, то: 200 рублей и расходитесь.
Знаете… у нас 725 рублей в час — ставка работы наших админов на хостинге… ну в смысле, если клиент просит что то хитрое на своём сервере.
Я сейчас читаю автора и сам офигеваю хД В Москве работаю на одном из самых деньгокушательных хостингов (М9 и всё такое).
Я сейчас читаю автора и сам офигеваю хД В Москве работаю на одном из самых деньгокушательных хостингов (М9 и всё такое).
сурово у вас, в нашем чудесном городе Красноярске 500 рублей это час работы эникейщика (настроить adsl модем например). А знаете почему для вас 400 рублей это нормально? потому, что вы не цените свой же труд. За 400 рублей я сложнее чем adsl модем точно настраивать ничего не буду, а вы же даже 50 рублей настроить open vpn сервер.
p.s.
отдача статики это 1 строчка (3 строчки в случае если скобочки выносить на отдельные строчки) без тонкой настройки, или ~5 с подгонкой).
p.s.
отдача статики это 1 строчка (3 строчки в случае если скобочки выносить на отдельные строчки) без тонкой настройки, или ~5 с подгонкой).
Я рад за красноярских эникейщиков, зарабатывающих по 80 000 рублей в месяц.
Мне страшно представить, сколько стою я в Красноярске. Наверное нужно ездить в этот чудный город на заработки. Месяц поработал и год в Таиланде отдыхаешь.
Или фишка в том, что больше двух модемов в день не настроишь, за каждый вызов по 400 рублей, а оставшееся время в дороге?
Мне страшно представить, сколько стою я в Красноярске. Наверное нужно ездить в этот чудный город на заработки. Месяц поработал и год в Таиланде отдыхаешь.
Или фишка в том, что больше двух модемов в день не настроишь, за каждый вызов по 400 рублей, а оставшееся время в дороге?
расскажи мне об этом больше. В день они могут настроить около 5 модемов если на автобусе, и ~10 на машине. Итог: 2500-5000 в день при полной занятости. Средняя статистика заказов — 80 в месяц. Итого 3х эникейщиков достаточно, что бы все заказы выполнялись в течении 24 часов после поступления зявки.
> Мне страшно представить, сколько стою я в Красноярске.
Нисколько ты не стоишь. Ты же ничего не умеешь и не ценишь свой себя.
>Месяц поработал и год в Таиланде отдыхаешь.
Какое ограниченное мышление, конечно же Таиланд для тебя верх мечтаний.
> Мне страшно представить, сколько стою я в Красноярске.
Нисколько ты не стоишь. Ты же ничего не умеешь и не ценишь свой себя.
>Месяц поработал и год в Таиланде отдыхаешь.
Какое ограниченное мышление, конечно же Таиланд для тебя верх мечтаний.
То есть я идиот, что зарабатываю в месяц больше не тратя времени на всякие покатушки на автобусах и работая откуда хочу, при этом занимаясь более интересными делами, чем настройка модемов…
Удачи в настройке.
Попробуйте модемы уже настроенными привозить. Тогда хватит одного водителя и одного эникейщика.
Удачи в настройке.
Попробуйте модемы уже настроенными привозить. Тогда хватит одного водителя и одного эникейщика.
Внезпно! Я не занимаюсь настройкой модемов. А живу в Калифорнии и работаю тоже где хочу и когда хочу.
>Попробуйте модемы уже настроенными привозить. Тогда хватит одного водителя и одного эникейщика.
Не получится, эникейщик не знает данных до прибытия на место. А модем уже у клиента в 70% случаев.
>при этом занимаясь более интересными делами
не верю. скорее всего так же повторяющиеся действия и копипаст. Опять же эникейщик получает в час больше чем ты, что весьма забавно, а настройка модемов только одно из направления куда их можно направить.
>Попробуйте модемы уже настроенными привозить. Тогда хватит одного водителя и одного эникейщика.
Не получится, эникейщик не знает данных до прибытия на место. А модем уже у клиента в 70% случаев.
>при этом занимаясь более интересными делами
не верю. скорее всего так же повторяющиеся действия и копипаст. Опять же эникейщик получает в час больше чем ты, что весьма забавно, а настройка модемов только одно из направления куда их можно направить.
Ну я не знаю во сколько вы там оцениваете такую работу. Может и целой жизни не хватит статику на nginx перевести;) Зачем же статья на хабре о том, как вы сделали тривиальную операцию неверным образом?
Кстати, в вашем случае действительно одна строка — видео раздается без антилича. Вам ее ниже привели.
и я ниже ответил почему я этот ход не использовал.
Зачем мне так отвечать? Я ж не заказчик, которого вы на деньги разводите;)
У вас видеофайы без права на чтение, но при этом доступные напрямую по http?
У вас видеофайы без права на чтение, но при этом доступные напрямую по http?
их читает апач запущенный из-под пользователя владельца сайта. а нгикс из под nobody проксирует и отдаёт файлы
А как влияет на безопасность 644 права на flv, js, css, jpg, gif ну это вот первый вопрос который мне пришел в голову?
На мой вопрос вы из соображений безопасности не отвечаете?=)
Если у вас файлы доступны напрямую по http, то смысла убирать для них права на чтение любым пользователем нет потому, что любой пользователь их и так сможет прочитать по http. А значит можно сделать файлы доступными для чтения всем и запускать nginx из под любого пользователя и та одна строчка будет себе хорошо работать.
Если у вас файлы доступны напрямую по http, то смысла убирать для них права на чтение любым пользователем нет потому, что любой пользователь их и так сможет прочитать по http. А значит можно сделать файлы доступными для чтения всем и запускать nginx из под любого пользователя и та одна строчка будет себе хорошо работать.
на этот вопрос я ответил в другом комменте. кратко: если есть несколько пользователей и мы включим их в одну группу, то они начнут видеть все файлы друг друга
Так пользователей трогать вообще не надо. Почему бы не поставить просто файлам права на чтение всем, если их и так могут прочитать все?
rwxr--r-- на папку с видео и на сами ролики вполне достаточно. Владельцем файла при этом может быть любой пользователь.приведите мне одну строчку конфига, которая переведёт весь сервак с nginx + apache + mod_php на nginx + phpЯ что, сказал, что нужно все переводить на nginx + php? Вы еще и читать не умеете. Просто не нужно огромную статику гонять через жесткий диск. Это одна строчка:
location /video/ { root /home/feericheskiy-debil/www; }
Кстати, где мои 200 рублей?
вы ответили фразой про одну строчку конфига на мою фразу о перенастройке всего сервера.
если я дам nginx права на доступ к файлам в одной папке (изначально он работает из под nobody nogroup), а это значит мне или нужно давать права на файлы пользователю nobody или группе nogroup, что некошерно.
Или запускать nginx из под другого пользователя или группы, у которой есть права на пользовательскую папку.
Итог: нужно очень внимательно пересмотреть все права пользователей, чтобы не возникло дыры в безопасности.
При всём при этом есть ещё пара других пользователей, поэтому лучше решать проблему поэтапно, не размашивая шашкой…
Это совсем не 5 минут и не одна строчка конфига. Всё не так просто…
если я дам nginx права на доступ к файлам в одной папке (изначально он работает из под nobody nogroup), а это значит мне или нужно давать права на файлы пользователю nobody или группе nogroup, что некошерно.
Или запускать nginx из под другого пользователя или группы, у которой есть права на пользовательскую папку.
Итог: нужно очень внимательно пересмотреть все права пользователей, чтобы не возникло дыры в безопасности.
При всём при этом есть ещё пара других пользователей, поэтому лучше решать проблему поэтапно, не размашивая шашкой…
Это совсем не 5 минут и не одна строчка конфига. Всё не так просто…
А у вас там 400 права на файлы что-ли?
не могу сказать из соображенией безопасности
Не беспокойтесь, и так ясно как божий день, что вы обосрались.
А вот тут вы не правы, благодаря автору, я в шесть утра по новосибирскому времени еще не сплю :-) а беседую с умными людьми.
я решил задачу, а вы тратите своё время на повышение самооценки за счёт обсирания других. гениально!
Боюсь к обеду по Маскве, это будет как в истории с bolgenos: Простите. Я сделал это ради лулзов.
Проблему вы не решили. Вам выше дали дельные советы как стоит делать.
Esc, homm, alfa… читайте их камменты и делайте выводы.
Esc, homm, alfa… читайте их камменты и делайте выводы.
сервер работает быстро. проблема решена. будут деньги — донастрою всё остальное
Деньги, что платили другие пользователи сервера (которых не стало), тоже вернулись после проведенных работ?
пользователь unix это совсем не означает реальное физическое лицо
Ну да.
Насмотрятся ещё всякие демоны видях и восстание затеют.
Закрою-ка я тоже на своих серваках доступ им к развлекаьельному контенту.
Насмотрятся ещё всякие демоны видях и восстание затеют.
Закрою-ка я тоже на своих серваках доступ им к развлекаьельному контенту.
если хоть один из таких демонов взломают, то можно испортить всю систему. я осторожно отношусь к потенциальным дырам
Злобные хацкеры не смогут смотреть видео прямо с сервера. Жестоко! После этого, как я понимаю, они помрут со смеху и в этом ваш коварный план.
Да блин, это же уже даже не смешно! Ну признайтесь уже в своих ошибках или там недостатке знаний, никто-же не осудит. А то настоящий сенсей не должен так себя вести.
И да, хидеры картинок проще смотреть не на веб-сервисах а-ля be1.ru/stat/, а с помощью curl -I
И да, хидеры картинок проще смотреть не на веб-сервисах а-ля be1.ru/stat/, а с помощью curl -I
И жмот ваш Усачов.
Я тут вижу троих, кто за два дня гарантированно бы настроил всё, как нужно а не ноготки у воробьев подстригал.
Сколько стоит два дня работ… Ну 7 000 рублей.
Вроде и времени было у вас до появления оперативки столько-же.
Пожопить 7 000 рублей, когда у тебя страницы по 5 минут грузятся…
Да он на кликах по рекламе больше потерял.
Я тут вижу троих, кто за два дня гарантированно бы настроил всё, как нужно а не ноготки у воробьев подстригал.
Сколько стоит два дня работ… Ну 7 000 рублей.
Вроде и времени было у вас до появления оперативки столько-же.
Пожопить 7 000 рублей, когда у тебя страницы по 5 минут грузятся…
Да он на кликах по рекламе больше потерял.
Будут деньги — купите еще оперативы? Даю совет для феерического дебила — добить оперативки до 32Гб и засунуть в нее и кеш и своп. Оптимизация — это не для уважающих себя специалистов.
Чесно говоря, мне пофиг, что вы решили. Я разное повидал за время общения с собственными серверами организаций, которые решили что им недостаточно обычного хостинга или vds. Видел и 20 сайтов, конектящихся к мускулю под рутом, на котором нет пароля. И 10-и гигабайтный access лог без ротации со всей статикой, когда паралельно админ мне говорил, что у него место на серваке заканчивается. Что самое интересное, это все настраивали специалисты с полной ставкой, которые уважают себя и «за 200 рублей даже смотреть не будет».
Но когда вы, голубчик, лезете рассказвать о том, какой вы Д`Артаньян, как вы все круто настроили за «ограниченный бюджет», прикупив тонну дорогущего жлеза — извольте принять ушат говна на голову.
Но когда вы, голубчик, лезете рассказвать о том, какой вы Д`Артаньян, как вы все круто настроили за «ограниченный бюджет», прикупив тонну дорогущего жлеза — извольте принять ушат говна на голову.
2 планки памяти — это не тонна.
И я и не говорю, что я д.Артаньян.
Я поделился опытом, а вы вместо конструктивной критики начали гавно разводить.
Я извлёк и из этого плюс. Хоть мне и не платили за дальнейшую настройку сервера я проверил все права, убедился что всё ок, и заставил nginx отдавать статику напрямую. изменения внесены в статью
И я и не говорю, что я д.Артаньян.
Я поделился опытом, а вы вместо конструктивной критики начали гавно разводить.
Я извлёк и из этого плюс. Хоть мне и не платили за дальнейшую настройку сервера я проверил все права, убедился что всё ок, и заставил nginx отдавать статику напрямую. изменения внесены в статью
Ну слава богу, не зря я вас изводил.
а вот это возмутительно.
вы вносите правки в статью, не отмечая что это правки. в итоге, контент изменился, благодаря комментаторам, статья не выглядит такой провальной, авторы комментариев, которые оказали вам большую помощь, никак не отмечены.
вообще адекватные люди не правят текст статьи, а пишут внизу UPD и указывают какой комментатор и что здравое написал. так как вы поступили — как минимум неэтично.
вы вносите правки в статью, не отмечая что это правки. в итоге, контент изменился, благодаря комментаторам, статья не выглядит такой провальной, авторы комментариев, которые оказали вам большую помощь, никак не отмечены.
вообще адекватные люди не правят текст статьи, а пишут внизу UPD и указывают какой комментатор и что здравое написал. так как вы поступили — как минимум неэтично.
вообще-то написал одному злостному комментатору.
он порадовался тому, что его разборки дали результат. так что никто не пострадал.
цель статьи — дать информацию другим. хорошую.
поэтому пусть сразу читают как делать правильно. а подробности все есть в комментах.
он порадовался тому, что его разборки дали результат. так что никто не пострадал.
цель статьи — дать информацию другим. хорошую.
поэтому пусть сразу читают как делать правильно. а подробности все есть в комментах.
Вы, кстати, не правильно написали в топике, нужно было пользоваться копи-пастом.
Директива root указывает, где лежит корневая папка для данного запроса. Т.к. у вас уже location равен /video/, то файл /video/1.flv будет искаться по адресу ochevidets.ru/video/video/1.flv.
Об этом написано в справке nginx. Вы бы знали, если бы читали её.
location /video/ {
root /home/ochev/html/ochevidets.ru/video/;
}Директива root указывает, где лежит корневая папка для данного запроса. Т.к. у вас уже location равен /video/, то файл /video/1.flv будет искаться по адресу ochevidets.ru/video/video/1.flv.
Об этом написано в справке nginx. Вы бы знали, если бы читали её.
Дать права на чтение ведеофайла группе nobody это жутко некошерно.
Права пользователей должны быть более ущемлены, чем права веб-пользователей. Это брутально.
Права пользователей должны быть более ущемлены, чем права веб-пользователей. Это брутально.
Как, правда, серьезно? Вы не можете дать всем права на чтение публичных файлов, которые раздаются любому ананимусу по протоколу http? О-хо-хо.
Или вам просто страшно признать, что вы выбрали не ту профессию?
Или вам просто страшно признать, что вы выбрали не ту профессию?
в рамках хостинга если дать права на чтение всем файлов всех, то туда попадёт многое из того, что не нужно видеть другим
Это видно и так всем! не только тем. кто на сервере, но вообще всем по http! Если там и есть что-то, что не нужно видеть другим, то его все равно видно.
Зачем всех файлов? Вас никто не просит скрипты давать читать всем желающим.
И вроде рамки единственного юзверя на сервере, если не всю статью позабыл.
И вроде рамки единственного юзверя на сервере, если не всю статью позабыл.
1) вроде как у вас уже свой выделенный сервер стал а не хостинг?
2) не обязательно всем файлам давать одинаковые права. Ставьте php скриптам 600 а видео и статике 644
2) не обязательно всем файлам давать одинаковые права. Ставьте php скриптам 600 а видео и статике 644
вообще знаешь, мне страшно. 69 человек добавили в избранное, плюсуют.
года 3 назад слили бы со свистом такой материал. и автора в придачу.
года 3 назад слили бы со свистом такой материал. и автора в придачу.
Вы бы поинтересовались для чего взялись правила с www
Убедились бы, что оно срабатывает в одном случае из 1000, если все остальное в норме. (То есть пользователя (не каждого) редиректнет при первом посещении, а дальше в ссылках, адресах картинок, и т.п. всегда будет www и никаких больше переадресаций).
А то, что было сломал и оптимизации пшик поимел…
Убедились бы, что оно срабатывает в одном случае из 1000, если все остальное в норме. (То есть пользователя (не каждого) редиректнет при первом посещении, а дальше в ссылках, адресах картинок, и т.п. всегда будет www и никаких больше переадресаций).
А то, что было сломал и оптимизации пшик поимел…
если у вас 2-3 секунды генерируется страница, то это, простите, ппц.
реально повлияло на скорость добавление памяти и то, что превьюшки больше не создаются при каждой загрузке страницы (ОМГ!!!).
Я думаю если бы вы не делали остального, результат получился бы примерно тот же.
реально повлияло на скорость добавление памяти и то, что превьюшки больше не создаются при каждой загрузке страницы (ОМГ!!!).
Я думаю если бы вы не делали остального, результат получился бы примерно тот же.
Кстати, про превьюшки, а почему так мало народа использует ngx_http_image_filter_module? Почему-то программисты считают ресайз своей прерогативой :-) (когда можно будет накладывать варермарки, nginx отберет у них последний аргумент).
Мое мнение — делать ресайз картинок (блокирующая, ресурсоемкая операция) в асинхронном сервере — неправильный подход.
Ну в теории, если контента много, а вариантов превьюх тоже много, то не создавая сразу стотыщьмиллионов картинок, а создавая их первых раз по запросу мы можем поберечь свои ресурсы.
Хотя, на одном из проектов, когда умер диск с превьюхами, то бот images.yandex.ru прошедший по всему архиву систему нагрузил, да.
Хотя, на одном из проектов, когда умер диск с превьюхами, то бот images.yandex.ru прошедший по всему архиву систему нагрузил, да.
Можно сделать что то в стиле
try_files $uri @image_resizer
а в @image_resizer уже запрос к какому то внешнему ресайзеру (апач, PHP etc)
Просто Nginx это в первую очередь асинхронный прокси — сервер. Так что если его загружать ресайзом картинок, то асинхронный поток может часто блокироваться… А плодить много воркеров для Nginx не принято. Если заняты все бекенды (апачи, php-fcgi) то это в общем то штатная ситуация, а если заняты все воркеры Nginx…
try_files $uri @image_resizer
а в @image_resizer уже запрос к какому то внешнему ресайзеру (апач, PHP etc)
Просто Nginx это в первую очередь асинхронный прокси — сервер. Так что если его загружать ресайзом картинок, то асинхронный поток может часто блокироваться… А плодить много воркеров для Nginx не принято. Если заняты все бекенды (апачи, php-fcgi) то это в общем то штатная ситуация, а если заняты все воркеры Nginx…
Я не думаю, что Игорь писал бы модуль делающий всё то-же самое, что phpшный ресайззер, только «долго, дорого и х… во» :-) В обычной работе я проблем не видел с нагрузкой, хотя конечно нужны нормальные тесты.
Да, согласен. Возможно, в принципе, что там ресайз идет в отдельном потоке либо он какой то хитрый потоковый. Нужны тесты.
Ну поиск по рассылке на www.lexa.ru/nginx-ru/ не показал проблемы, это не значит, что её нет, но уже о чём-то говорит. Попробую на выходных тесты сделать.
sysoev.ru/nginx/
Nginx заявляет ресайз картинок как одну из своих ключевых возможностей
Nginx заявляет ресайз картинок как одну из своих ключевых возможностей
Основная функциональность HTTP-сервера:
да ладно. 1 раз сконвертить картинку и 1к раз показать куда проще чем 1к раз сконвертить ее и тем самым тратить процессорное время и отвлекать воркеры.
немного не понял про «1к сконвертить», при image_filter + try_files?
картинки то налету генерятся. лучше сконвертить в нужный размер 1 раз и потом отдавать. без всяких преобразований на лету.
Что такое «на лету» в вашем понимании?
Допустим, сервис имеет 4 размера превьюшек. Что быстрее, аплоад и показ какой-то одной (на странице загрузки) или вообще никакой (если там тупо ОК пишется), чем аплоад и создание этих четырех превьюх, одна из которых (для каких-нить экранов мобильных) запрошена будет вообще не скоро. Я конечно описал очень частный случай, но всё-же.
Допустим, сервис имеет 4 размера превьюшек. Что быстрее, аплоад и показ какой-то одной (на странице загрузки) или вообще никакой (если там тупо ОК пишется), чем аплоад и создание этих четырех превьюх, одна из которых (для каких-нить экранов мобильных) запрошена будет вообще не скоро. Я конечно описал очень частный случай, но всё-же.
Как я понял там имеется в виду превьюшка видео, т.е. из видео вырезается случайный (или определенный) кадр и отдается как превьюшка.
Хотя могу ошибаться.
Хотя могу ошибаться.
это не генерируется, а загружается на комп клиента
кхм.
для улучшения времени загрузки на комп клиента обычно работают над всякими вещами, вроде css-спрайтов, объединением и сжатием js-файлов и тд.
вы же работали над серверными вещами, которые измеряться, как мне кажется, должны временем генерации страницы.
для улучшения времени загрузки на комп клиента обычно работают над всякими вещами, вроде css-спрайтов, объединением и сжатием js-файлов и тд.
вы же работали над серверными вещами, которые измеряться, как мне кажется, должны временем генерации страницы.
специфика этого проекта в тяжёлых видеофайлах. время генерации малое. страницы довольно простые
Еще раз, для студентов. На неасинхронной загрузке рекламы ровно половина тормозов.
какой рекламы?
ессли про директ или адсенс, то их ускорить равно как и отказатьсяя не в моей компетенции
ессли про директ или адсенс, то их ускорить равно как и отказатьсяя не в моей компетенции
Может их загружать после отрисовки страцицы…
А то с падением бегуна на чудосайте вообще ничего увидеть нельзя будет.
А то с падением бегуна на чудосайте вообще ничего увидеть нельзя будет.
есть варианты с загрузкой рекламных кодов в самом конце.
вот вам статейка.
ivanov.in/mixmarket/avoid-slow-js-2/
вот вам статейка.
ivanov.in/mixmarket/avoid-slow-js-2/
В общем как в том анекдоте про пьянку…
А потом я отравился печенюшкой а потом привезли оперативки и все заработало.
За час-два можно было убрать апач к чертям и на этом закончить.
За час-два можно было убрать апач к чертям и на этом закончить.
Но учитывая то, что при обычном просмотре каталогов из 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
Для владельцев сайта:
Сайт перегружен или заблокирован.
Звоните: +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?
Это адаптековская фишка. И ssd продаётся в комплекте специальный.
Мне нужны конкретные модели дисков и контроллеров, их пропускная способность. Может 3Ware 6Гб с SAS дисками будет дешевле, быстрее и масштабируемее, чем этот adaptec.
Хотя я 100% не стал бы использовать их контроллеры :)
Хотя я 100% не стал бы использовать их контроллеры :)
Ого, у нас уже ведущие занимаются проблемами быстродействия сайта
Продолжим за оптимизацию.
Зачем в БД отдельная ячейка для превью.
Вроде всю жизнь хватало структуры папок и единственного имени файла в БД.
Зачем в БД отдельная ячейка для превью.
Вроде всю жизнь хватало структуры папок и единственного имени файла в БД.
Добавлю свою лепту…
— стоит избавится от апача вообще, настроить nginx через spawn-cgi, зачем лишние ресурсы тратить
— статику раздавать через другой порт, на котором будет висеть squid, как кеширующий прокси, у которого будет выделено несколько гигов оперативки под кеш мелких файлов (например до 15-20мб), при правильной настройке в кеше будут сидеть в основном превьюшки и самые популярные ролики, таким образом жестко уменьшаем соличество операций с диском
— ничего не было сказано про кеширование опкода, поэтому стоит проверить используется там какой-либо оптимизатор (в последнее время пользуюсь APC)
— стоит избавится от апача вообще, настроить nginx через spawn-cgi, зачем лишние ресурсы тратить
— статику раздавать через другой порт, на котором будет висеть squid, как кеширующий прокси, у которого будет выделено несколько гигов оперативки под кеш мелких файлов (например до 15-20мб), при правильной настройке в кеше будут сидеть в основном превьюшки и самые популярные ролики, таким образом жестко уменьшаем соличество операций с диском
— ничего не было сказано про кеширование опкода, поэтому стоит проверить используется там какой-либо оптимизатор (в последнее время пользуюсь APC)
Напишите, пожалуйста, подробнее про второй пункт (другой порт и squid). Довольно интересно решение. Как по-вашему, насколько оно лучше кэширования статики средствами nginx?
По-поводу сквида надо целую статью писать, но суть в том, что проски это основная его задача, поэтому он намного гибче в настройке чем nginx или lighttpd
Не вижу, в чём должно проявлятся преимущество его гибкости для простой задачи кеширования всех файлов.
Другими словами, по прежнему неясно, чем здесь squid будет лучше nginx
Другими словами, по прежнему неясно, чем здесь squid будет лучше nginx
Когда объем файлов на 2-3 порядка превышает максимально возможный объем оперативной памяти которую является возможным выделить под кеш, то задача эффективного кеширования уже не такая простая. Вероятность попадания в кеш в дефолтном режиме порядка 5%-10%, что не является сколь-либо приемлемым результатом, после некоторых оптимизаций(путём подбирания настроек) удалось поднять эту цифру до порядка 70-75%.
Контетном было порядка 80,000 видеофайлов общим размером ~3.5Тб + по 3 картинки на каждое.
Контетном было порядка 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.
кеширование производилось в RAM и отдельный винт (HDD), хранилище данных 4х1,5Tb RAID5
— картинки с возрастом не более недели в RAM, на несколько дней (точно не помню на сколько)
— видео с возрастом не более суток и размером не более 20Мб в RAM, ttl 12часов (свежак появлялся на главной и был самым востребуемым)
— видео которое смотрели несколько раз (>= 3) размером в HDD (часто всплывало
несвежее видео которое рассылается всему контакт листу какого-либо), ttl 12ч
— шейпинг скорости отдачи видео с RAID-массива на уровне 4Мбит, т.к. часто смотрели большое видео которое в кеш не попадало
Под кеш выделялось всего 2Gb оперативки, и 30Gb HDD.
>видео которое смотрели несколько раз (>= 3) размером в HDD
размером до 50Мб
размером до 50Мб
И всё же заметкой это было бы интересно.
P.S. Кстати, никогда не понимал, зачем использовать RAID5 на конфигурации из 4 винтов. RAID10 для них будет существенно быстрее и надёжнее на «половину HDD». А уж потерей пространства с нынешними ценами за гигабайт можно просто пренебречь и купить ещё пару винтов.
P.S. Кстати, никогда не понимал, зачем использовать RAID5 на конфигурации из 4 винтов. RAID10 для них будет существенно быстрее и надёжнее на «половину HDD». А уж потерей пространства с нынешними ценами за гигабайт можно просто пренебречь и купить ещё пару винтов.
что за панацея с cgi у всех?
нет никакого прироста скорости у всех типов cgi. php_fpm ещё как то экономит память, но не время.
это миф, который распространяют те, кто вообще не пытался настроить mod_php. Он вполне быстр, если не использовать дефолтный конфиг.
нет никакого прироста скорости у всех типов cgi. php_fpm ещё как то экономит память, но не время.
это миф, который распространяют те, кто вообще не пытался настроить mod_php. Он вполне быстр, если не использовать дефолтный конфиг.
Об оптимизации скорости отрабатывания php вообще речь не шла ни в комментах, ни в «статье».
Так что причем тут ваш прирост скорости…
Так что причем тут ваш прирост скорости…
widowmaker предлагает избавиться от mod_php в сторону fcgi и ему подобных механизмов. я к этому.
Практика же показывает, что в очень многих случаях никакого прироста ни в чём это не даст.
И не нужно говорить о том, что «в cgi меньше времени тратится на инициализацию». Для любого более или менее современного процессора, это такие копейки, что на них оглядываться не стоит.
Время на компиляцию php на современных процах уже давно пришло к чему то вроде «0.0хх секунд». Так что, если сайт не написан изначально с использованием фич 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
К тому же у меня есть обратный опыт, при большом наплыве посетителей на слабой машине, когда nginx ждал каждого ответа от апача по 30+ секунд, статика летала будь здоров. Да и вроде нагрузка между воркерами апача была равномерной, хотя их количество было 7, а nginx — 2.
Кстати, могу даже картинку приложить:
Это я искуственно сделал ab -n 1000 -c 20
epoll/kqeue вам на что?
Да и не будет воркер ничего ждать. Воркеры — многопоточны. Затык будет только тогда, когда буду заняты все чайлды — пользователь увидит Bad Gateway, если вы всё правильно настраивали.
А вот время занятости чайлдов апача нужно снижать, да.
Да и не будет воркер ничего ждать. Воркеры — многопоточны. Затык будет только тогда, когда буду заняты все чайлды — пользователь увидит Bad Gateway, если вы всё правильно настраивали.
А вот время занятости чайлдов апача нужно снижать, да.
Расскажите о правильной настройке mod_php плз.
80% io? и вы ещё стали ковырять nginx… кхе кхе.
Приятно когда приходит клиент с полностью убитым сервером и настройками «как заработало» — тогда любые найденные в гугле фишки убыстряют, особенно когда память в несколько раз подняли :)
На сайте этом ни одно видео не работает, флв файл не находит
Я не любитель давать людям заочные оценки, но автор поступает как очень неумный и недальновидный человек, поправив изначальную статью без указания на авторов людей, которые в комментариях топикстартеру и разжевали всё, и в рот положили.
Я не делал diff c первоначальной публикацией, но
текущий текст:
разительно отличается от первоначального:
Хотя автор просто не разобрались в плёвой проблеме, пока его не ткнули носом в конкретную ссылку.
Не говоря уж о добавленных впоследствии записях о slow log мускула и прочих.
Хреново поступаете «уважаемый».
Я не делал diff c первоначальной публикацией, но
текущий текст:
Но ещё лучше заставить nginx отдавать статику напрямую. Например так:
разительно отличается от первоначального:
Я записал себе в список дел настроить nginx раздавать статику напрямую. В этом посте я касаться этого не буду.
Хотя автор просто не разобрались в плёвой проблеме, пока его не ткнули носом в конкретную ссылку.
Не говоря уж о добавленных впоследствии записях о slow log мускула и прочих.
Хреново поступаете «уважаемый».
я уже говорил о том, что если бы главный критикующий общался бы без мата, то я дал бы на него ссылку.
кроме того я говорил об ограниченном времени и бюджете из-за которых все нужные настройки не были сделаны сразу.
Я прекрасно понимал эти замечания ещё до того как они были написаны. И даже говорил об этом в посте. В итоге меня вынудили сделать часть того что я планировал сделать позже делать ночью.
А насчёт slow — об этом был вопрос в комментах и я вспомнил соотвествующие детали.
Если статья изменяется и информация всё время остаётся актуальной — это очень хорошо.
кроме того я говорил об ограниченном времени и бюджете из-за которых все нужные настройки не были сделаны сразу.
Я прекрасно понимал эти замечания ещё до того как они были написаны. И даже говорил об этом в посте. В итоге меня вынудили сделать часть того что я планировал сделать позже делать ночью.
А насчёт slow — об этом был вопрос в комментах и я вспомнил соотвествующие детали.
Если статья изменяется и информация всё время остаётся актуальной — это очень хорошо.
Главный критикующий дал вам ценные советы, которые вы применили. Неумение признавать критику это очень печально.
Вы правда не понимаете разницу поправить статью на актуальную (там параметр в конфиге забытый какой-нибудь) или написать ахинею на 50%, расписаться в своём не профессионализме, а потом выехать за счёт дельных советов, в том числе, «главного критикующего»? Впрочем можете не отвечать, ответы и так понятны будут тем, кто осилит прочитать ветку.
Если статья изменяется и информация всё время остаётся актуальной — это очень хорошо.
Вы правда не понимаете разницу поправить статью на актуальную (там параметр в конфиге забытый какой-нибудь) или написать ахинею на 50%, расписаться в своём не профессионализме, а потом выехать за счёт дельных советов, в том числе, «главного критикующего»? Впрочем можете не отвечать, ответы и так понятны будут тем, кто осилит прочитать ветку.
кроме того я говорил об ограниченном времени и бюджете из-за которых все нужные настройки не были сделаны сразу.Ну зачем вы повторяетесь, я вам уже отвечал — единственная нужная настройка, которая бы снизила io в 3-4 раза, не требует ни времени ни бюджета.
а я уже говорил, что на тот момент у меня не было времени продумывать систему прав. и к тому же со мной за то что я сделал ещё полностью не рассчитались. зачем работать бесплатно?
Напоминает:
За такую зарплату нужно не только не работать, а еще немножечко вредить!
Вы продолжаете нести феерический бред. Неполностью заплатили? Вам заплатили за комментиирование строчек с редиректом? Вот это можно было не делать, а сделать раздачу видео nginx, по времени столько же выходит. Меня ваши работы и оплата вообще не касаются, я обсуждаю статью.
«Продумывать систему прав» — это что? Вам было сложно продумать, какие права должны быть на файл, чтобы его смог читать nobody? Вам даже это, кстати, ражевали в комментариях. Вы даже это не сообразили сами.
«Продумывать систему прав» — это что? Вам было сложно продумать, какие права должны быть на файл, чтобы его смог читать nobody? Вам даже это, кстати, ражевали в комментариях. Вы даже это не сообразили сами.
ну тогда и коменты обсуждай. у любого поступка есть основания. которые я объяснил.
я сделал и много другого, что не вошло в статью.
и вообще, если ты легкомысленен в вопросах прав пользователей, то я не должен быть таким.
а если обидно, что я тебя не удостоил ссылки — общайся нормально, без мата
я сделал и много другого, что не вошло в статью.
и вообще, если ты легкомысленен в вопросах прав пользователей, то я не должен быть таким.
а если обидно, что я тебя не удостоил ссылки — общайся нормально, без мата
Вы просто не в теме как работают права на файлах/директориях, признайтесь уж.
Это видно уже по вашему ответу:
Как по вашему работают хостинги с фронтендами?
И сильно улыбнуло обвинение homm в заботах о упоминании в «статье».
Это видно уже по вашему ответу:
не могу сказать из соображенией безопасности
Как по вашему работают хостинги с фронтендами?
И сильно улыбнуло обвинение homm в заботах о упоминании в «статье».
в теме. я админю сервера уже 12 лет. и поэтому я стараюсь глубоко продумывать каждый шаг в этой сфере и не совершать легкомысленных телодвижений.
я админю сервера уже 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)
Я вижу проблему в последнем запросе, как заказчик созреет — буду оптимизировать
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 (правда сейчас не час пик).
Не много ли памяти это займёт?
а стоит ли ставить такое большое число?
Ведь запущенных всего 2 (правда сейчас не час пик).
Не много ли памяти это займёт?
У него чуть меньше двух гетов в секнду, зачем ему 32 треда.
да, теперь слабым местом субд остается.
судя по всему, надо настраивать max_user_connections, max_connections и thread_cache_size
Простое тестирование одной и той же страницы ложит сервер БД.
судя по всему, надо настраивать 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 с кеширование в файлы, незачем нагружать программиста )))
Добавлю момент, всё-же стоит читать комментарии перед тем как писать, там много интересного есть, например, вот эта веточка: habrahabr.ru/blogs/webdev/109191/#comment_3464727
кстати, а скруглять уголки может?
Осилил… Редиректы зря убрали все-таки. Ни разу не слышал, что они могут хоть сколько-нибудь ощутимо нагружать сервер.
Так задача всегда не сервер разгрузить, а клиентов ускорить.
они вызывались на всех картинках, которых на странице 30-40 (включая элементы дизайна)
Элементы дизайна должны быть прописаны в css. В любом случае поставьте редирект и посмотрите насколько измениться время загрузки. Я не думаю, что там будет ощутимая разница. Без редиректа другие проблемы вылезут, о которых уже писали выше.
Я правильно понимаю, что у вас там все пути абсолютные, да еще и не на тот домен?
Вставлю свои пару копеек:
— с этим gzip_types text/html nginx, вероятно, не стартанет из-за ошибки, ибо этот тип есть по дефолту в конфигурации, описывать его не надо.
— при отдаче flv не надо ограничивать скорость и количество потоков, это я понял по своему проекту, диск от ограничения скорости умирает намного быстрее и хуже, если этих потоков достаточно много (лучше быстрее отдать клиенту, чем занимать память кеша или постоянно по чуть-чуть читать с диска), если есть ограничения потоков — будут постоянные ошибки при просмотре flv в плеере, он не всегда правильно закрывает коннект во время seeking, в итоге — пару раз перемотал и получил 503.
А вообще, в таком деле память решает все, у меня на сервере 14 гигов оперативки и 4 ядра, а и он с легкостью раздает 600 мбит видеопотока и обычного файла. Хотя у меня настройки в nginx получше ваших :)
— с этим gzip_types text/html nginx, вероятно, не стартанет из-за ошибки, ибо этот тип есть по дефолту в конфигурации, описывать его не надо.
— при отдаче flv не надо ограничивать скорость и количество потоков, это я понял по своему проекту, диск от ограничения скорости умирает намного быстрее и хуже, если этих потоков достаточно много (лучше быстрее отдать клиенту, чем занимать память кеша или постоянно по чуть-чуть читать с диска), если есть ограничения потоков — будут постоянные ошибки при просмотре flv в плеере, он не всегда правильно закрывает коннект во время seeking, в итоге — пару раз перемотал и получил 503.
А вообще, в таком деле память решает все, у меня на сервере 14 гигов оперативки и 4 ядра, а и он с легкостью раздает 600 мбит видеопотока и обычного файла. Хотя у меня настройки в nginx получше ваших :)
вот что бывает если школьники делают такой сайт. Серьёзно, order by rand(), неправильная ссылка на картинки без «www», отсутствие простейшего кэширования прьевьюшек — умный разработчик себе такого бы не позволил.
«В бд завести отдельную ячейку для превью» — зачем? Можно и так хранить в виде файла в отдельной папке, но с тем же именем.
Не озвучен размер базы, без этого не понятно, нужна ли была RAM или нет.
«В бд завести отдельную ячейку для превью» — зачем? Можно и так хранить в виде файла в отдельной папке, но с тем же именем.
Не озвучен размер базы, без этого не понятно, нужна ли была RAM или нет.
И раз уже асфальтоукладочным катком проехались…
p8.inetstar.ru/.svn/entries
hbk.inetstar.ru/.svn/entries
p8.inetstar.ru/phpmyadmin/
Тут видимо были попытки закрыть) hbk.inetstar.ru/.svn/text-base/.htaccess.svn-base
Но они зафейлились.
hbk.inetstar.ru/.svn/text-base/cleaner.php.svn-base
Фееричненько
p8.inetstar.ru/.svn/entries
hbk.inetstar.ru/.svn/entries
p8.inetstar.ru/phpmyadmin/
Тут видимо были попытки закрыть) hbk.inetstar.ru/.svn/text-base/.htaccess.svn-base
Но они зафейлились.
hbk.inetstar.ru/.svn/text-base/cleaner.php.svn-base
Фееричненько
Мелочь конечно, но можно так написать
server_name .ochevidets.ru;Вот еще: отключаем gzip для IE6
gzip_disable msie6;Можете объяснить, зачем это нужно? Будут ли данные сжиматься, зависит от того, что послал клиент в заголовке Accept-Encoding, а не от его юзер-агента.
Видимо, ha2bj о проблеме сжатия http в ie6. При этом в заголовках http от браузера есть поддержка сжатия, но ошибка при обработке сжатого контента возникает.
По идее, все модули сжатия (для apache, nginx и для CMS) учитывают эту особенность. Но директива «gzip_disable msie6» всё равно отдельно есть.
По идее, все модули сжатия (для apache, nginx и для CMS) учитывают эту особенность. Но директива «gzip_disable msie6» всё равно отдельно есть.
резюмирую статью:
у меня был сервер, он тормозил. я в 5 раз увеличил количество памяти, и провёл тонкую настройку gzip-буферов у nginx.
теперь всё работает быстро — вот чего можно добиться с помощью тонкой настройки!
у меня был сервер, он тормозил. я в 5 раз увеличил количество памяти, и провёл тонкую настройку gzip-буферов у nginx.
теперь всё работает быстро — вот чего можно добиться с помощью тонкой настройки!
Даже такое, казалось бы простое, решение нужно уметь принять. Если бы после установки памяти всё осталось бы в тормозящем состоянии, то мне пришлось бы заказчику деньги за память из собственного кармана возвращать.
Проблема могла быть вполне в динамической генерации превью или в БД или старых винтах.
Есть притча как изобретатель за удар кувалдой получил 1000 долларов. Так вот тут из этой же серии.
И поскольку я не был на 100% уверен, что новая память переломит ситуацию (всё таки роликов сотни гигабайт, а памяти всего добавил 8, и явно они все в кеш не войдут), то я оптимизировал всё что было возможно в рамках отпущенного времени и бюджета.
Проблема могла быть вполне в динамической генерации превью или в БД или старых винтах.
Есть притча как изобретатель за удар кувалдой получил 1000 долларов. Так вот тут из этой же серии.
И поскольку я не был на 100% уверен, что новая память переломит ситуацию (всё таки роликов сотни гигабайт, а памяти всего добавил 8, и явно они все в кеш не войдут), то я оптимизировал всё что было возможно в рамках отпущенного времени и бюджета.
У меня был сервер в нете
Малость тормозил
Попросил Серегу сделать
Он его убил.
(с) Иван Усачев.
Малость тормозил
Попросил Серегу сделать
Он его убил.
(с) Иван Усачев.
коенчно увеличение памяти с 2 до 10 решает многие проблемы.
Еще лучше освободиться от апача напрочь и навсегда.
видео сам бог велел отдавать энджиниксом
и только дураки могли додуматься видео отдавать скриптом (из текста я понял что жто так и было).
что касается мускуля, то ели Вы проектируете высоконагрузочный сервис,
то забываем про джоины. Либо производительность, либо деноморолизация.
Отсюда и память занимаемая мускулем уменьшиться.
а в целом автору зачет, спас проект — спасибо.
Еще лучше освободиться от апача напрочь и навсегда.
видео сам бог велел отдавать энджиниксом
и только дураки могли додуматься видео отдавать скриптом (из текста я понял что жто так и было).
что касается мускуля, то ели Вы проектируете высоконагрузочный сервис,
то забываем про джоины. Либо производительность, либо деноморолизация.
Отсюда и память занимаемая мускулем уменьшиться.
а в целом автору зачет, спас проект — спасибо.
скриптом там делались превьюшки из больших фоток. а видео изначально отдавал апач через нгинкс.
к слову говоря: мне кажется что эта проблема с джойнами — это фишка mysql. неужели у оракла тоже 2 запроса работают быстрее, чем один?
к слову говоря: мне кажется что эта проблема с джойнами — это фишка mysql. неужели у оракла тоже 2 запроса работают быстрее, чем один?
я с Oracle не работал лет эдак 7…
по этому как там и что спорить не буду.
что касалось превьюшек фото — а нельзя ли их было на генерировать заранее столько,
сколько нужно?
сейчас работаю над фотохостингом, собираемся размещать миллионы фотографий (пока ТЗ на 5-ть),
соответственно будем показывать слайдером превьюшки по темам. Все превьюшки будут сгенерены заранее, можно сказать почти сразу после загрузки, но, ВНИМАМИЕ! не путать — со [b]скриптом загрузки[/b].
Грузить вообще будет энджиникс upload_module + upload_progress_module, а потом будет запускаться бэдграундный скрипт конвертации.
по этому как там и что спорить не буду.
что касалось превьюшек фото — а нельзя ли их было на генерировать заранее столько,
сколько нужно?
сейчас работаю над фотохостингом, собираемся размещать миллионы фотографий (пока ТЗ на 5-ть),
соответственно будем показывать слайдером превьюшки по темам. Все превьюшки будут сгенерены заранее, можно сказать почти сразу после загрузки, но, ВНИМАМИЕ! не путать — со [b]скриптом загрузки[/b].
Грузить вообще будет энджиникс upload_module + upload_progress_module, а потом будет запускаться бэдграундный скрипт конвертации.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тормозит веб-сервер. Настройка на примере www.ochevidets.ru