Когда я обнаружил проблему с моделями (профайлером), исправление ускорило код примерно на 30%. Пришлось сделать самодельный кэш атрибутов и использовать в нагруженных местах.
Пожалуй самый главный тормоз это модели, а точнее доступ к атрибутам. Они реализованы в корне неверно, и вот я посмотрел в 8 версии ларавела — все то же самое. А проблема вот в чем: модель внутри хранит сырые данные из базы, и при каждом обращении к атрибуту вызываются касты и мутаторы, и это никак даже не кэшируется. Соотвественно запись в атрибут сразу конвертирует значение в понятное базе. А должно быть наоборот — конвертация один раз при чтении или записи в базу.
В нашем проекте есть json поля в базе, и много бизнес логики для них, соответственно обращение к таким атрибутам очень частое, и вот при каждом обращении под капотом вызывается json_decode/json_encode. Я был разочарован когда раскопал откуда тормоза пошли.
Второй пример это функция Arr::get(), а точнее ее использование. Она позволяет получить значение из вложенного массива передавая путь вида «path.to.value», и соответственно реализация содержит explode() и цикл по сегментам пути. Так вот очень важная функция config() под капотом вызывает ту самую Arr::get() при каждом обращении, никак не кэшируя результат. И если у вас где-то в большом цикле вызов config() — прощай производительность. Эта Arr::get() используется и некоторых в других местах аналогичным способом.
Это два ярких примера которые пришли в голову сразу, на самом деле там еще найдется. Вполне возможно что в вашем проекте это не актуально, но эти примеры отлично иллюстрируют подход разработчиков к вопросам производительности.
Проблема отсутствия специалистов не пришла внезапно, она медленно надвигалась и все об этом знали. Так почему нельзя было еще 10 лет назад начать переписывать легаси код? Программу за программой, это ж не один гигантский монолит. Как я понимаю и сейчас не спешат, ждут когда последний дедушка нас покинет?
Вообще Laravel довольно неоднозначный фреймворк. На первый взгляд он очень функционален и в нем реализовано много полезных штук, но как только приходится решать нетривиальную задачу с помощью этих самых штук — начинаешь вспоминать разработчиков матерным словом и переделывать их работу. То же самое касается производительности — очень многое реализовано крайне неэффективно и начинает дико тормозить с ростом посещаемости.
Посмотрел в настройках — судя по всему нет. Только последнее состояние или один из преднастроенных режимов, а в этих режимах нельзя настроить чтоб было выключено.
Тут я бы не был так уверен, все-таки прогресс в сторону юзабилити очень даже заметен. Скорее они просто не спешат наладить всю систему разрешений и привести ее к максимально идеальному виду, но тут опять же не все так просто. Эти кривые объединения разрешений были заложены изначально, практически в фундаменте, и чтоб теперь их разделить — нужно проделать очень много работы, при этом не забыв про совместимость со старыми приложениями.
Мы начинаем смешивать намерения разработчиков и функции ОС.
Разрешения пачкой это legacy, так было в приложениях под старые версии андроида, и пока они продолжают работать. Но новые приложения, и даже обновление для старых — не пройдет в маркет с этим legacy запросом разрешений, заставят переделать.
Вообще конечно система разрешений в андроиде не идеальна, согласен, многие вещи почему-то объединены, хотя по логике не должны быть. Те же вызовы с телефонной книгой, или вайфай с геолокацией. Но это уже вопрос к андроиду, надеемся что они таки починят это однажды.
Фитнес трекерам понятное дело нужен gps, и еще парочке приложений, но это неизбежно же. А вот приложения которые требуют чего-то, чего требовать не должны в принципе — нужно бойкотировать, но к сожалению большинство людей вообще не придает этому значения.
Вот если бы ОС могла просто скармливать фейковые/пустые данные приложению, если пользователь отказал в разрешении — это бы решило очень много проблем. Но гугл такое почему-то не хочет внедрять.
Вы говорите о древнем андроиде, уже давно все абсолютно не так. Разрешения выдаются по-отдельности, можно запретить/разрешить что-то конкретное. В меню приложений можно управлять разрешениями любого приложение, а так же можно посмотреть каким приложениям разрешено использовать локацию, например.
Другое дело что бессовестные разработчики иногда делают так, что приложение не работает без разрешения, даже если объективно оно могло бы работать. И если телефонную книгу или список вызовов не очень жалко, то вот локацию очень даже, и такие приложения я просто посылаю в пешее эротическое, но это редкость на самом деле. И то, даже телефонную книгу я не буду разрешать всем подряд, подумаю можно ли обойтись…
Что на андроиде, что на айфоне — приложение не может получить доступ к локации, не запросив разрешение пользователя. И если с навигаторами понятно, то зачем его давать, условно, текстовому редактору или просмотрщику фотографий?
Или все-таки какую-то информацию приложения могут получить без разрешения?
Конечно много людей используют микросервисы как дань моде, но на самом деле необходимость есть, в основном в действительно больших проектах с большим количеством разработчиках. Только наступает эта необходимость в каждом проекте по-разному, где-то может вообще не наступить, это чувствуется. Когда становится сложнее вносить правки, когда команды мешают друг-другу, когда сложность и запутанность кода выросла на столько, что джуна подпустить к проекту это долгий и сложный процесс, когда сами разработчики тупят или делают баги из-за чрезмерной запутанности. Еще есть технические причины, например когда по мере роста нагрузки нужно прооптимизировать какое-то место, но не получается из-за связности с другими частями, и это требует глубокого рефакторинга, затем повторить через месяц в другом месте. Ну и конечно же производительность — микросервисами дешевле и проще горизонтально масштабироваться.
В общем просто из-за моды это деньги на ветер, решение должно созреть на объективной почве.
В том что все изменения нужно согласовывать с разными сервисами, то есть с разной кодовой базой и возможно разными людьми. Это сильно сложнее чем пробежаться по монолиту.
Вот сколько статей уже перечитал про переход от монолита к микросервисам — никто и нигде не упоминал такую очень важную вещь как переиспользование кода.
В монолите содержится много разных utility классов, включая бизнес-логику, которые используются в разных частях (которые в итоге должны быть разными микросервисами). И как вот с этим быть? Копипастить код? Конечно нет, ведь бизнес-логика постоянно развивается. Выносить в подключаемые библиотеки? Во-первых это сработает только если все сервисы на одном языке. А во-вторых это сильно усложняет внесение правок в эти библиотеки — ведь раньше можно было сделать find usages по монолиту, а теперь по куче сервисов, да еще и отвечают за них разные люди. Использовать отдельный микросервис с бизнес-логикой? Тогда это будет монолит в миниатюре.
Если кто-то владеет информацией как решаются такие вопросы, или просто ссылкой на неё — буду благодарен.
Другая проблема — это низкая производительность доступа к файлам в линуксовой подсистеме из-под windows
Вот сейчас потестил время индексации большого PHP проекта на Laravel с кучей composer библиотек. Развернул две новых копии проекта — одну на винде, другую в WSL2, затем по очереди открывал в PhpStorm (на винде конечно) и замерял время индексации.
Результаты:
Windows — минута и 22 секунды
WSL — минута и 13 секунд
Ноут у меня такой: Core i7, 32 гига памяти, диск NVMe Samsung 960 EVO.
Так что все в порядке с доступом из винды на линукс, тормоза только при обратном доступе.
Я правильно понимаю — это как Google Authenticator, только не приложение в телефоне, а отдельное физическое устройство которое показывает коды на своем экране? Какая прелесть.
Когда я обнаружил проблему с моделями (профайлером), исправление ускорило код примерно на 30%. Пришлось сделать самодельный кэш атрибутов и использовать в нагруженных местах.
В нашем проекте есть json поля в базе, и много бизнес логики для них, соответственно обращение к таким атрибутам очень частое, и вот при каждом обращении под капотом вызывается json_decode/json_encode. Я был разочарован когда раскопал откуда тормоза пошли.
Второй пример это функция Arr::get(), а точнее ее использование. Она позволяет получить значение из вложенного массива передавая путь вида «path.to.value», и соответственно реализация содержит explode() и цикл по сегментам пути. Так вот очень важная функция config() под капотом вызывает ту самую Arr::get() при каждом обращении, никак не кэшируя результат. И если у вас где-то в большом цикле вызов config() — прощай производительность. Эта Arr::get() используется и некоторых в других местах аналогичным способом.
Это два ярких примера которые пришли в голову сразу, на самом деле там еще найдется. Вполне возможно что в вашем проекте это не актуально, но эти примеры отлично иллюстрируют подход разработчиков к вопросам производительности.
Тут я бы не был так уверен, все-таки прогресс в сторону юзабилити очень даже заметен. Скорее они просто не спешат наладить всю систему разрешений и привести ее к максимально идеальному виду, но тут опять же не все так просто. Эти кривые объединения разрешений были заложены изначально, практически в фундаменте, и чтоб теперь их разделить — нужно проделать очень много работы, при этом не забыв про совместимость со старыми приложениями.
Разрешения пачкой это legacy, так было в приложениях под старые версии андроида, и пока они продолжают работать. Но новые приложения, и даже обновление для старых — не пройдет в маркет с этим legacy запросом разрешений, заставят переделать.
Вообще конечно система разрешений в андроиде не идеальна, согласен, многие вещи почему-то объединены, хотя по логике не должны быть. Те же вызовы с телефонной книгой, или вайфай с геолокацией. Но это уже вопрос к андроиду, надеемся что они таки починят это однажды.
Фитнес трекерам понятное дело нужен gps, и еще парочке приложений, но это неизбежно же. А вот приложения которые требуют чего-то, чего требовать не должны в принципе — нужно бойкотировать, но к сожалению большинство людей вообще не придает этому значения.
Вот если бы ОС могла просто скармливать фейковые/пустые данные приложению, если пользователь отказал в разрешении — это бы решило очень много проблем. Но гугл такое почему-то не хочет внедрять.
Другое дело что бессовестные разработчики иногда делают так, что приложение не работает без разрешения, даже если объективно оно могло бы работать. И если телефонную книгу или список вызовов не очень жалко, то вот локацию очень даже, и такие приложения я просто посылаю в пешее эротическое, но это редкость на самом деле. И то, даже телефонную книгу я не буду разрешать всем подряд, подумаю можно ли обойтись…
Или все-таки какую-то информацию приложения могут получить без разрешения?
В общем просто из-за моды это деньги на ветер, решение должно созреть на объективной почве.
В том что все изменения нужно согласовывать с разными сервисами, то есть с разной кодовой базой и возможно разными людьми. Это сильно сложнее чем пробежаться по монолиту.
В монолите содержится много разных utility классов, включая бизнес-логику, которые используются в разных частях (которые в итоге должны быть разными микросервисами). И как вот с этим быть? Копипастить код? Конечно нет, ведь бизнес-логика постоянно развивается. Выносить в подключаемые библиотеки? Во-первых это сработает только если все сервисы на одном языке. А во-вторых это сильно усложняет внесение правок в эти библиотеки — ведь раньше можно было сделать find usages по монолиту, а теперь по куче сервисов, да еще и отвечают за них разные люди. Использовать отдельный микросервис с бизнес-логикой? Тогда это будет монолит в миниатюре.
Если кто-то владеет информацией как решаются такие вопросы, или просто ссылкой на неё — буду благодарен.
Вот сейчас потестил время индексации большого PHP проекта на Laravel с кучей composer библиотек. Развернул две новых копии проекта — одну на винде, другую в WSL2, затем по очереди открывал в PhpStorm (на винде конечно) и замерял время индексации.
Результаты:
Windows — минута и 22 секунды
WSL — минута и 13 секунд
Ноут у меня такой: Core i7, 32 гига памяти, диск NVMe Samsung 960 EVO.
Так что все в порядке с доступом из винды на линукс, тормоза только при обратном доступе.