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

Маркетинг для шоколадной фабрики. На 34% выше средний чек
Через устранение узких мест
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
X-Accel-Redirect
Никто об этом не писал. Не знаю, какому идиоту могут понадобиться счетчики "для всего".
Пф, легко. Учет количества скачиваний определенного файла или изображения на фотохостинге. Самый простой и распространенный пример.
И именно тут возникнет вопрос: как наиболее эффективно вести эту статистику на нагруженном сайте с приличным трафиком. И попробуйте кому-то рассказать, что отдавать статику или отдавать статику и считать на лету счетчик равно одно и тоже )
И как это поможет сделать из 1+1 = 1 операцию в обсуждаемой задаче
Тут вопрос, скорее, как сделать, чтобы php не имел отношения к отдаче статики и при этом в нем можно было вести статистику. И X-Accel-Redirect в этом помогает. Более того, даёт возможность настроить доступ к файлу и т.д.
Можно много теоретизировать о решениях для многомиллионных сайтов, но наиболее практично решать задачи, которые по нагрузке максимум в 10 раз отличаются от текущей.
И если у ТСа возник такой вопрос, то скорее всего, вряд ли там посещаемость сколько-нибудь значимая. Хотя да, хотелось бы знать больше вводных.
Но в целом, если просто отдавать файл через PHP - это даже на мелком сайте будет нагрузка, а вот сделать тоже самое через передачу задачи с PHP на Nginx с помощью заголовка X-Accel-Redirect, предварительно сделав обсчёты, будет, как мне кажется, наиболее оптимальным решением.
Следующим этапом уже заносить задачу подсчёта в очередь и делать пересчёт асинхронно с выполнением текущего скрипта. Это если нужна какая-то дополнительная логика, а так и логов достаточно будет.
Но в целом, если просто отдавать файл через PHP - это даже на мелком сайте будет нагрузка,
Собственно, о чем и была речь и о чем решил поспорить estic. В данном контексте и было сказано, что из-за отсутствия вводных есть два решения. Можно сделать при помощи PHP, чем и интересовался ТС в теме, но с оговоркой, что при определенном трафике это легко может нагрузить простенький хостинг и выбить во временную блокировку или понижение ресурсов. Потому, в этом случае, стоит использовать не прямой php-подсчет скриптом, а фоновый.
Так в том и дело, что X-Accel-Redirect никоим образом не исключает необходимость запуска скрипта. Вам все равно придется выполнить вторую операцию - подсчет. А она ресурсоемкая. И эта директива ничем тут не помогает, она лишь инструмент более гибкого применения, на вкус и цвет админа. А если вы это еще и на хостинге вдруг делаете, то доступа к конфигурации nginx у вас в принципе может не быть.
Посему возвращаемся к искомому. PHP-подсчет имеет место быть на низком трафике, либо для использования, к примеру, в качестве пикселя. В остальных случаях следует изучить более тщательно задачи такого подсчета и, по возможности, оптимизировать.
PS: Вообще, конечно, это пустые споры, поскольку для тех, кто никогда не сталкивался с большими нагрузками и миллионными записями, а оперирует шаблонными сайтами - эти вещи крайне далеки и не интересны, в их вселенной такого не произойдет. А если произойдет, то они имеют привычку сообщать, что "упс, ну не хватает ресурсов тарифного плана, купите следующий". В моей же практике приходится заранее задавать клиенту и себе вопросы о предварительной оптимизации процессов, чтобы потом не было неожиданностей и необоснованной траты ресурсов, а следовательно и денег на них.
Не строки/байты лога же в самом деле считать, как кто-то выше написал 😀
Уже после этой фразы можно было завершать дискуссию, ибо если сat/grep/sed лога вызывает такое удивление, то о чем можно вести речь..
вы по-любому делаете +1 операцию сверху
Тема как раз про это 😉
По крайней мере была, пока автор не заговорил про куки 😀
Тема как раз про это 😉
По крайней мере была, пока автор не заговорил про куки 😀
И именно в этом контексте были оговорки без вводных, что есть два пути, в зависимости от условий.
Все ответы выше, не вижу, что еще тут можно добавить по теме.
И попробуйте кому-то рассказать, что отдавать статику или отдавать статику и считать на лету счетчик равно одно и тоже )
Хотел бы я посмотреть, как вы будете считать статистику не "на лету", объяснять пользователю, что статистика запоздалая, и при этом "укладываться в 0" 😀
Кхм. Если это не задача выполнения операции здесь и сейчас, то является нормой задержка отображения статистики. Начиная с движков форума, которые считают темы и сообщения раз в период, заканчивая такими крупными системами как РСЯ - статистика дохода в них не мгновенная, а показывается с задержкой и даже после окончания суток сумма еще изменяется.
Неужели это вас так удивляет? 🤦
И эта директива ничем тут не помогает, она лишь инструмент более гибкого применения, на вкус и цвет админа.
то является нормой задержка отображения статистики
Пользователю успели об этом рассказать? Или он в перманентном паническом состоянии у вас находится по поводу того, что "там" происходит за горизонтом доступной статистики?
Нужно хотя бы написать "Чему быть, того не миновать". Пусть сильно не паникует 😂