|
Yii2+redis+AR+mysql+model
|
||
|---|---|---|
Участник
Откуда: Бийск, Новосибирск
Сообщения: 13 075 |
||
|
автора отработка скрипта = микросекунды.
 |
||
| 16.03.2016, 12:28 |
|
|
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
сабж. есть на юи2 модельки для работы с мускулом. есть редис. есть кеш-система. надо: прикрутить редис в качестве кеширующих средств ДО обращения к мусклю. Желательно так, чтобы не переписывать вручную все модели. есть идеи? пока нарыл , redis\ActiveRecord но не совсем понял как это поможет в плане, что мускул все же должен остаться жить - не только один лишь редис. делать дубли всех моделей выглядит глупо. как и ручное перезадание ключей всем моделям . приветствуется ссылки на л-ру + конструктив! спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.03.2016, 18:37 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
Jude, самый главный вопрос, на который следует ответить перед тем, как собираешься городить кеш - а как, собственно, ты будешь его инвалидировать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 13:49 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
FishHook, ответ прост: в "кеше" будет основная жизнь динамически меняющихся данных, которые там как раз и нужны. ну и при этом будет признак/свойство/режим = для синхронизации с бд. например по комманде "зеленый свисток" - я выдаю 10-100 объектов, которые на данный момент готовы к синронизации. после чего скрипт пробегает их и "сбрасывает на диск" - т.е. делает инсерты и т.д. при обратном процессе = если кеш бракованный и нужно его принудительно перекрыть из бд = если это рестарт - скрипт "разогрева" если же это "грохнуть все устаревшее" = то снова список объектов с последующей заливкой + элементы синхронизации наподобие "критической секции" - дабы не поперезаписывать лишнего, не отдать наполовоину проапдейченный элемент и т.д. как это захардкодить я знаю. как это же сделать "по феншую" я пока догадываюсь и вижу 2-3 варианта. вопрос про второе. как "должно бы было быть". ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 15:20 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
бери Memcached плагин к mysql и не компосируй моск. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.03.2016, 17:56 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
Judeв "кеше" будет основная жизнь динамически меняющихся данных Что значит "динамически меняющиеся данные"? Надо полагать, что бывают "статически меняющиеся данные"? Если ты имел в виду "часто изменяющиеся данные" то твой кеш концептуально не верен. Хранить в кеше надо редко изменяющиеся, но часто запрашиваемые данные, чтобы не ходить за ними в базу и не нагружать её одним и тем же запросом, ответ на который вероятно будет один и тот же в течении продолжительного времени. Каталог каких-нибудь товаров, который обновляется раз в неделю или расписание занятий или меню сайта - вот данные, которые нужно кешировать. Если у тебя инвалидация по времени жизни, то ничего страшного не случится, если расписание занятий изменится не в тот же момент, когда его поменяли в БД: ну случится это через 10 минут, ну и хрен с ним. То, что ты придумываешь, скорее всего не даст ощутимого прироста производительности, зато существенно усложнит систему. У меня есть опыт изобретения наколенного суперкеша на редисе. Идея была подписаться на все события изменения и удаления моделей из ОРМ Django и по этим событиям изменять соответствующие объекты, хранящиеся в редисе. Специфика проекта такова, что есть довольно большой набор справочной информации, которая изменяется редко, но изменения должны в реальном времени отображаться на клиенте. Полгода я поддерживал разработку довольно своеобразной самописной системы, объединяющей под одним фасадом кеш, ОРМ, БД и бизнес-логику. И оно даже работало. В итоге оказалось, что овчинка не стоит выделки - на часто запрашиваемых данных "умный" кеш не дает существенного прироста производительности, потому что оракл сам умеет успешно кешировать такие запросы, а на редко запрашиваемых кеш нафиг не нужен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2016, 07:21 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
FishHook, интересный опыт. тут нет цели в "супер умном" кеше. идея как раз в том, что будет хорошая нагрузка. и 70мс на запрос - очень долго. поэтому ВСЕ пхается в кеш. ну и бэкап кеша в мускул идет типа по крону. так хочет заказчик. то , что при 2500 подключений мускул ляжет - немного пугает заказчика. как будто пхп или апач вытянет 2500 :) но. т.к. для масштабируемой системы можно сделать несколько шардов - типа все будет ок - ограничения пхп не пугают заказчика. и вот придумали сделать кеш узким местом. теперь все громоздкие структуры (это НЕ картинки) - я прячу в кеш - вместо мускула. точнее в редис. и вынимаю оттуда. всю "статику" - типа справочников, которые тоже можно поредактировать из админки - но они общие для всех - я тоже положу в кеш - точнее JSON - чтобы сразу отдавать. а динамику - - данные , которые персональны для каждого юзера - ее буду вместе с моделями хранить отдельно- в редисе и отдельно - в мускуле. идея в том, что запросы к бд по юзеру при хорошем rps - дадут плохой отклик по времени а если всех направить в редис, то скорость будет повыше. зато можно будет задедосить редис сервер :) но т.к. они в одной подсети (а то и на одном физ серваке) на начальном этапе это никого не напугает. в общем была команда так сделать. но на случай если все плохо - из редиса бэкапить в бд. а на случай совчем плохо = из бд залить в редис при "проведении технических работ". как-то так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2016, 13:06 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
Jude, а почему бы не подумать в несколько другом направлении - кешировать на клиенте в локалсторидж и по запросу отдавать http 304? Тогда в редисе тебе придется держать только пары id->timestamp и model_name -> last_id ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2016, 13:23 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
FishHook, потому как "клиент" = мобильное устройство с жаба-приложением и контуженным "своим" протоколом с претензией на RESTful API есть сомнения в клиентской возможности по локал стореджу. ++ данные желательно проверять на серверной стороне. из соображенией безопасности - т.е. по максимуму сделать невозможным брутфорсить ид юзеров или от имени одного юзера получить частично данные другого юзера и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2016, 13:40 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
FishHook, выходит : получил запрос. залочил учетку в редисе типа "идет обработка команды" сформировал ответ. разлочил учетку отдал ответ. доделал действия по запросу, которые можно оставить на отложенное выполнение.(крон, обсервер, шо угодно.) вплоть до того, что если комманда сотрудничает с внешними сервисами ( мордокнига, к примеру), то сперва отдал запрос что все ок, а когда дождался ответа и узнал, что не все гладко - залочил учетку, или предпринял другие действия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2016, 13:45 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
FishHook, собственно пока у меня есть ряд юи - моделей сгенерированных для админки - с crud = т.е. что-то похожее на справочник. и есть такие - же модельки = но для юзер даты - без контроллеров. есть набор рест - комманд. каждая комманда наследуется от предка , который , в свою очередь , наследник базовой команды. есть ряд общих обработок и проверок - одинаковый для всех. а дальше идет разделение слоя бизнес - логики и орм. т.к. прикрутил всю работу с хранилищем через орм - питал надежду , что получится безболезненно , не переписывая слой логики, перейти на работу через редис. т.е. надо: - запрос к модели за данными - проверили редис - вернули данные. - если в редисе не было - запись в лог - и берем из мускула.(типа ленивого обновления) - записываем в редис. - запись данных - запрос к модели. - пишем в редис. - даем запись в событие - обновить базу. - по крону - выбираем кого надо обновить(наблюдатель он же обсервер) и пакетом обновляем. - после чего снова проставляем флажек что данные актуальны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.03.2016, 13:55 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
Jude, А у тебя все запросы по одной записи возвращают что ли? Допустим, надо нам извлечь все записи из одной таблицы (тупо без джойнов) за период с каким-нибудь фильтром, ну и как ты поймешь, что нужные записи есть в кеше? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2016, 14:34 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
Один только вопрос, зачем все это? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2016, 22:05 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
Защита от ддос на уровне пхп это бред. Если нужна большая производительность, используйте шардинг, например ту же галеру на мускуль, или другую субд где шардинг есть из коробки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.03.2016, 22:09 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
FishHookJude, А у тебя все запросы по одной записи возвращают что ли? Допустим, надо нам извлечь все записи из одной таблицы (тупо без джойнов) за период с каким-нибудь фильтром, ну и как ты поймешь, что нужные записи есть в кеше? нет, не все. для частичных выгребаний я использую те же модели юи. и связанные данные. с т.з. производительности это не очень... но! если есть штука как не изобретая велосипеда получить работу с моделью , где вместо мускула - редис... то собственно было бы не плохо. в противном случае получается наоборот = нужно каждый подобный запрос делать методом модели и решать как с ним быть. цель не в том , чтобы все переиначить... цель засунуть часто используемые и тяжелые данные в редис, облегчив к ним доступ и ускорив работу. т.е. 1 запрос к серверу бд вместо 50ти запросов.. 1кб данных вместо 1 гб и т.д. но т.к. используется ОРМ - надеюсь хоть начто-то она годна? ну кроме необходимости изучения еще одного мета - языка + отжирания кучи ненужной памяти впустую... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 08:10 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
HettЗащита от ддос на уровне пхп это бред. Если нужна большая производительность, используйте шардинг, например ту же галеру на мускуль, или другую субд где шардинг есть из коробки. так надо. архитектуру планировал не я. шардинг будет . если по решению есть совет - неплохо бы ссылочку на статью/ пример решения, если не затруднит. спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.03.2016, 08:13 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
В Yii есть возможность кэшировать блоки на уровне вьюх, может уж лучше этот механизм тогда и использовать, и редис ваш любимый без дела не останется Хотя хватило бы и мемкеша. Просто вот лично я не понимаю, зачем вы городите такой механизм, когда выборка из MySQL по правильно сформированному ключу будет моментальной (миллисекунды). В итоге на обработку самого пхп скрипта будет тратиться в разы больше времени, чем на запросы к субд, т.е. проще проц мощнее поставить. Время программиста дороже железа зачастую. Если там какие-то сложные запросы получаются, то можно задуматься о денормализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2016, 10:13 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
Hett когда выборка из MySQL по правильно сформированному ключу будет моментальной (миллисекунды). В итоге на обработку самого пхп скрипта будет тратиться в разы больше времени, чем на запросы к субд, т.е. проще проц мощнее поставить. Время программиста дороже железа зачастую. Если там какие-то сложные запросы получаются, то можно задуматься о денормализации. предположительно 1 млн юзеров при хорошем rps = положат мускул. 70мс = минимум при запросе. а отработка скрипта = микросекунды. при привычке поведения из коробки "по запросу на чих" будет 20-50 запросов на страницу (космический бред! но факт:( оптимизировать вызовы можно - но нужно выбрасывать "родную" логику). построить нормальную архитектуру - нужно время. пока мой опыт говорит, что никто на этапе проектирования не задумывается об этом, и "просто сделать нальзя?" а к моменту если проект доживает до нормальной нагрузки и все начинает захлебываться - руководство задумывается про оптимизацию. но в целом согласен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2016, 11:36 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
автора отработка скрипта = микросекунды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2016, 12:28 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
Hett, ладно, погорячился. не микросекунды. в случае с фреймворком загрузка ядра кушает хорошее время - ++ не видел скриптов, написанных правильно, где бы время обращения к базе было бы больше , чем время работы скрипта. исключение - если очень медленная файловая система , а сервер БД лежит где-то на "виртуальном диске" - т.е. оперативной памяти. а так , да. если на поток - читай на 1 скрипт - дано достаточнео памяти чтобы не париться с "постраничной обработкой" - скрипт штука довольно шустрая. "тупить" начинает , когда мы связываемся с базой данных, особенно если она где-то удаленно на др. сервере. ну и классика "время отклика не должно превышать 100мс"(с) = как правило не дает сделать более 1 запроса , который в районе 70-80 мс. :) ладно я че то в оффтоп ударился. как понимаю "волшебного компонента" никто не предложит. :) напишу - поделюсь впечатлениями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2016, 14:58 |
|
||
|
Yii2+redis+AR+mysql+model
|
|||
|---|---|---|---|
|
#18+
Вообще даже кэширование запросов реализовано в самом Yii из коробки. Там хоть в редис настраиваете, хоть в файлы, хоть в мемкеш. Не подойдет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.03.2016, 15:23 |
|
||
|
|
start [/forum/topic.php?fid=23&fpage=46&tid=1461175]: |
0ms |
get settings: |
12ms |
get forum list: |
15ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
31ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
78ms |
get tp. blocked users: |
2ms |
| others: | 262ms |
| total: | 422ms |
| 0 / 0 |
