Именно так поступили у себя с синхронизацией в общей папке дропбокса. Но все равно ищем лучший (более удобный вариант), много пересмотрели, но ничего не нашли, или сложно (работают девушки-менеджеры) или с дыркой в безопасности
Максим Ворожцов, никуда возможность использования разных доменов не пропадает, как минимум можно задавать роуты с доменами, ну или динамически их вставлять. По поводу стандартных компонентов, они все подходят только для тривиальных задач, иногда приходиться или писать с нуля или допиливать напильником иначе упремся в какую-то мелочь.
Максим, У нас тоже самое и ТТФБ примерно 100 мс, для нас этого достаточно вполне и сервер абсолютно не нагружен, но там по сути база маленькая около мегабайт 500 (сам бекап весит). Мы тоже на будущее думали что
делать если будет (часто и ДДОСы мелкие + бешеный парсинг волнами), придумали что будет делать кеш на Варнише или что-то подобное. С базой проблем нет никаких, мы как заменили мускул году в 2015 на марию так вообще замечательно стало, все запросы при дебаге показывают максимум 20мс (без кеша).
Ребят, вы шутите, 40 запросов к базе с пингом 100+, это ж минимум несколько секунд только на БД, а ещё эти данные нужно обработать и это только генерация страницы, а ещё загрузка статики и рендеринг страницы. Никто в здравом уме не будет использовать продовскую базу для девелопмента да ещё и с такими сетевыми задержками. Есть догадка что раньше работал кеш, а сейчас его нет
А цель распараллеливания - это ускорение запросов? А пробовали кешировать запросы (если проект на нескольких серверах то кеш в редиску можно) или дело именно в специфической задаче?
Анатолий уже ответил, немного структурирую информацию, может кому пригодиться. Нужно отличать пути в файловой системе и на сайте (через веб-сервер). У каждой файловой системы есть корень - это / (слеш), если путь начинается со слеша, это абсолютный путь от корня файловой системы, если начинается не со слеша, это относительный путь (относительный - потому что относительно текущего положения файла). Относительные пути могут начинаться с ../ и ./ - вариант с двумя точками это выход на уровень выше, вариант с одной строкой - это аналогия как я без ничего, то есть в текущей папке.
Зачем нужны относительные пути? Чтобы укоротить путь или убрать зависимость от места хранения файлов, пример: Вы разрабатываете сайт, некоторые статические файлы лежат глубоко в папке с названием пакета, номера версии, юзера, мы прописали в скрипт картинку, скрипт находиться в папке /static/vasya/script - а прописанный абсолютный путь от корня веб-сервера картинки /static/vasya/images, в конце vasya - это автоматически созданные папки пользователей, этот Вася меняет логин на supervasya - по какой-то причине у Вас создан функционал, который переименовывает папки юзеров при изменении логина. И получается что путь изменился и картинка больше не работает (если путь не меняется автоматом), чтобы такой ситуации не было можно использовать просто относительные пути, так как папки script и images находятся в одной папке (/static/supervasya) то просто водим на один уровень выше и заходим в папку images и получаем наш файлик, то есть проще и работать будет всегда (если папки относительно друг друга не менялись). Относительный путь выглядеть будет так ../images.
История с абсолютными путями веб-сервера выглядит похожим образом, нужно запомнить, что / (то есть корень сайта) это та папка, которую мы прописываем в конфиге как root, то есть если корень веб-сервера /var/www/site.name/web то картинка picture.jpg, которая лежит в папке /var/www/site.name/web/images/ на сайте всегда!!! будет иметь вид /images/picture.jpg вне зависимости от того в какой папке находиться файл, где будет прописан этот путь, повторюсь - это все потому что путь начинается со слеша.
Если стоит вопрос какие пути для сайта выбрать, то лучше делайте абсолютные то есть от корня со ведущим слешем спереди.
Теперь, почему абсолютные пути сайта не работают в файловой системе на компе разработчика, все очень просто - корень веб-сервера это папка внутри проекта, а когда мы открываем хтмл файл вне веб-сервера, мы имеем дело с корнем той файловой системы где это лежит, то есть от корня диска и поэтому пути не совпадают, поэтому всегда веб-разработку начинайте с установки веб-сервера (denwer, openserver, vagrant или docker с установленными веб-серверами и т.п.). Знания того как это работает когда-нибудь да пригодятся, особенно когда начнёте копать куда-то глубже чем верстка (а копать рано или поздно начнёте). Работать без веб-сервера можно, но нужно понимать специфику и понимать, что иногда в очень крайних случаях могут быть ошибки типа не сработает images/pictures.jpg, но сработает ./images/picture.jpg, почему так? Разные ОС, версии пакетов, особенности разных веб-серверов и фаз Луны и дня в женском календаре жены ведущего разработчика пакета, который пять лет не менялся и все работало, а потом внезапно сделал рефакторинг без изменения функционала и пути сломались. Ну в общем Вы поняли
СимиларВеб показывает не очень «точную» информацию и пологаться на него в таких вопросах мягко говоря «гадать на кофейной гуще». Данные могут быть похожи, но на деле разница колоссальна (в разы отличаться), особенно по отказам и времени посещения
Asparagales, нельзя, он совсем другое проксирует, например запросы от веб-сервера к бекенду, но никак не Ваши запросы от браузера (или чем хотите ходить в интернет) к сайтам
Павел, странный вывод, на самом деле мария оптимизированнее из коробки на голову выше мускула. Немного дополню Бориса, разница в настройке там только в том, что умолчания разные и есть доп опции параметров, которых нет в мускуле, но конфиг из мускула заведётся и в Марии. В одном из наших проектов просто переход с мускула на Марию без изменения настроек ускорил запросы в три раза (обычные селекты без джойнов), попробуйте - там отличий внешне очень мало
Иван Ильясов, решение простое, выносите файлы, которые нужны на поддомен (то есть просто ссылки на них меняете, а в конфиге веб-сервера прописываете второй server для поддомен с рутом в той же папке, только без http2 и эти файлики будут открываться как надо. Насколько я понял Вам нужен только .epub - это самое простое решение
Или ещё круче, типа даёшь ссылку человеку, которая срабатывает один раз и передаёшь ее например через телеграм, бот телеграма заходит на страницу чтобы сделать превью и следующий переход ведёт на 404. У Вас логика хромает - делайте не одноразовые ссылки, а доступ по паролю или по авторизации. Остальное уже будет с логическими проблемами
Вообще-то это вполне актуально и никакие прокси-анонимайзеры не смогут пройти фильтры по айпи, поэтому всякие накрутчики пытаются подобными способами с реальных айпи и с другими фингерпринтами накручивать что нужно.
Если перерисовываются иконки, которые прописаны как бекграунд в css, то скорее всего у Вас кеширование статики не включено, за это отвечает веб-сервер и движок тут не при чем, об этом писали выше уже
Тут дело в особенностях вёрстки и кеширования. Простой пример - даже если сайт не подгружает ничего динамически, то он может все равно прыгать - например при некоторых реализациях решений проблемы вспышек текста с кастомными шрифтами без их кеширования (foit, fout) - тут механизм таков, высота блока авто, расчёт высоты текста ведётся со стандартным шрифтом и потом пересчитывается после подгрузки «правильного», но обычно так только с выключенным кешем в браузере бывает, аналогично блоки в которые идёт подгрузка контента, но ширина и высота не заданы жёстко (например требование дизайна или лень) и ещё при использовании в css calc - часто можно увидеть этот самый расчёт величины в виде поддергивания размера блока. Поэтому чтобы такого не было нужно или всему где можно задавать размер (не авто) и тестировать кеширование (стили, картинки, скрипты, шрифты), не на всех платформах (в частности не на всех мобильных) все работает так же красиво как на десктопе
Я бы добавил http кеш надо не обойти вниманием, тогда поисковикам в основной массе будут отдаваться 304 а не 200 коды, что в разы ещё сократит нагрузку, а делается это просто добавлением поведения в контроллере