Adamos, верно, я просто когда отвечаю стараюсь предполагать, что ответ кто-то потом в гугле найдет, года через два, если эту планету не разнесут к чертям хозяева родин. Всех родин.
хорошо, звучит верно, пусть будет по вашему, если написать запрос ON DUPLICATE KEY UPDATE по двум полям возможно, я тоже возьму на вооружение. Но мне казалось, что нет.
Предположение шло из вопроса, что автор занимается оптимизацией. Я не думаю, что вы предполагаете, что можно просто заниматься оптимизацией не желая получить прироста скорости. Скорее я подозреваю, судя по отсутствию в вашем сообщении фразы "в дополнение к" вы хотели просто меня пнуть. За что? Ну не важно. Но вы не хотели, я понимаю. И вообще мне показалось, и я вчера родился.
Смотря сколько их.
Если таблица небольшая и по указанному критерию там десятка два записей будет - можно вытащить "все десятка два для всех критериев" - получится ну бог знает 200 записей. И их проверять. Если их там сотни тысяч, то нужно вокруг этого действия оборачивать в "взять 10 критериев, найти 200 совпадений, проверить, записать, взять еще 10 критериев..." и тд.
Важно понимать, что тут правильное мышление "будет от силы 200", а не "сейчас 200 поэтому так и напишем". Если их "будет 100 тысяч скорее всего" то обертку (условный foreach, или метод еще один, или целый класс) нужно уже сейчас писать.
perchikooko,
а после исправления вот тут уже косяк.
Для каждой записи делается select запрос. Так точно не надо.
Надо оббежать массив, сделать запрос. Один. Выполнить. А потом по результатам одного запроса оббежать еще раз и сформировать два = на вставку и на обновление.
странно выглядит, array_push работает по ссылке, а потом все равно копирует результат в $new, хотя в теории конечно может быть. Я пишу $new = $result[] = $data; По сути то же самое, но субьективно для меня - читается легче.
2) ON DUPLICATE KEY UPDATE я стараюсь избегать, из-за определенной неочевидности. Я обычно делаю Select во что-то, группирую по ключу, и потом проверяю isset($exists[ $key ]). То есть сначала я обхожу $data чтобы построить запрос выборки, выполняю его и получаю $exists. Потом еще раз обхожу $data, чтобы то, чего нет - в инсерт, а то что есть - в апдейт.
3) точно убрать die() из функции выполняющей запрос. Заменить на эксепшен, который на функции выше можно перехватить, чтобы проигнорировать или в лог написать.
4) и как я уже сказал - медленная скорость записи обуславливается не только php кодом. Либо индексов очень много, что он просто долго пишет во все алфавитные указатели, либо наоборот очень мало, чтобы найти "то что уже есть" он проходит всю таблицу, а не использует индекс. Это дебажится с помощью EXPLAIN QUERY, что очень удобно делать в программе баз данных типа Navicat или HeidiSQL, а не в браузере после PHP кода с помощью die(var_dump());
даешь типу решение его проблемы, говоришь ура, наконец-то кто-то ещё захотел, пригодится кому-то, а он такой "хмм, а оно отличное? или просто хорошее?" - мне с тебя денег взять или куда? почитай пожалуйста, умеет оно или не умеет. или ты еще жалобу на меня за это накатаешь.
floppy-drive, если я понимаю правильно, то люди точно делают, чтобы в ответ на /start приходило сообщение "здрасте, я даня крастер", а значит поймать точно можно. И запретить тоже.
Старт или нет, там в метаданных сообщения точно должно быть "от кого" и там точно можно понять что оно - бот. И надо писать в файл список кому нельзя. Со временем все 500 попадут в игнорлист. Не думаю что телеграм позволяет делать "генерацию сотни новых ботов" с помощью скрипта. Главное здесь чтобы первый скрипт отрабатывал как космолет, очень быстро, не начинал чето там скачивать из базы данных, думать что ему написали и когда. Он либо ставит в очередь на разбор, либо сам проверяет Symfony\RedisCache на тему "а запись с таким айди есть?" - "есть" = die();
Ты хочешь сказать, что при приходе сообщения там не написано что оно "от бота"? Не верю. Там точно есть поле, проверяя которое можно писать в ответ "сам ты бот".
А если они таким образом ддосят и им вообще пофиг, отвечаешь ты или нет, их просто тьма, то думаю надо знаешь чего задумать... хмм! Написание от имени бота .conf файла для nginx или iptables, который бота будет в исключения добавлять, а потом перечитывать) например по крону каждые 5 мин.
Как сказали выше - лонг пулинг тоже вещь. Все твои входящие обрабатывает скрипт, который всё, что делает - запускает Predis и пишет в очередь "новое сообщение" (должен вообще в 6мб памяти отрабатывать), а второй воркер его разгребает в порядке очереди, запуская уже непосредственно скрипт который или отсылает что-то боту, или дулю показывает. В этом случае у тебя не 10000 скриптов на пыхе будет работать, а три. Один ставит задачу в очередь, один постоянно очередь чекает, и время от времени запускает третий. Хотя эти три в пиковые моменты могут быть "10002", но первый должен ультрабыстро отрабатывать, без логики.