@dim4ik так же элементарно через дату последней рассылки новостей для данного юзера. Пользователя же правильно уведомлять каждых Х часов (дней/недель/мецев/лет), а не на каждую новость, т.е. правильный вариант это дайджест. И ни каких проблем с очередью, т.к. письмо должно уходить по факту.
Желающие мониторить добавление новостей в реальном времени используют RSS.
И редис для данной зачади совершенно не требуется.
@Abdukhafizсам планировщик ни как. Более того, использование его это единственный правильный путь в контексте windows (был бы linux ответ был бы cron).
Авторизацию нужно использовать не для того, что бы оно не попало в спам, а для того, что бы быть уверенным, что оно вообще куда-то попало. А для "не попало в спам" нужны SPF и PTR (при обеспечении коих можно и прямо с сервера фигачить письма без авторизации и не попасть в спам).
@dim4ik чем тут поможет Redis? Что, в нем не нужно будет хранить эти 100 000 000 записей? С каких пор для РСУБД 100Мзаписей стало много, а для in-memory базы нормально?
Если это вопрос использования Redis потому что это клево и модно и круто написать что вот заюзал его в своем проекте, то обсуждать правильный алгоритм под указанную задачу бессмысленно тогда.
@dim4ik Все укладывает в банальную схему связи многое-ко-многим. 3 таблицы: таблица с пользователями user (id_user, name ....), таблица с треками track (id_track, name ...), таблица отмечающая какой юзер какой трек слушал user_track_link(id_user, id_track). Элементарный SELECT...LEFT JOIN даст все исчерпывающую информацию. Redis тут абсолютно не нужен и даже вреден.
@cookie а кто сказал, что планировщик выбрал именно этот ключ? @Gordim прав, EXPLAIN точно покажет, какой индекс используется. Гарантированно окажется, что для обоих запросов они разные.
@Nc_Soft не стоит в сети увеличивать количество лжи. nginx в первую очередь отработает префиксные location и только потом регулярные. Причем вне зависимости от того, в какой последовательности они идут в конфигурационном файле. Более того, модификатором = можно его заставить не проверять дальше регулярные location вовсе.
@nelis как я понимаю, а автора опытный программист все и завалил. Если же под опытным программером понимается новый человек, то текущий разработчик весьма вероятно будет подвергать сомнению все работу новичка и даже саботировать работу. Поэтому и скорость и качество врятли вырастут.
Тогда не подскажу. web dav не юзаю, nginx всегда ставил самосбором. По идее должно было работать. Как вариант могу предложить пересобрать nginx без web_dav. Хотя для начала стоило бы посмотреть вывод strace и убедиться, что это nginx так отвечает, а не бэкэнд.
@Nc_Soft спорно, т.к. на хараде в момент запроса у сервера в распоряжении все ресурсы в отличие от вдс которая могла оказаться зажатой контейнером и не получить так нужные её io-ы. Не один раз видел, как один и тот же сайт работал с шареда лучше, чем с вдс.
Что бы вдс работал лучше, нужно конфиги ручками крутить.
@mittus тогда шансов убедить нет. Только личным примером, только личными деньгами. Берем, финансируем PHP-ка дабы он сделал фичу Х. Она дает денег Y. Все, аргументировать и убеждать не нужно, все покажут продажи. Готовы на такое?
@artem_gurnovich что бы гарантированно проверить URL на факт того, что это картинку нужно в любом случае скачать его. А все это "Высота 30 и ширина 30 продолжаем" баловство. В http header я могу вам заслать что угодно (в том числе, что это картинка, а отдать реально скрипт, и вуаля обзавестись php шелом).
@AMar4enko все правильно говорит, nginx пропускает все типы корректных запросов ( forum.nginx.org/read.php?21,220827,220827#msg-220827 ). То, что в заголовках мы не видим признаков бэкенда вовсе не значит, что запрос на него не ушел. Скрыть заголовки бэкэнда достаточно просто. Единственный случай когда nginx может взять на себя обработку запроса - WebDAV. Поэтому для начала смотрим, собран ли он с его поддержкой: $ nginx -V
@Fesor а что вы хотите от готового решения? Бот сам зашел на страницу, понял, что вот эта форма это форма логина, разобрался, где поле ввода логина, пароля, другие поля, все это сам ввел после чего сделал вывод, работает? )))
@Cyapa в десятки? Не нужно так драматизировать. Чем JOIN пугает? Это нормальный стандартный механизм который можно и нужно использовать. Главное нормальные fk между таблица расставлять. А судя по описанию имеем преждевременную оптимизацию. Приводим к нормальным формам, делаем нормальную структуру, начинаем что-то переделывать если возникает реальная проблема.
P.S. Есть на руках проекты с десятком хитрых JOIN на таблицах по миллиону записей и все прекрасно работает.
Желающие мониторить добавление новостей в реальном времени используют RSS.
И редис для данной зачади совершенно не требуется.