А в чем проблема не понимаю? Тащите страницу всю каким нибудь file_get_contents (PHP), запихиваете в md5 (PHP) и складываете все в базу вида url|hash
И парсите хоть каждые 5 минут, md5 быстрый алгоритм и не грузит железо, и сравнивайте хеши, изменился ли хэш или нет. Если изменился - шлите email
UPD: Есть более короткая запись md5-file
PS. Только используйте sleep чтоб не ложить сайт туроператора и запускайте из командной строки обернув все это в цикл, там (cli) обычно не ограничено время выполнения скрипта, и вот у вас уже "демон" болтается и следит за обновлениями. Можно пойти дальше и повесить мониторинг работы скрипта и если не работает перезапускать процесс :))
Magistr, Моё предложение остаеться в силе, сделайте несколько запросов просто с ON email = email_N, а потом данные объедините в приложении
Из 7000 строк, выбираеться 3697 строк по where, а потом каждая из этих строк в джоин сравнивается с !каждой строкой во второй таблице, то есть 8738 раз, как думаете это быстро? Индексы помогают уменьшить результатирующую выборку для сравнений, у ТС на первом скрине ключ email в столбце ref имеет значение NULL, что говорит о том, что сравнивается со всей таблицей и чем больше таблица, тем дольше будет работать запрос при том по экспоненте, тем более IN работает только с проиндексированными полями, иначе он убивает любой селект - так в документации написано, не мои слова )))---------- Добавлено 21.07.2016 в 20:12 ----------
Поверьте, вы ошибаетесь :)
В данном случае можно добавить поле partners_id в mailmaster_users и склеивать по нему. Но лучше вынести настройки в нормальную табличку с адекватными связями.
Я предпочитаю хранить настройки/поля/etc в табличке вида id_сущности|название_поля|значение_поля, можно повесить индекс на значение поля и составные индексы на сущность+название+значение, сущность+название
---------- Добавлено 21.07.2016 в 19:38 ----------
Ну вот, а тут всего 3697 строк обрабатываеться и везде с индексами, как положено
У вас запрос обрабатывает 32 304 386 строк
А добавьте EXPLAIN с одним параметром, который отрабатывается быстро. У вас просто на джоинах не используються индексы, да и тип объединения чуть лучше чем ALL, но очень плохо что последний.
А вообще предлагаю упрощать запросы, разбивать на подзапросы и менять структуру или вводить избыточность в таблицы.
без EXPLAIN не понять, скорее всего там где то не юзается индекс и mysql из за этого ворочает миллионами строк, собственно по этому так и долго.
Выполните запрос 3 раза, будет 0.3 сек. А так, если я правильно понимаю в IN вы каждый раз обходите таблицу table1, но 7000 записей для базы это фигня какая то, запустите EXPLAIN
Там много других плюшек: модульность, повторное использование кода, наследование и так далее. Вы пробовали делать адаптивные сайты? Прикольно переделывать все media с 990px на 991px?
CSS - это такая штука, если квалификации нехватает, делаем custom.css и подключаем ниже основного и делаем там свой огород, дабы стили каскадные.
Вы же должны понимать, что это попугаи? У меня на виртуалочке за 250р/м проект (>120 000 номенклатура - автозапчасти) на Yii держит эталонный тест в ~2500 запросов в секунду и то мне кажется это было ограничение железа с которого шел тест, потому что сайт даже не поперхнулся.
Но хозяин барин конечно, если учесть что php, да и все интерпритируемые языки с понятием скорости в принципе не дружат, тот тут (в сфере веб разработок) обычно выбирают по другим параметрам 😂
Таких middleware framework'ов довольно много, сайлекс построен на компонентах symfony, что говорит о простом росте если потребуется.
Модели везде надо прикручивать самому, где то уже вшитая есть реализация ORM, но тут хоть доктрину прикручивай. Тем более композер никто не отменял, а у silex нет каких либо ограничений на этот счет.
Лично у меня на слуху из таких фреймворков только 2 - это silex и slim. С певым довольно хороший опыт, со вторым дел особых не имел.
