Можно ли хранить laravel passport токены в redis/memcache?

Question

[Евгений Хрипунов]

В SPA приложении настроена аутентификация через laravel passport. К каждому запросу прикрепляется токен и проверяется есть ли такой в бд. Следовательно при каждом get/post запросе отправляется запрос в бд такого вида:

select * from `oauth_access_tokens` where `id` = '6756c7ef9221d9b897c1980a84349618aefce2e44db6380756b839a19c54bc5a0a65be3cd2a6ac90' limit 1

Можно ли сохранить данную таблицу в redis? Т.е. в laravel passport сначала проверять есть ли токен в redis, если нет, то проверять в бд, и далее добавлять его в redis. Хотелось бы таким способом снизить нагрузку на бд.

Answer 1

[Александр Аксентьев]

А сколько у вас уникальных юзеров стучится в апишку?
Здесь запрос проще некуда, ничего вообще не даст это изменение.

Не говоря уже про то что в самой базе есть свой кеш, и он нормально работает для всех запросов из коробки.

Comments

[Евгений Хрипунов]

Просто в очевидной (идеальной) ситуации где можно использовать redis/memcache хочется сделать именно через них, вне зависимости от количества пользователей.
Всё будет упираться в количество уникальных пользователей в секунду при запросах к бд. Для redis же эта планка намного выше. В ситуации, если пользователь не просто заходит посмотреть на сайт, а минут 10-20 постоянно с ним взаимодействует и отправляет запросы, каждый из которых дополнительно отправляет запрос на проверку токена в бд, всё это увеличивает время общего ответа сервера, особенно если пользователей много. Memcache/redis как нельзя кстати подойдут в данной ситуации (токены меняются не так часто, даже если данные в redis/memcach затрутся/потеряются токен всегда можно опять вытащить из бд)

[Евгений Вольф]

Просто в очевидной (идеальной) ситуации где можно использовать redis/memcache хочется сделать именно через них, вне зависимости от количества пользователей.

Вы точно уверены, что это что-то даст (я имею в виду положительный эффект)? Для сокращения времени ответа БД есть масса других способов:
1. Таблицы в памяти (Memrory)
2. MyISAM-таблицы
3. Индекс в БД
4. Кэш самой БД
5. Unix-сокеты для подключения к БД

Так же, важный момент заключается в том, что "горячие" данные БД хранятся в оперативной памяти (и как следствие - достаются они оттуда очень быстро), а память - одна на всех, и чем больше памяти будут "откусывать" другие приложения - тем меньше её будет доступно для MySQL.

Всё будет упираться в количество уникальных пользователей в секунду при запросах к бд.

Судя по этой этой строчке, насколько я понимаю, у Вас проект масштабов mail.ru и база "не справляется"? Либо, Вы стали "очередной жертвой оптимизации" пытаясь починить то, что ещё не сломалось (и ломаться пока не планирует).

Я думаю, наиболее вероятны тут следующие варианты:
1. Выбор Laravel passport - был не рациональным решением в данном случае, т.к. он не имеет возможности справляться с поступающей нагрузкой, в виду того, что не умеет использовать кэш-хранилища
2. Laravel passport - отлично работает и без кэш-хранилищ, по этой причине его разработчики не сделали соотв. поддержку этих самых хранилищ (т.к. выигрыш от них крайне незначителен, если вообще есть, в данном случае)
3. Разработчики просто не успели добавить поддержку кэш-хранилищ и сделают это позже. Вам нужно просто подождать, сделать это самостоятельно или нанять пару индусов, которые охотно помогут Вам решить этот вопрос за небольшое вознаграждение.

P.S. Мне кажется, немного допилить код, добавив туда механизм, о котором Вы говорите - не должно составить особого труда для опытного разработчика, а если эти доработки ещё и оформить в виде патча и/или прислать merge-request авторам... То чувство, когда ты понимаешь, что мир стал чуточку идеальней (или просто лучше), обычно стоит потраченного на это времени.

[hOtRush]

Евгений Вольф, какие-то странные советы. Myisam который уже deprecated, или кэширование запросов для базы под нагрузкой) Индекс здесь может не дать желаемого результата. А вот in-memory таблицы можно попробовать.

[Евгений Хрипунов]

Евгений Вольф, спасибо!

[Евгений Вольф]

hOtRush, "deprecated" != "deleted". Я думаю, Вы же в курсе, по какой причине он "deprecated" и про особенности данного движка... я веду к тому, что для хранения различного рода "мусора", вроде временных токенов, сессий и т.п. данных не критического значения - он вполне может сгодиться. Касательно того, что "индекс может не дать желаемые результаты" - это очень тонкий вопрос, всё зависит от того, какой именно индекс и как он используется (и используется ли вообще) и массы других факторов, если смотреть на вещи под таким углом, желаемого результата могут не дать и "MEMORY"-таблицы, в зависимости от того, чего и как именно желать и применять в конечном итоге.

Евгений Хрипунов, в некоторых случаях (когда-то раньше), мне помогала так же, установка однобайтовой кодировки для таблиц, в которых данные хранятся (например, CP-1251). Сейчас не могу вспомнить подробности, но логически это должно дать следующий эффект: данные (сама таблица) на диске занимает меньше места, благодаря чему доступ к ней осуществляется быстрее.

Answer 2

[Вадим Щепотьев]

Ну а чего вы, сколько у вас там юзеров или сколько предполагается? Взяли и сделали нагрузочное тестирование, удостоверились что база тут отработает быстро и идеально и занимаетесь другими более важными вещами. Если проще, то перед тем как вы получите влияние на скорость от такого простого запроса, вы поймёте что bottle-neck тут php, и пойдёте думать в сторону load-balancing и распределеных систем, а вот когда вы уже начнёте упереться в базу данных, вот тогда можно будет подумать о репликации.
кеширование в данном случае вас не спасёт вы продублируете данные в памяти, MySQL это умеет делать и без вашей помощи, в общем случае вообще не имеет смысла делать кешированое на одиночные разряженные и простые запросы.