Алексей Тен, АУФ ПУШКА)
только теперь попутный вопрос, если надо отфильтровать массив из 1000 объектов и внутри .filter() я буду использовать эту функцию, не сильно потеряю в производительности?
Максим, есть, откройте devTools перезагрузите страницу, выберите фильтр WS по подключениям и увидите своё подключение WebSocket, нажмите на него и там будет вкладка Messages, попишите в поле отправки что-нибудь и увидите как сообщения побегут, если же нет, значит где то косяк с отправлением.
Я думаю стоит отметить мой ответ решением, потому как на основной вопрос я ответил, а вопрос, который сейчас возникает перенести в новый и там уже будет больше ответов и подходящая тема
Максим, в DevTools браузера отправителя посмотрите, он шлет что нибудь? На получателе посмотрите, принял что либо?
В laravel, в routes/channels.php прописали для этого приватного канала обработку?
Andrew, извиняюсь, что подумал на свой счет, просто ваш комментарий был сразу под моим и не адресован никому, поэтому из контекста подумал на свой счёт)
Andrew, ну т.е. фреймворки работают без события по полю или по свойству, за которым смотри watch или computed (как пример привел Vuejs)? Всё это работает по событийной модели и как раз автору и был дан ответ о том, что следует смотреть на события и идти в эту сторону
AUser0, проблема join в том как выстраивается план запроса, в случае where он выстраивается по другому, я и про это читал, но было очень давно и я уже не могу найти источника, но это зависит от БД, потому как план может быть и одинаков. Много индексов тоже не всегда хорошо, например, если поле под индексом часто изменяется, то это будет лишь тормозить запросы и работу БД. В этом случае лучше иметь несколько таблиц с распределенными данными и несколькими связями, так в случае частых изменений индексы могут быть не затронуты там где это не нужно, об этом также говорилось в комментариях
viktorross, и ещё совет по *, лучше отказаться от нее, посмотрите какие поля действительно используются, если же действительно используются все, то пропишите ручками их, это тоже сократит время запроса, я читал об этом, правда сейчас не могу найти ту статью
С вашего позволения оформлю как ответ, чтобы потом другие пользователи могли воспользоваться этой информацией.
viktorross, часто это просто ошибка, коллега на такое наткнулся, когда я ещё был в начале своего пути. Я тогда просто не переваривал и не понимал запросы с join, поэтому всегда старался их избегать и как то раз он сидел и матерился на запрос такого рода, он отрабатывал около 5 минут)) тогда я просто предложил сделать where, потому как сам так делал и запрос выполнился за секунду)) Вот такая история, для меня она была очень яркой, помогла запомнить, что join не всегда и не везде нужен)
А добавлен он скорее всего туда для того чтобы отсечь ненужные строки, как и предполагали Руслан ., и я ранее
viktorross, кэш отдал так быстро скорее всего. а потом произошло переполнение и выбралось снова, скорее всего его недостаток с введением новых запросов стал причиной, либо за это время был какой либо insert или update, что также выбрасывает запрос из кэша, но во всяком случае уберите не нужный join, он тормозит выполнение.
Как часто происходят изменения записей или вставка новых?
это я к тому, чтобы дальше проект не загнулся