Александр,
1. mysqltuner и тюнить до бесконечности, до момента когда результат уже незаметен на глаз) Увеличивать конфиги так чтобы чуть ли не вся таблица/база лежала в раме, это максимизирует скорость. Ядра сами по себе не знаю точно помогут или нет, но Mhz одного ядра тоже должны увеличить скорость работы. Так что просто смена 4 на 8 ядер не факт что поможет если процессор тот же или около того. Ну и SSD само собой должен быть на сервере.
2. Со всеми запросами одна практика - explain. Там будет понятно что именно делается и что нужно подправить. Джоины сами по себе не оптимизируются, решается всё обычно индексами в таблице куда джоин ходит т.к. он точно так же делает обычный запрос с условиями и без индекса он будет перебирать все данные.
Ну собственно explain должен это показать в том числе. Самый главный критерий это столбец rows в explain. Чем меньше тем лучше. Если там число приближающееся к количеству все записей в таблице значит всё очень плохо либо запрос без условий.
VisualIdeas, насколько часто трудно сказать, но частенько проходит частичная индексация. Особенно с учетом того что постоянно прыгать по файлам надо через подсказки по классам-методом это все равно сильно повлияет скорее всего.
Сейчас проверил у себя, в общем-то даже неплохо работает, индексация 15к файлов заняла минуты 2-3, примерно столько же сколько и скачать такую папку с самбы.
Установка тяжелых npm пакетом тоже по 3-5+ минут занимает и до бесконечности.
+ @vue/cli@4.1.2
added 919 packages from 538 contributors and audited 13286 packages in 1328.214s
22 минуты
Еще тест показал что шторм сразу пишет
> External file changes sync may be slow: Project files cannot be watched (are they under network mount?)
И как результат действительно не видит новые файлы довольно долго, даже если открыть папку и там они будут через Finder/Explorer.
В общем по скорости быстрее чем я думал, но вряд ли это можно назвать комфортным для работы.
res2001, тоже самое в принципе и с NFS.
Не припомню способов вообще для передачи большого количества файлов быстро. Как ни монтируй удаленный диск на любом софте все равно мелкие файлы убивают всю скорость работы. Единичный большие файлы будут летать на максимуме при этом.
Обычно это tar -> download -> untar, иначе можно ждать бесконечно.
res2001, при попытке читать бесконечно количество файлов все равно оверхед будет офигенный потому что каждый файл будет отдельным запросом тянуться скорее всего. Не знаю как там это работает во всяких самбах, но явно какой-то лимит на одновременные подключения имеется и это будет узким местом.
И то судя по опыту того как в принципе быстро работает самба и работы с файлами в обычных условиях там скорее всего один поток как таковой и реализация такая что даже ручной просмотр файлов и папок очень медленный. Так что когда речь будет про сотни-тысячи папок и файлов во всяких вендорах php/js скорее всего это вообще нежизнеспособно.
Zhalgas Saparov, ломается из-за этого {{user.profile.phone}}, в момент рендеринга компонента там нет никакого profile еще.
Поэтому нельзя получить phone из profile который null/undefined.
перед выводом надо проверить что оно там есть
v-if="user && user.profile"
И в целом в коде когда используется тоже самое, иначе там и будет выкидывать ошибку.
Вы видимо с Рональд Макдональд никогда рекламу яндекс или гугла не видели которая ВНЕЗАПНО показывает то что вы искали?
Все это работает абсолютно по такой же схеме, только законность спорная когда вы будете всем подряд сливать собранные почты с телефонами.
А собрать и перепродать другим вообще не проблема, простейшие скрипты с "куками" или хотя бы тупо по айпишнику позволяют это всё автоматизировать, что и предлагают автору
