После обновления Safari на IOS перестала корректно работать функция отлючения скролла страницы, страница перестала жестко фиксироваться. Подскажите, есть ли у вас решение для фиксирования страницы на экране? Параметр Overflowhidden не работает
После обновления Safari на IOS перестала корректно работать функция отлючения скролла страницы, страница перестала жестко фиксироваться. Подскажите, есть ли у вас решение для фиксирования страницы на экране? Параметр Overflowhidden не работает
Александр Кузнецов, подскажите, PostgreSQL может конвертировать все данные в Json формат при выдаче их серверу или только Json строки? Нам как раз важен формат всех данных из разных таблиц, т.е. поля могут быть текстовыми, числовыми, датами и тд.
Подскажите, на сколько это ускорит процесс обработки запроса при условии того, что Symfony нужно передать эти данные на фронт? Т.е. ускорит ли это скорость обработки запросов?
Пума Тайланд, мы в целом так и планировали. Но хотели больше опираться на мировую практику и опыт на высоконагруженных проектах. Мы думали в сторону того, чтобы в Redis запихать и другие параметры настроек, которые статичные и можно восстановить из основной БД. Но опять же, интересен реальный опыт. Чем нам симпатизирует PostgreSQL, так это то, что он уже может сам разложить строку в Json формат, что уменьшает операции на самом сервере.
Вводные
- Под одним аккаунтов может сидеть только один пользователь одновременно
- У сессии есть срок жизни равный 48ч
- Ожидается до 20к одновременных запросов на сервер
Андрей, спасибо. Дополнил комментарий вводными данными и уточняющим вопросом. Зачем нам в этом случае Redis, почему нельзя ограничиться только PostgreSQL?
1. Регистрация нового пользователя (вызов метода Reg)
Фронт отправляет POST запрос с данными, которые нужно записать в таблицу Members, сгенерив предварительно UID и повестив его вместе с данными в эту таблицу, а также сделать запись в Redis. В ответ сервер отдает UID
2. Авторизация пользователя (вызов метода Login)
Фронт отправляет запрос c данными для авторизации, сервер идет в таблицу Members, берет данные, в частности uid, генерит новый, заменяет старый в Members, а также обновляет его в Redis. Возвращает данные пользователей вместе с UID
3. Запись прогресса
Фронт отправляет запрос с UID. Сервер проверяет его в Redis, если он валидный, делает запрос в таблицу Members, обновляет соответствующие данные, а также перезаписывает UID и обновляет его в Redis
4. Запрос списка наград
Фронт отправляет UID и CONTEST_ID. Сервер проверяет валидность UID в Redis, если валидный идет в таблицу Rewards и берет все награды для Campaign_ID, а также проверяет какие награды получал пользователь в таблице Members -> Progress.
ЧТО ВИДНО ИЗ КЕЙСОВ
- Практически во всех методах идет обращение в таблицу members
- UID проверяется на валидность до момента обработки основного запроса
- Обновляем UID при POST/PUT/DELETE запросах в таблице Redis/PostgreSQL + TTL в Redis
ВОПРОС, НУЖЕН ЛИ НАМ REDIS И ПОЧЕМУ?
С одной стороны у нас появляется дополнительная прослойка
С другой стороны это прослойка уменьшает объем запросов в основную БД при условии, что будет достаточное кол-во не валидных запросов со старыми токенами. Но какой их процент в реальности?
Если действовать только на базе PostgreSQL, у нас добавляется логика обработки срока жизни токена. Т.е. нужно добавить поля когда выдан и сколько действует uid. Возможно проверка увеличит скорость обработки запроса
