Да я изначально хотел с docker разобраться )

Laravel Ninuzhna

тогда phpdocker.io , генери, меняй, разбирайся

Да тут не в php дело, а именно в самом докере, для лучшего понимания решил сам что-то более менее рабочие поднять и попробовать, т.к. переодически сталкиваюсь с ним, и приходится на уровне рандомного тыка править, что мне не нравится )

😂👍 следующий этап после Лагавель)

ну вот phpdocker - это способ взять изначально рабочий конфиг и править его, разбираясь, как работает докер

laradoсk - это способ юзать докер, не разбираясь, как он работает, плохой способ.

Спорить не буду, но есть причины, по которым нужен был чистый докер композ )

Чуть подправил пермишены, теперь в логах nginx вижу
2020/03/20 07:39:45 [error] 6#6: *2 directory index of "/var/www/public/admin/" is forbidden, client: 172.28.0.1, server: , request: "GET /admin/ HTTP/1.1", host: "localhost:8081"

хз в чет точно трабла, но после того как я поменял префикс для роутов админки и убрал admin то все заработало)

Насколько я понял, был конфликт - у тебя "виртуальный" путь был /admin и физическая папка с таким же именем.

да, тоже об этом подумал

Всем привет, есть вопрос по поводу кеширования и оптимизации. Когда есть диалоги с юзерами, мы запускаем приложение и открываем его и показываются последние сообщения, допустим их штук 20 (условно) и сами диалоги тоже (сколько их там есть). Я выкупаю что если запустить приложение и грузить всё из БД, то будет дохера времени тратиться на загрузку диалогов и сообщений из бд, пришла в голову идея организовать memcached, кешировать все чатрумы в которых состоит пользователь и кешировать их, также кешировать n-количество сообщений в каждом чатруме и тянуть их из memcache при запросе, а потом уже лейзилоадом подтягивать сообщения при скроле, которых не было в memcache. Как думаете это хорошая идея?

Плохая. Ты всю базу в кэш перегонишь, а всего лишь изменением пары настроек и мускуль можно в оперативку выгрузить.

В твоем случае кэш может устареть и нужно будет совершать дополнительные неоправданные телодвижения на его актуализацию и проверку целостности, так сказать.

Также, приложуха кидает запросы в json, а это копеечный трафик. Оптимизируй запросы к базе и всё будет нормально.

А так, на лицо явная попытка сэкономить на спичках.

Ну хорошо, а если к примеру юзеров уже тысячи, сообщений сотни тысяч

Юзер открывает приложение

И как сделать так что бы при открытии не тратилась тонна времени

На загрузку

Ну смотри, условно у тебя 10'000 юзеров. При открытии приложения они кинут 10'000 запросов на получение списка сообщений. Допустим, одно сообщение будет весить 1Кб текста.
Ты рассматриваешь вариант заменить это на следующее:

1. 10'000 юзеров получают сообщения в первый раз;
2. При повторном входе кидается 10'000 запросов на сервер, получая в ответ кэш сообщений для юзеров;
3. Локально собирается массив id записей и юзеры отправляет 10'000 запросов на сервер, передав id, в ответ получив новые данные.
4. Также, эти 10'000 юзеров отправляют 10'000 запросов на бэк с целью проверить какие из сообщений были удалены (сообщения можно заменить на посты, например, не суть).

Итого: сейчас ты кидаешь 10к запросов и получаешь ответ из базы. Всё норм.

В предлагаемом варианте картина будет следующая:
1. 10к запросов, они кэшируются (это минус 10Мб в оперативку (за кэш редис же отвечает, да?));
2. В ответ получаешь 10Мб кэша
3. Вновь кидаешь 10к запросов, сервер очищает 10Мб кэша и вновь составляет его;

Итого, в первом случае сервер примет 10к запросов, а во втором - 40к на то же самое действие.

Вопрос: в каком варианте нагрузка на сервер будет наименьшей?)

Переведу пример в другую плоскость. Например, удаленка:

Первый вариант: человек сел на автобус, доехал до работы, взял нужные документы и вернулся домой.

Второй вариант: человек сел на автобус, доехал до работы, взял документы, сел на автобус, вернулся домой. Посмотрел каких документов нет, сел на автобус, приехал в офис, оставил ненужные и взял нужные, сел на автобус и вернулся домой.

Ну да, в принципе логично поулчается, тоесть кеш тут юзать не нужно?

Не нужно. Как минимум это экономия на спичках, а как максимум - намеренное увеличение нагрузки на сервер.