Потому, что IT на высшем уровне - это о том, чтобы не делать одну и ту же работу два раза, отказ от ручного труда, а для этого нужно каждый раз проводить НИОКР - не все могут строго декомпозировать, формализовать и алгоритмизировать задачу на компоненты, которые можно переиспользовать.
Сегодня утром при попытке создать образ возникла проблема к попытке подключения к dockerhub. Причем эти люди с альтернативными сексуальными предпочтениями даже не указали Россию в список стран под запретом:
403 Forbidden Since Docker is a US company, we must comply with US export control regulations. In an effort to comply with these, we now block all IP addresses that are located in Cuba, Iran, North Korea, Republic of Crimea, Sudan, and Syria. If you are not in one of these cities, countries, or regions and are blocked, please reach out to https://hub.docker.com/support/contact/
Думаю, для тех кто знаком с данным сервисом понимают последствия.
Решение появилось достаточно быстро - https://huecker.io/. Также при работе через VPN проблем также не возникает
Всем привет!
Я обычный программист город Тверь, никогда не проектировал софт и не был архитектором.
Но очень горю желанием сделать наконец уже свой серьезный проект.
Много раз пытался делать разные проекты, и пришел к выводу, что мне очень не хватает компетенции в сфере планирования и проектирования. Пока я знаю, что и как делать, то проект растет. Но без четкого плана на голом энтузиазме я держусь недолго.
Я надеюсь, что здесь есть люди, которые в этом разбираются, и которые были бы рады помочь неофиту.
В общем, я пришел к выводу, что мне нужно перед любой разработкой проследовать по такому плану:
Составить документы по 5 конкурентам, в которых перечислить:
- Функционал детально
- Страницы, пункты меню
- Entities и их поля
- Взаимосвязи, сценарии
- Какие есть роли
- Функционал по разным ролям
- Что редактируется, когда редактируется, кем редактируется
Смержить эти документы и получить MVP, в котором будет прописан функционал, entities and fields, взаимосвязи и сценарии, роли, функционал по ролям и т.д.
На основе выше полученного спроектировать базу данных.
Потом разбить на задачи по страницам, по сценариям, по ролям.
Детально прописать задачи, какие поля на странице, какие placeholders, опции селектов.
Заказать реализацию дизайна для каждой задачи.
Начать реализацию кода.
Подскажите пожалуйста, все ли я правильно понял, и может быть я что-то упустил?
Всем привет, в последние годы я исследую Искусственный Интеллект, мой контент об этом можно найти на канале Ruslan Dev на YouTube. В этой статье я расскажу о том, как я сделал файнтюнинг Llama 3 70B - лучшей базовой модели на сегодняшний день. Я обучал модель на мультиязычном датасете Tagengo, в котором есть русскоязычная выборка.
Очевидно, обучение такой модели требует серьезных вычислительных мощностей, поэтому полного цикла на 3-4 эпохи я делать не стал. Я рассчитывал потратить пять-десять GPU-часов, чтобы проверить мой код для файнтюнинга на работоспособность, посмотреть метрики обучения, запустить инференс модели и оценить первые результаты.
Кстати, для файнтюнинга моделей я использую свой фреймворк gptchain, который построен на основе библиотек unsloth и trl (Transformer Reinforcement Learning).
Моей второй целью была квантизация обученной модели и сохранение в формате GGUF. Этот формат позволяет запустить Большую Языковую Модель (LLM) на любом компьютере с достаточно мощным процессором.
Базовая модель, которую я файнтюнил - unsloth/llama-3-70b-bnb-4bit. Cначала я проверил, как эта модель справляется с русскоязычным промптом, задав ей вопрос - "Из чего состоит нейронная сеть?"
Очевидно, что базовая модель не обучена следовать инструкциям. Она просто повторяла мой вопрос, итерация за итерацией, пока генерация не достигла максимальной заданной длины. Я рассчитывал на то, что после файнтюнинга модель будет следовать инструкциям на русском языке.
Я обратился к облачному GPU сервису immers.cloud. чтобы обучить модель.
Сначала я собирался обучать на нескольких видеокартах параллельно и выбрал два GPU A100 c NvLink.
Однако, я не учел тот факт, что библиотека unsloth, которую я использую в моем фреймворке, еще не поддерживает model parallelism, а это серьезное ограничение. В их дискорде нашел пост, что в ближайшее время обучение на нескольких GPU станет возможным. Если этого не случится, мне придется искать альтернативные пути.
Поскольку файнтюнинг базовой модели Llama 70B c квантизацией в 4 bit на 3 эпохи на одном A100 требует порядка 5 дней, мне пришлось сократить количество шагов обучения.
Также я решил перейти на другую видеокарту - H100, самую мощную из того что есть.
Настройка рабочего окружения у меня довольно простая. Мне нужен только python >= 3.9, а затем клонирую свой фреймворк gptchain с github:
И устанавливаю его зависимости:
pip install -r requirements-train.txt
Весь код, который понадобится мне для файнтюнинга, запускается через консольный интерфейс фреймворка.
После обучения веса модели мержатся с параметрами LoRA, полученными в процессе файнтюнинга, их можно загрузить на Huggingface.
Я использовал датасет lightblue/tagengo-gpt4.
На странице датасета заявлено, что "Tagengo - самый большой в мире мультиязычный датасет высокого качества". 78 тысяч примеров диалога на разных языках, включая русский. Здесь есть серьезная выборка на русском - 8 тысяч строк.
Я обучил модель на 2,400 шагов, на это ушло 7 часов на H100.
python gptchain.py train -m unsloth/llama-3-70b-bnb-4bit \
--dataset-name tagengo_gpt4 \
--save-path checkpoints/llama-3-70b-tagengo \
--huggingface-repo llama-3-70b-tagengo \
--max-steps 2400
Если использовать A100, по моим расчетам, потребовалось бы примерно 10 часов.
Я запустил файнтюнинг на Виртуальной Машине в бэкграунд-процессе. Для этого я воспользовался systemd, стандартным способом создания фоновых процессов (демонов) в Linux.
Я создал файл gptchain.service в /etc/systemd/system. В него вставил вот такую конфигурацию:
[Unit]
Description=Llama-3-70b finetune
[Service]
WorkingDirectory=/home/ubuntu/gptchain
ExecStart=/home/ubuntu/venv/bin/python gptchain.py train --model_id unsloth/llama-3-70b-bnb-4bit --dataset-name tagengo_gpt4 --save-path checkpoints/llama-3-70b-tagengo --huggingface-repo llama-3-70b-tagengo --max-steps 2400
Type=simple
Restart=no
Здесь главное - команда gptchain.py train, которая запускает файнтюнинг модели.
А теперь нужно выполнить:
sudo systemctl daemon-reload
sudo systemctl start gptchain
И все, остается ждать завершения файнтюнинга, но метрики вроде Train Loss хотелось бы как-то отслеживать. Самое простое - посмотреть логи процесса:
journalctl -u gptchain.service
Чтобы иметь возможность нормально наблюдать метрики, лучше, конечно, использовать wandb или tensorboard.
В этот раз я использовал wandb - просто указал ключ доступа в переменной WANDB_API_KEY в файле .env. Мой процесс подключается к wandb автоматически и экспортирует метрики в реальном времени.
К базовой модели применяется LoRA (Low Rank Adaptation), метод, позволяющий файнтюнить параметры более эффективно - исходная матрица параметров оставляется неизменной ( "замораживается"). В процессе обучения изменяется представление параметров модели в виде двух матриц более низкой размерности. Реализация LoRA, с которой мы обычно имеем дело, работая на стеке Huggingface Transformers (как и в данном случае) - через библиотеку peft.
Дальше происходит загрузка датасета и приведение к нужной структуре. Данные в Tagengo представлены в виде массивов json, какие принимает и возвращает OpenAI API. Чтобы использовать эти данные для файнтюнинга, я сконвертировал их в формат ChatML. У библиотеки Unsloth есть хорошая поддержка СhatML, что мне очень помогло конвертировать данные из вот этого:
[
{
"from": "human",
"value": "The user’s message goes here"
},
{
"from": "gpt",
"value": ""
}
]
Вот в это:
<|im_start|>user
The user’s message goes here
<|im_end|>
<|im_start|>assistant
Следующее, что происходит в моем коде - конфигурируется экземпляр Supervised Fine-tuning Trainer (SFTTrainer) - класса, предоставленного библиотекой trl. В нем задаются параметры файнтюнинга.
Основные из них:
learning_rate: 2e-4
seed: 3407
gradient_accumulation_steps: 4
per_device_train_batch_size: 2
optimizer: adamw_8bit
lr_scheduler_type: linear
warmup_steps: 5
max_steps: 2400
weight_decay: 0.01
Через семь часов файнтюнинг завершился. Я убедился, что Train Loss медленно, но верно сходится. Хотелось бы обучить на несколько полных эпох, но, как я уже говорил, надо значительно больше GPU часов. Обучать нужно минимум на 2, а лучше на 4 видеокартах параллельно.
Затем я проверил, начала ли Llama следовать инструкциям на русском языке:
python gptchain.py chat -m checkpoints/llama-3-70b-tagengo \
-q '[{"from": "human", "value": "Из чего состоит нейронная сеть?"}]' \
--chatml true
Да, начала - вместо бессмысленных повторений я получил правильный, очень подробный ответ на вопрос "Из чего состоит нейронная сеть?" Рекомендую посмотреть видео, чтобы оценить качество ответа и скорость инференса Llama 3 70B на H100.
Стиль ответа напоминает GPT-4, это длинный детализированный текст. Неудивительно, так как датасет tagengo включает именно ответы GPT-4.
Затем я выполнил квантизацию модели и сконвертировал ее в формат GGUF, чтобы ее можно было запускать без GPU, на обычном процессоре.
Для этого в моем фреймворке есть консольная команда quant. Среди прочих аргументов она принимает метод квантизации. В интерфейсе llama.cpp, который используется под капотом, есть также полезная команда quantize --help, которая покажет много полезной информации по методам квантизации, в том числе какие из них рекомендуются в плане баланса качества модели, скорости инференса и размера файла. Я воспользовался методом q4_k_m:
python gptchain.py quant -m checkpoints/llama-3-70b-tagengo \
--method q4_k_m \
--save-path quants/llama-3-70b-tagengo \
--huggingface-repo llama-3-70b-tagengo-GGUF
Для Llama 3 70B непосредственно квантизация занимает примерно полчаса, перед этим еще произойдет сборка llama.cpp из C++ исходников, что необходимо для конвертации весов модели в GGUF формат.
В итоге вы получите файл gguf в папке quants, его можно запустить с помощью llama.cpp.
Я задал модели тот же вопрос "Из чего состоит нейронная сеть?", и модель начинала генерировать просто completion - завершила фразу, выдала в конце токен end-of-text и остановилась.
Это потому, что я не задал формат промпта. Здесь ведь нет автоматической конвертации инпута в формат СhatML, которую мне обеспечивал Unsloth при инференсе несжатой модели.
Я задал формат ChatML вручную и запустил еще раз:
llama.cpp/main -m quants/llama-3-70b-tagengo-unsloth.Q4_K_M.gguf \
-p "<|im_start|>user \nИз чего состоит нейронная сеть?<|im_end|>"
Модель на этот раз поняла, что от нее хотят. Она сгенерировала ответ в нужном формате.
Это такой же развернутый ответ в том же стиле, что у несжатой модели. Но инференс GGUF значительно медленнее, чем на GPU. Зато вы можете запустить этот файл на любом компьютере, лишь бы хватило мощности CPU, иначе инференс будет длиться вечность.
Однако ближе к концу ответа модель стала генерировать странную последовательность обратных слэшей и других символов. У несжатой модели такого дефекта не было. Возможно, если бы файнтюнинг был проведен полностью, эта проблема бы не возникла.
Тем не менее, в целом мне понравилось качество ответов обеих моделей - с квантизацией и без. Я бы хотел протестировать свою модель на разных бенчмарках, например MT-Bench, в особенности меня интересуют результаты для русского языка. Это, вероятно, тема для новой статьи. А пока я рекомендую посмотреть видео о том, как происходил файнтюнинг, описанный в этой статье.
Веса моей модели можно скачать с Huggingface:
И хорошо если пчелки правда знают о проблеме и работают над ее исправлением, но на деле чаще всего вы не видите даже этой ошибки, а просто ждёте бесконечный прогресс бар ... нет, прогрессбар - это про какой-то прогресс, процесс, с хотя бы отдалённо и приблизительно понятной продолжительностью.
Даже эти нехитрые технологии были потеряны
Отголоски развитой цивилизации и сейчас можно найти в виде скриншотов в сети:
Что мы можем увидеть на прогресс-баре здорового человека
На хорошем прогресс-баре мы видим что, собственно, присходит, сколько элементов обрабатывается, общий процент выполненной работы (5), сколько примерно времени потребуется (4), сколько объектов и гигабайтов осталось обработать (2), скорость передачи данных (3), тот же процент но наглядно в виде заполнения бара (1) и даже график изменения скорости обработки данных!
Кстати, давно не пользуюсь windows, но, кажется, там сейчас такой или похожий прогресс-бар на копирование файлов, но...
Но во всех стальных местах где пользователю приходится ждать, его буквально заставляют СТРАДАТЬ!
Я не знаю кто это придумал, но уверен, что сам адский сатана его большой поклонник.
Установка программы, перезагрузка системы, ОБНОВЛЕНИЕ! Какого черта нигде не пишется даже сраный процент прогресса?! Порой вот эта тупая анимация просто крутится в виде зацикленной гифки, и она вообще никак не связана с процессом. Криворукие разработчики зачастую даже не думают потрудиться и сделать ожидание пользователя чуть более предсказуемым по времени и информативным.
Да ладно "по времени", иногда глядя на анимацию не понятно закончится этот процесс вообще когда-нибудь, или что-то там уже бесповоротно сломалось, а анимация эта бесконечная, на экране по-прежнему висит надпись "осталось совсем немножко, подождите, пожалуйста", и так ждать можно до тепловой смерти вселенной!
Неужели только меня одного бомбит от всего этого?
Сейчас придёт кто-нибудь в комменты защищать тугосерь-разработчиков, мол, ненуачо, ненуим манагер сказал так сделать, ненуакак они узнают сколько осталось, когда кампуктеры у всех разной производительности, интернет-соединение разное и, возможно, нестабильное, количественный прогресс может нелинейно зависеть от времени.
Ну так да, дорогие коллеги, в решении этих сложностей и заключается наша с вами профессия!
Ничего невозможного тут нет, а сделать лучше чем сейчас в 99% местах вообще не сложно.
Кто мешает эмпирически подобрать более адекватную кусочно-полиномиальную формулу аппроксимации? Кто мешает собрать статистику у контрольной выборки пользователей и выявить закономерности длительностей разных этапов процесса от примерного уровня оборудования? Кто мешает в ходе самого прогресса замерять скорость тех или иных операций, чтобы предсказать общее время процедуры. Хотя бы очень приблизительно. Хотя бы оценкой сверху "если ничего непредвиденного и редкого не случится".
Кто-то скажет, что, мол, радуйтесь, что вот, к примеру, при загрузке системы вам хоть анимацию с приятной картинкой показываем, а так вообще черный экран был бы. Ведь как пробросишь подробности процесса в тупой фронтенд? А так и пробросишь! Чуть поострее сделать фронт, чуть больше интроспекции, немного статистики и, вуа-ля, у вас дружелюбный информативный интерфейс, а не вот это вот вращающееся бесконечное говно на палочке.
И напоследок. Не надо считать пользователя идиотом, но и оставлять наедине со своими проблемами без какой-либо информации - тоже не надо. Правильная обработка handled и unhandled исключений изучается в институте, но это не рокет-сайнс, тут можно освоить базовые премудрости.
Пользователю должно быть понятно, что что-то пошло не так, ему должно быть понятно имеет ли смысл и имеется ли возможность решать как-то возникшую проблему, или стоит сразу в ужасе удалить поделку неграмотных "погромистов", чтобы не терять время и искать уже более качественный софт.
Винда, кстати, тоже не безгрешная, в плане наплевательства на удобство пользователя при ожидании. Чего стоит только вот это вот внезапное желание обновиться. Сколько было случаев, когда винде (и не только) приспичило срочно обновиться, когда горят сроки и нужно доделать курсовую, или срочно надо распечатать документы, или быстро скопировать нужный файл, или целая аудитория ждёт презентации на подключенном к проектору ноутбуке...
21 век на дворе! Пора делать все эти побочные процессы, которые не нужны, по сути, пользователю, просто незаметными и НИКАК не затрагивающими пользовательский опыт.
Пора писать софт везде так, как это делали для Вояджеров и марсоходов. Предсказуемо, конфигурируемо, надёжно. Что стоит при обновлении делать равнозначный клон ядра операционной системы и обновлять его, а не работающю систему? Потом "щёлк" и у вас обновленный софт! Что мешает? Техническая сложность? Ну так пора сделать это важным техническим преимуществом, чтобы была конкуренция за такое удобство.
Простите, друзья, что-то меня подорвало снизу. Отбомбил. Думаю эта статья уже малость припоздала лет эдак на 10. Сейчас проблема, может быть, уже стоит не так остро, компы у нас быстрые, каналы широкие, нервы правда ни к черту, ну да что поделаешь...
Картинки для иллюстрации взяты из сети, а эмоции из глубин воспалённого мозга.
Добрый день! Нужен совет программиста. У знакомого есть местячковый сайт, указывать название не буду, чтобы за рекламу не приняли. Содержание сайта – всякие интервью с директорами компаний и полезные статейки для бизнеса. Сайту уже 23 года, сам сайт на Вордпрессе уже 4 год (раньше был самописный).
Человек хостится на Рег.ру с тарифом Host-3. Недавно (после предупреждения) хостер выключил сайт потому что нагрузка на CPU за 7 дней составила 23% при допустимой в 13%.
Хозяин сайта в силу возраста попросил меня по знакомству посмотреть и поправить по возможности ситуацию. Я ни айтишник ни разу, но почитав помощь хостинга, разблокировал, увидел, что с конкретных ip адресов и ботов идет куча запросов.
Заблокировал эти адреса через плагин Wordfence в админке, Заблокировал адреса также в htaccess. Там же, в htaccess заблокировал бота ClaudeBot с 42000 запросов, а так же 5 000 ежедневных запросов от бота facebook.
Техподдержка ответила хозяину сайта тоже самое, что я уже сделал и прислала правило в файл .htaccess, предложив еще добавить фильтрацию траффика с их стороны (не знаю за сколько денег).
Сегодня зашел в админку и вижу что все эти блокировки моих "знакомых" IP адресов вообще пофигу. Как пытались зайти, так и пытаются.
Вопросы: 1)Можно ли сделать так, чтобы эти адреса действительно заблокировать и как это сделать? 2)Правильно ли я вписал директиву в htaccess? 3)Не получится ли, что вместо этих IP адресов прийдут на смену другие?
P.S. Убрал на всякий случай часть цифр, во избежании всякого разного. Еще раз хочу сказать, что я не программист и если у кого есть желание ответить, просьба максимально простым языком написать. Шутки люблю, но хотелось бы решить ситуацию.
Скрин с хостинга
Скрин с хостинга по запросам
Привет.
TLDR: Вся боль в заголовке. Как научить поделие китайских инженеров нормально отдавать и регулировать звук?
К делу. В общем, сидела моя жена все время на винде и горя не знала, но тут решила попробовать себя в linux и попросила меня катнуть рядом с виндой какой-нибудь дистрибутивчик не сильно замороченого линукса. Почесав немного репу и со словами "Да ща 5 сек делов то на 15 минут"
Приблизительно так я себе это и представлял
Выбор мой пал на Mint(M)/Ubuntu cinnamon(UC)/Ubuntu Budgie(UB). Существенная разница лишь в том, какой релиз стоит под капотом. То есть 22.04 lts/23.10/24.04 lts
И вот через 10 минут, я уже отдал комп жене с M со словами "пользуйся" и гордый пошел в свой кабинет дописывать код.
Ничего не предвещало беды, но ровно через 10 минут с кухни послышалось "А чо со звуком?".
Тут то и начались мои танцы с бубном.
Начал разбираться, действительно. Звука есть, но очень тихий и не регулируется через клавиши мультимедиа и ползунком громкости. aplay -l и cat /proc/asound/cards говорят, что звуковая карта есть и висит как card0. в alsamixer она определяется как sof-hda-dsp и при этом при нажатии мультимедиа клавиш ползунок в Speaker ползет вниз и ничего не происходит ровно до момента когда он доходит до конца и активирует режим mute. Отключается Master и Speaker каналы. Обратно такая же ситуация, то есть звук при нажатии + появляется (размьют) и больше, собственно, ничего. Пробовал и HWE и OEM ядра - эффект одинаков.
Путем нехитрых манипуляций было выявлено, что либо в драйвере либо в HW перепутаны каналы Headphone и Speaker. То есть если делать программно amixer set Headphone 10+ то звук прибавляется, так же и убирается. При этом подключение наушников происходит штатно - Headset нормально работает от ползунка громкости и от мультимедиа клавиш.
Гугл выдал мне 500 топиков боли и страданий, но почти все рекомендации я проделал до них, либо не помогли, либо сделали хуже (Окей, спасибо, гугл:) )
Перебиндил пока клавиши мультимедиа на выполнение команды amixer set $HW_OUTPUT_SET 5+/- где сама $HW_OUTPUT_SET формируется через сервис, который раз в 2 милисекунды опрашивает /proc/asound/cards на наличие/отсутствие карты Earphones и делая нужное мне значение переменной. Но это изврат какой-то :))
Поможите, люди добрый, кто сталкивался с таким и решил проблему - не дайте посрамить честь :))
ПыСы: UC вообще не определила звуковую карту и не смогла запустить pulseaudio. UB - +/- как на минте, но игрался только на liveCD и не могу обновить ядро, так что может там и получше.
ПыСы2: Воткнул все 3 версии флешкой себе в Lenovo ThinkPad - везде работает корректно звук :(
Привет тебе, всякий читающий! Сегодня расскажу о том, как я проводил оптимизацию одного из своих сайтов с нуля, чего в результате добился, и для чего это вообще всё надо.
Результат оптимизации сайта
Есть сайт на PHP 8.1, Laravel. Под базу взят PostgreSQl. На фронте нативный JS. За основу взят шаблон от Metronic, дабы не делать всё с нуля.
Страниц на сайте больше 2 миллионов. Контент собирался в результате сбора информации с множества источников.
Первоначальная оценка по Google Page Speed была не очень - 36 на мобильных устройствах и 80 на компьютере.
Это мобилки
Это компьютер
Вроде бы на компьютерах выглядит всё адекватно, но не тут то было. Сейчас все поисковики смотрят скорость именно по мобильным устройствам и акцент делают именно на них.
Наша цель - довести показатели на мобилках до максимума.
Поехали проводить аналитику по шагам.
Идём на гитхаб и устанавливаем через композер расширение. Там всего пару кликов, каждый уважаемый программист сделает самостоятельно.
После успешной установки при заходе на страницу (не забудьте в настройках в файле .env поставить APP_DEBUG=true) внизу слева страницы появится иконочка, при клике на которую откроется панель с кучей вкладок.
Залазим во вкладку Queries и смотрим все запросы, которые есть на странице. Получается что-то такое.
Красным отмечена суммарная продолжительность выполнения.
Я использую PHPStorm для работы с базой. Вы же можете использовать что-то иное, это не принципиально.
На этой вкладке нужно проанализировать вызов запросов. Для начала я увидел, что при выводе списка статей в цикле вызывается ещё один дополнительный запрос. Сделал всё в 1 запросе. Это практически минус 12 запросов со страницы. Такие моменты нужно анализировать глазками и оптимизировать под каждый проект самостоятельно.
Далее я взял КАЖДЫЙ запрос и проанализировал план его выполнения. Вот пример:
Смотрим здесь Total Cost
Как видим здесь нет никаких индексов. Лечится это легко. Смотрим по каким полям у нас происходят условия и с какой сортировкой. Затем создаём индекс по этим полям и смотрим результат. Вот что получилось у меня:
А вот результат после создания индексов
Мы оптимизировали запрос с 17к до 207. И это только один пример.
Вот пример простейшего запроса без индекса
А вот результат после создания индекса
Так мы должны пройти по каждому запросу на каждой странице и проанализировать их работу. Вполне возможно, что можно отказаться от каких-то таблиц, лишних джоинов и т.д.
Ещё я советую проанализировать таблицы, которые можно было бы разбить на партиции.
Пример: у нас есть аналитика по годам в одной таблице с 1 миллионом записей. Вы постоянно забираете аналитику на текущий год и выводите пользователю. Здесь так и напрашивается деление таблицы по годам, а может даже и по месяцам. В результате запрос будет идти по ограниченному набору данных, а не по всем данным за всё время.
Результат после оптимизации запросов
Как видим уже есть сподвижки. Работаем дальше.
Сайт грузит очень большое количество различных картинок, css'ов и js'ов. Пришла мысль всё это дело закешировать, чтобы быстро отдавать из оперативной памяти, а не лезть на жёсткий диск.
Для своих проектов я использую VarnishCache, т.к. уже привык и у него очень гибкая настройка.
Если вы используете Laravel, то есть вот такое расширение, чтобы подружить варниш с ларкой:
А вот здесь есть классное руководство по настройке:
А вот ещё ссылочка с конфигом. Если у вас другая версия варниша - поменяйте в урле версию и будет вам счастье.
Я добавил в кеш все js, css и картинки. Будьте крайне внимательны с настройкой. Можно, например, закешировать POST-запросы с формами или какие-то JSON-Ответы. Советую прогонять тестами сайты после добавления таких модулей.
Здесь шаг очень простой. Нужно проанализировать утилизацию ресурсов на вашем сервере. Посмотрите сколько используется процессора, памяти, места. Я на этом этапе просто взял и купил сервер в 2 раза мощнее, дабы мне хватило ресурсов с лихвой.
У меня в проекте использовался дефолтно сборщик webpack и правила на нём были крайне простыми - берём все файлы и засовываем в единый файл bundle.
Представьте, что на КАЖДОЙ странице забираются все js-библиотеки и css. Это очень сильно усложняет вывод страницы, при этом делает работу программиста легче. Не надо думать что и когда подрубить. Просто подключаешь любую компоненту и она работает! Ну не прелесть ли. Но не для поисковиков.
Пришлось переписать сборку. В результате теперь вместо одного большого файла у меня будет парочка сотен небольших. При этом нужно следить за последовательностью их подключения, переписать все страницы и т.д. Да, переписывать готовый проект очень сложно, и очень велика вероятность ошибки. Но на то мы и специалисты, чтобы делать всё качественно, не правда ли?
Классным дополнением будет пул коннектов к базе. Для PostgreSQL я использую PgBouncer. Можете скачать по ссылке ниже.
Пул коннектов позволяет держать постоянные соединения с базой данных для уменьшения потерь при подключений к ней. Вот здесь можете почитать официальную документацию:
Я установил расширение на Laravel для отлова мобильных устройств. качал отсюда:
Далее в коде для мобилок сделал другую вёрстку, более простую, чем в версии для компьютеров. Вырезал половину анимации, блоки с картой, ненужные слайдеры. Такой вариант поможет уменьшить DOM страницы и ускорит её отображение.
Смотрим полученный результат
Можно ещё пытаться оптимизировать файлы и запросы. Я не использовал Reddis для кеширования запросов, но вы можете тоже использовать этот метод.
По капельке можно легко оптимизировать большинство страниц. Благодаря такому подходу ваши сайты смогут быстро улучшить свои позиции в выдаче и увеличить конверсию.
Буду благодарен за подписку на мой tg-канал, если материал был полезен.
