- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
вот убийца диска
почему? где вы начитались подобной глупости?
myhand, яб сказал не начитался, а напрактиковался, при раздачи mp3 и прочего мультимедийного контента всегда наблюдал wa в полку при sendfile on, а почему вы считаете, что это глупость?
почему? где вы начитались подобной глупости?
Вижу предупреждение.
sendfile(). Без ограничения, одно быстрое соединение может целиком захватить рабочий процесс.
хотя я думаю. это больше к CPU
http://nginx.org/ru/docs/http/ngx_http_core_module.html#sendfile
почему вы считаете, что это глупость?
Потому что я знаю что делает и для чего предназначен sendfile. Я бы покрутил его сперва, чем отключать (напр. sendfile_max_chunk).
А еще обращайте внимание на контекст опций. Отключать sendfile глобально - глупо в 99.9999%.
Отключать sendfile глобально - глупо в 99.9999%.
что глупо, так это заявлять такое, рассмотрим ситуацию когда контент отдаётся с ограничением скорости, в контексте sendfile осуществляется не буферизированный вывод, что усугубляет отдачу данных большому количеству подключений, а при использование aio на linux, sendfile так вообще отключается автоматически.
рассмотрим ситуацию когда контент отдаётся с ограничением скорости
Вы что, *весь* контент отдаете с ограничением скорости? Бакенд тупил-тупил - а вы и дальше вывод php-скрипта по байту цедить будете?
в контексте sendfile осуществляется не буферизированный вывод, что усугубляет отдачу данных большому количеству подключений
Что вы имеете в виду под "не буферизованным выводом" - и как это автоматически может усугублять отдачу данных большому числу подключений?
Вы точно уже прочитали man sendfile?
а при использование aio на linux, sendfile так вообще отключается автоматически.
Еще глупость. Дело не в sendfile, а в O_DIRECT (опция directio).
Ситуация сильно не меняется. Увеличил proxy_buffers 64 8k;
Вот конф.файл домена с mp3
limit_zone one $binary_remote_addr 10m;
server {
listen ip:80;
server_name domen.ru;
error_page 418 = @nolimit;
error_page 503 /503.html;
location ~* ^.+\.(mp3)$ {
proxy_pass http://ip:8080;
root ....;
if ( $http_user_agent ~* (Google|Rambler|Aport|Mail|Yandex) ) {
return 418;
}
limit_conn one 1;
set $limit_rate 500k;
}
location @nolimit {
proxy_pass http://ip:8080;
}
Atop.
[ATTACH]102179[/ATTACH]
Ситуация сильно не меняется. Увеличил proxy_buffers 64 8k;
Да не число буферов - а размер их увеличьте. И не в два раза, а поболее, наверно...
Сейчас попробую..хотя ситуация вроде немного изменилась, если диск всё время был загружен на 98%, то сейчас опускается до 45-50%, при этом посещаемость на сайтах немножко выросла.
Кстати после перезагрузки nginx нагрузка сильно падает, увеличил proxy_buffers 64 32k;
Сейчас попробую..хотя ситуация вроде немного изменилась, если диск всё время был загружен на 98%, то сейчас опускается до 45-50%, при этом посещаемость на сайтах немножко выросла.
скоро будет другая проблема, ваш link нагружен