Конвертер шрифтов
Если нужно конвертнуть шрифт во все форматы. На выходе архив со шрифтом в разных форматах и CSS-файл с подлючением.
https://transfonter.org/
Если нужно конвертнуть шрифт во все форматы. На выходе архив со шрифтом в разных форматах и CSS-файл с подлючением.
https://transfonter.org/
❤12👍9🔥5
Нарабатываю привычку задавать вопросы ИИ вместо поисковика. Последнее время делаю это каждый день. Не всегда идеально, но прикольно. Возможность обсудить любой вопрос со специалистом по всем вопросам 😁
Недавно надо было сделать быстрый перевод сайта на английский язык. Отправить ИИ файл (json) с текстами на русском, получил в ответ такой же с переводами, вставил в проект и готово 🚀
Так что пользуйтесь тоже, привыкайте, учитесь правильно задавать вопросы и получайте профит. Сегодня наша работа стала такой простой, как никогда, благодаря крутым инструментам 🔥
Недавно надо было сделать быстрый перевод сайта на английский язык. Отправить ИИ файл (json) с текстами на русском, получил в ответ такой же с переводами, вставил в проект и готово 🚀
Так что пользуйтесь тоже, привыкайте, учитесь правильно задавать вопросы и получайте профит. Сегодня наша работа стала такой простой, как никогда, благодаря крутым инструментам 🔥
🔥7👍2👌2
Сегодня в VIP-канале вышел очередной (25й) урок из курса по аутентификации.
В уроке для разнообразия использовали Livewire, чтобы реализовать переход по ссылкам и функционал без обновления страницы и без написания кода на JavaScript. Быстро, просто и красиво.
Очень нравится Livewire, для ленивых веб-ремесленников самое то 😁
В уроке для разнообразия использовали Livewire, чтобы реализовать переход по ссылкам и функционал без обновления страницы и без написания кода на JavaScript. Быстро, просто и красиво.
Очень нравится Livewire, для ленивых веб-ремесленников самое то 😁
👍6❤3🔥1🤣1
Новая версия поиска от Яндекса, которая по нашему запросу анализирует несколько релевантных сайтов и выдаёт ёмкий ответ.
При этом можно продолжить диалог, чтобы задать уточняющие вопросы. Прикольно!
Заценить: https://ya.ru/?neuro=1
@onecode_blog 👈
При этом можно продолжить диалог, чтобы задать уточняющие вопросы. Прикольно!
Заценить: https://ya.ru/?neuro=1
@onecode_blog 👈
👍6🔥2❤1
Серверы и масштабирование Часть 1 Серверы
Бывает такое, что при запуске проекта говорят, что сразу нужно подготовить серверы к нагрузке и масштабированию без остановки приложения. В этом случае я обычно создаю несколько серверов:
1. Балансировщик нагрузки (LoadBalancer). Этот сервер стоит на передовой и принимает все HTTP-запросы к приложению. На сервере стоит веб-сервер Nginx, который проксирует (перенаправляет) запросы к одному из серверов приложений по локальной сети. То есть он скрывает за собой серверы с приложением и распределяет запросы (нагрузку) между ними. На балансировщике стоит SSL-сертификат, таким образом остальные серверы НЕ требуют его установки, тк их общение проходит в локальной (закрытой) сети.
2. Сереры приложения (Application1). Их может быть несколько, но в начале создаю один нужной конфигурации для обработки ожидаемого количества запросов. На этом сервере тоже установлен Nginx, который принимает запросы от балансировщика (первый сервер) и направляет их в приложение - PHP, PHP-FPM, Laravel.
3. Сервер очередей (Queue). Этот сервер НЕ принимает запросы, а занимается только обработкой задач в очереди. На нём так же работают задачи по расписанию, запускаемые ежеминутно через CRON. Тут стоит PHP и тоже самое приложение на Laravel. Очереди с помощь Laravel Horizon.
4. WebSocket-сервер (WS). Это опциональный вариант, если для приложения требуется обновление данных на клиенте в реальном времени. Вместо этого сервера можно использовать внешние сервисы, такие как Pusher и Ably (раньше использовал оба). Или развернуть на этом сервере свой вебсокет-сервер на JavaScript, например Soketi (использовал). Или развернуть тоже самое приложение на Laravel с новым пакетом Laravel Reverb (использую сейчас). На этом сервере подключен отдельный домен с SSL для обработки входящих подключений и Nginx, который перенаправляет запросы на сам вебсокет-сервер.
Что даёт это разделение? А то, что application серверы скрыты за балансировщиком, позволяет незаметно добавлять новые серверы по мере необходимости. Например нужно увеличить мощность application сервера (вертикальное масштабирование) - тогда просто создаём новый application сервер бОльшей мощности, разворачиваем на нём приложение и говорим балансировщику, чтобы он все запросы отправлял на него, а старый (маленький) application сервер удаляем.
Таким образом для увеличения мощности сервера НЕ пришлось останавливать работу сайта. Или другой вариант - просто добавить второй такой же application сервер (горизонтальное масштабирование), балансировщик будет разделять все запросы между двумя серверами и опять же без остановки приложения. Так можно добавлять еще сервера в будущем по мере роста нагрузки.
Что касается сервера очередей и вебсокет-сервера, то их в этой схеме не получится увеличить без простоя, то есть пока сервер выключен (увеличивается), задачи в очереди обрабатываться не будут, а когда включится - обработка продолжиться. Обычно это занимает 2 минуты, поэтому для очередей это не так критично, а сам сайт продолжает работу. С вебсокетами аналогично. Не вижу смысла здесь сильно запариваться.
Нужно продолжение? С тебя лайк и репост! @onecode_blog 👈
#servers #devops
Бывает такое, что при запуске проекта говорят, что сразу нужно подготовить серверы к нагрузке и масштабированию без остановки приложения. В этом случае я обычно создаю несколько серверов:
1. Балансировщик нагрузки (LoadBalancer). Этот сервер стоит на передовой и принимает все HTTP-запросы к приложению. На сервере стоит веб-сервер Nginx, который проксирует (перенаправляет) запросы к одному из серверов приложений по локальной сети. То есть он скрывает за собой серверы с приложением и распределяет запросы (нагрузку) между ними. На балансировщике стоит SSL-сертификат, таким образом остальные серверы НЕ требуют его установки, тк их общение проходит в локальной (закрытой) сети.
2. Сереры приложения (Application1). Их может быть несколько, но в начале создаю один нужной конфигурации для обработки ожидаемого количества запросов. На этом сервере тоже установлен Nginx, который принимает запросы от балансировщика (первый сервер) и направляет их в приложение - PHP, PHP-FPM, Laravel.
3. Сервер очередей (Queue). Этот сервер НЕ принимает запросы, а занимается только обработкой задач в очереди. На нём так же работают задачи по расписанию, запускаемые ежеминутно через CRON. Тут стоит PHP и тоже самое приложение на Laravel. Очереди с помощь Laravel Horizon.
4. WebSocket-сервер (WS). Это опциональный вариант, если для приложения требуется обновление данных на клиенте в реальном времени. Вместо этого сервера можно использовать внешние сервисы, такие как Pusher и Ably (раньше использовал оба). Или развернуть на этом сервере свой вебсокет-сервер на JavaScript, например Soketi (использовал). Или развернуть тоже самое приложение на Laravel с новым пакетом Laravel Reverb (использую сейчас). На этом сервере подключен отдельный домен с SSL для обработки входящих подключений и Nginx, который перенаправляет запросы на сам вебсокет-сервер.
Что даёт это разделение? А то, что application серверы скрыты за балансировщиком, позволяет незаметно добавлять новые серверы по мере необходимости. Например нужно увеличить мощность application сервера (вертикальное масштабирование) - тогда просто создаём новый application сервер бОльшей мощности, разворачиваем на нём приложение и говорим балансировщику, чтобы он все запросы отправлял на него, а старый (маленький) application сервер удаляем.
Таким образом для увеличения мощности сервера НЕ пришлось останавливать работу сайта. Или другой вариант - просто добавить второй такой же application сервер (горизонтальное масштабирование), балансировщик будет разделять все запросы между двумя серверами и опять же без остановки приложения. Так можно добавлять еще сервера в будущем по мере роста нагрузки.
Что касается сервера очередей и вебсокет-сервера, то их в этой схеме не получится увеличить без простоя, то есть пока сервер выключен (увеличивается), задачи в очереди обрабатываться не будут, а когда включится - обработка продолжиться. Обычно это занимает 2 минуты, поэтому для очередей это не так критично, а сам сайт продолжает работу. С вебсокетами аналогично. Не вижу смысла здесь сильно запариваться.
Нужно продолжение? С тебя лайк и репост! @onecode_blog 👈
#servers #devops
👍55🔥8❤1
Серверы и масштабирование Часть 2 Базы данных
Вчера говорили про серверы, на которых работает наше приложение. Их может быть от 1 до бесконечности, а в нашем примере их было два + балансировщик нагрузки, который скрывает всю эту кухню, позволяя нам спокойно проводить свои эксперименты за его кулисами😈 И опциональный вебсокет-сервер для реалтайм обновлений.
Сегодня говорим про базы данных. У нас может быть несколько баз данных. В моих проектах их две - реляционная (PgSQL) для основных данных приложения и NoSQL (Redis) для кеширования, сессий и задач в очереди.
Реляционная база данных
В нашем примере я выношу основную базу на отдельный сервер. Это нужно потому что все серверы, на которых работает наше приложение должны работать с одной базой данных. Соответственно наши application серверы и worker сервер подключаются к отдельному серверу БД по локальной сети.
Во-вторых отдельный сервер базы данных позволяет масштабировать базу данных отдельно от самого приложения. То есть мы можем мониторить нагрузку этого сервера отдельно, увеличивать его при необходимости или добавлять новый сервер с репликой (копией базы данных), чтобы часть запросов на чтение данных перенести на реплику.
NoSQL база данных
Для кеша использую БД Redis, который тоже ставлю на отдельный сервер, чтобы к нему могли иметь доступ остальные серверы с приложением. Сессии в идеале тоже нужно хранить на отдельном сервере, чтобы в случае очистки кэша (php artisan cache:clear) они не потерялись - в этом случае пользователям придется заново входить в кабинет (в случае с аутентификацией через сессию).
Но я храню сессии вместе с кешем, потому что не уверен, что держать отдельный сервер чисто для сессионных данных оправдано. С задачами для очередей ситуация немного опаснее, потому что если мы храним задачи в той же базе, где кэш, то в случае его очистки мы тупо теряем все задачи, которые были в очереди и НЕ успели обработаться - вот это уже не приятно. Конечно чистить кеш так радикально нельзя, но на практике есть такой кейс.
У меня был разный опыт по поводу хранения задач в очереди. Было дело хранил их на worker сервере, где собственно эти задачи и выполняются. Было дело хранил их на сервере кэширования, а когда очистили кэш все задачи пропали. Было дело хранил их на отдельном сервере - это самый спокойный вариант, поэтому сейчас я бы выбрал его.
Подводим итог
Основную базу данных держим на отдельном сервере, чтобы к нему могли подлючаться все экземпляры приложения, а так же мониторить и обслуживать этот сервер независимо. Обязательно настраиваем резервное копирование базы каждый час. Резервная копия, конечно, должна лежать отдельно (например на другом сервере). Кеш и сессии можно держать вместе, если не очень принципиально потерять сессионный данные в случае очистки кеша, а задачи для очередей держим на отдельном сервере (например worker), потому что их потерять точно не хочется.
Дополнительно
В последнее время вместо разворачивания серверов с базой (в продакшене) использую облачные базы данных, управляемые поставщиком услуги (Cloud Managed Databases). Там мы просто выбираем тип базы данных (MySQL, PostgreSQL, Redis), размер сервера (процессор, оперативка, размер диска) и всё. База автоматически разворачивается, а наши приложения подключаются к ней, как обычно. Там мы видим основную статистику по работе этой базы, можем увеличивать её мощность, имеем автоматическое резервное копирование (репликацию) и можем добавлять еще экземпляры для чтения в пару кликов. И всё это без остановки приложения!
Очень понравилось много репостов в прошлый раз. Ну вы поняли. @onecode_blog 👈
#servers #devops
Вчера говорили про серверы, на которых работает наше приложение. Их может быть от 1 до бесконечности, а в нашем примере их было два + балансировщик нагрузки, который скрывает всю эту кухню, позволяя нам спокойно проводить свои эксперименты за его кулисами
Сегодня говорим про базы данных. У нас может быть несколько баз данных. В моих проектах их две - реляционная (PgSQL) для основных данных приложения и NoSQL (Redis) для кеширования, сессий и задач в очереди.
Реляционная база данных
В нашем примере я выношу основную базу на отдельный сервер. Это нужно потому что все серверы, на которых работает наше приложение должны работать с одной базой данных. Соответственно наши application серверы и worker сервер подключаются к отдельному серверу БД по локальной сети.
Во-вторых отдельный сервер базы данных позволяет масштабировать базу данных отдельно от самого приложения. То есть мы можем мониторить нагрузку этого сервера отдельно, увеличивать его при необходимости или добавлять новый сервер с репликой (копией базы данных), чтобы часть запросов на чтение данных перенести на реплику.
NoSQL база данных
Для кеша использую БД Redis, который тоже ставлю на отдельный сервер, чтобы к нему могли иметь доступ остальные серверы с приложением. Сессии в идеале тоже нужно хранить на отдельном сервере, чтобы в случае очистки кэша (php artisan cache:clear) они не потерялись - в этом случае пользователям придется заново входить в кабинет (в случае с аутентификацией через сессию).
Но я храню сессии вместе с кешем, потому что не уверен, что держать отдельный сервер чисто для сессионных данных оправдано. С задачами для очередей ситуация немного опаснее, потому что если мы храним задачи в той же базе, где кэш, то в случае его очистки мы тупо теряем все задачи, которые были в очереди и НЕ успели обработаться - вот это уже не приятно. Конечно чистить кеш так радикально нельзя, но на практике есть такой кейс.
У меня был разный опыт по поводу хранения задач в очереди. Было дело хранил их на worker сервере, где собственно эти задачи и выполняются. Было дело хранил их на сервере кэширования, а когда очистили кэш все задачи пропали. Было дело хранил их на отдельном сервере - это самый спокойный вариант, поэтому сейчас я бы выбрал его.
Подводим итог
Основную базу данных держим на отдельном сервере, чтобы к нему могли подлючаться все экземпляры приложения, а так же мониторить и обслуживать этот сервер независимо. Обязательно настраиваем резервное копирование базы каждый час. Резервная копия, конечно, должна лежать отдельно (например на другом сервере). Кеш и сессии можно держать вместе, если не очень принципиально потерять сессионный данные в случае очистки кеша, а задачи для очередей держим на отдельном сервере (например worker), потому что их потерять точно не хочется.
Дополнительно
В последнее время вместо разворачивания серверов с базой (в продакшене) использую облачные базы данных, управляемые поставщиком услуги (Cloud Managed Databases). Там мы просто выбираем тип базы данных (MySQL, PostgreSQL, Redis), размер сервера (процессор, оперативка, размер диска) и всё. База автоматически разворачивается, а наши приложения подключаются к ней, как обычно. Там мы видим основную статистику по работе этой базы, можем увеличивать её мощность, имеем автоматическое резервное копирование (репликацию) и можем добавлять еще экземпляры для чтения в пару кликов. И всё это без остановки приложения!
Очень понравилось много репостов в прошлый раз. Ну вы поняли. @onecode_blog 👈
#servers #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
👍40🔥7❤1💩1🍌1
Серверы и масштабирование Часть 3 Мониторинг
В крупных и важных приложениях нужен хороший мониторинг, чтобы мы могли легко оценить текущее состояние системы, определить узкие места и вовремя реагировать на возможные неприятности.
В базовом варианте мониторингом может служить панель сервер-провайдера, то есть сервиса, где вы покупаете серверы - там обычно есть графики потребления памяти, процессора и диска. Можно настроить уведомления о привышении нагрузки, например когда потребление памяти превышает 80% мы получим письмо на email. Это удобно и всегда нужно сразу настраивать такие уведомления.
Однако для более крупных приложений хочется видеть больше данных. Кроме нагрузки на сам сервер важно отслеживать работу отдельных процессов, таких как Nginx, PHP-FPM и базы данных.
Например для Nginx полезно видеть количество запросов, время отклика, количество открытых соединений и тд. Для PHP-FPM тоже количесто запросов, время обработки запроса, потребление памяти и тд. Для PostgreSQL или MySQL тоже количество запросов, время работы запросов, потребление ресурсов и тд.
Для решения этой задачи есть разные способы, но оптимальный с точки зрения простоты настройки, надежности и полноты я считаю связку Prometheus + Graphana. Можно сказать, что это классический популярный вариант. Обычно они вместе ставятся на отдельный небольшой сервер.
Prometheus
Как я сказал, прометеус в идеале устанавливается на отдельный сервер и собирает необходимые данные с остальных серверов, сохраняя их в свою внутреннюю базу данных. Настройка прометеуса довольно проста - там есть файл конфигурации prometheus.yml, в котором мы указываем какие метрики, с каких серверов и с какой периодичностью необходимо получать.
Помимо этого на каждый сервер, с которого прометеус должен собирать метрики, необходимо установить экспортер - небольшая программа, которая получает данные от нужного процесса и передаёт их в прометеус. Например, если мы хотим собирать метрики Nginx, то нужно установить nginx-prometheus-exporter, для PHP-FPM устанавливаем php-fpm_exporter, для PostgreSQL ставим postgres_exporter и так далее.
Экспортеры работают на нужных серверах, собирают данные в нужном для прометеуса формате, при этом потребляют незначительное количество ресурсов сервера. Прометеус опрашивает экспортеры с указанной нами периодичностью (например раз в 15 минут) и хранит эти данные у себя. Всё просто.
Graphana
Графана нужна для отображения данных из прометеуса в графическом интерфейсе. В графане мы можем создавать различные информационные панели с графиками на основе данных из прометеуса, выдавать к ним доступ и настраивать уведомления (alerts). Например, можно создать панель, отображающую количество запросов в секунду (RPS) для Nginx, время отклика PHP-FPM, использование CPU и памяти сервером и т.д.
Таким образом анализируя метрики в Graphana, собранные Prometheus, можно выявлять узкие места в производительности и принимать решения о масштабировании или оптимизации инфраструктуры и своевременно получать уведомления, когда что-то идёт не так.
Спасибо за внимание и репосты, парни! @onecode_blog 👈
#servers #devops
В крупных и важных приложениях нужен хороший мониторинг, чтобы мы могли легко оценить текущее состояние системы, определить узкие места и вовремя реагировать на возможные неприятности.
В базовом варианте мониторингом может служить панель сервер-провайдера, то есть сервиса, где вы покупаете серверы - там обычно есть графики потребления памяти, процессора и диска. Можно настроить уведомления о привышении нагрузки, например когда потребление памяти превышает 80% мы получим письмо на email. Это удобно и всегда нужно сразу настраивать такие уведомления.
Однако для более крупных приложений хочется видеть больше данных. Кроме нагрузки на сам сервер важно отслеживать работу отдельных процессов, таких как Nginx, PHP-FPM и базы данных.
Например для Nginx полезно видеть количество запросов, время отклика, количество открытых соединений и тд. Для PHP-FPM тоже количесто запросов, время обработки запроса, потребление памяти и тд. Для PostgreSQL или MySQL тоже количество запросов, время работы запросов, потребление ресурсов и тд.
Для решения этой задачи есть разные способы, но оптимальный с точки зрения простоты настройки, надежности и полноты я считаю связку Prometheus + Graphana. Можно сказать, что это классический популярный вариант. Обычно они вместе ставятся на отдельный небольшой сервер.
Prometheus
Как я сказал, прометеус в идеале устанавливается на отдельный сервер и собирает необходимые данные с остальных серверов, сохраняя их в свою внутреннюю базу данных. Настройка прометеуса довольно проста - там есть файл конфигурации prometheus.yml, в котором мы указываем какие метрики, с каких серверов и с какой периодичностью необходимо получать.
Помимо этого на каждый сервер, с которого прометеус должен собирать метрики, необходимо установить экспортер - небольшая программа, которая получает данные от нужного процесса и передаёт их в прометеус. Например, если мы хотим собирать метрики Nginx, то нужно установить nginx-prometheus-exporter, для PHP-FPM устанавливаем php-fpm_exporter, для PostgreSQL ставим postgres_exporter и так далее.
Экспортеры работают на нужных серверах, собирают данные в нужном для прометеуса формате, при этом потребляют незначительное количество ресурсов сервера. Прометеус опрашивает экспортеры с указанной нами периодичностью (например раз в 15 минут) и хранит эти данные у себя. Всё просто.
Graphana
Графана нужна для отображения данных из прометеуса в графическом интерфейсе. В графане мы можем создавать различные информационные панели с графиками на основе данных из прометеуса, выдавать к ним доступ и настраивать уведомления (alerts). Например, можно создать панель, отображающую количество запросов в секунду (RPS) для Nginx, время отклика PHP-FPM, использование CPU и памяти сервером и т.д.
Таким образом анализируя метрики в Graphana, собранные Prometheus, можно выявлять узкие места в производительности и принимать решения о масштабировании или оптимизации инфраструктуры и своевременно получать уведомления, когда что-то идёт не так.
Спасибо за внимание и репосты, парни! @onecode_blog 👈
#servers #devops
👍12🔥9❤1
Вышло предложение добавить в PHP BCmath (вычисления с повышенной точностью) объекты для работы с числами.
Очень похожую историю мы делали сами в уроке Как работать с деньгами на PHP. Очень крутой урок, где за час обсудили много проблем и нашли решения в этой важной теме.
Урок доступен в VIP-канале 👈
Как по мне - офигенная тема, надеюсь предложение примут.
https://wiki.php.net/rfc/support_object_type_in_bcmath
Очень похожую историю мы делали сами в уроке Как работать с деньгами на PHP. Очень крутой урок, где за час обсудили много проблем и нашли решения в этой важной теме.
Урок доступен в VIP-канале 👈
Как по мне - офигенная тема, надеюсь предложение примут.
https://wiki.php.net/rfc/support_object_type_in_bcmath
👍6❤3🔥3
Серверы и масштабирование Часть 4 Нагрузочное тестирование
Нагрузочное тестирование - это отправка некоторого количества запросов для определения максимальной нагрузки, которую может держать приложение. То есть мы можем понять какое кол-во запросов способны обрабатывать наши серверы в секунду.
По факту мы можем получить лиш примерное представление, потому что запрос запросу рознь. У нас на сайте могут быть "лёгкие" разделы, которые не требуют обращения к базе данных, или наоборот "тяжелые" с большим кол-вом запросов к базе.
Поэтому здесь как вариант можно просто создать отдельный роут, в котором отправить несколько запросов к базе и получить таким образом что-то среднее для проведения нагрузочнгого тестирования этого роута. Конечно можно для этого использовать любые другие роуты нашего приложения.
Тут важно понимать, что опасно запускать такие тесты в продакшен, потому что сайт может сломаться вплоть до необходимости перезагрузки сервера, поэтому нужно действовать аккуратно и постепенно. Лучше сначала потренироваться отдельно на тестовом сервере.
Первый способ
В Linux есть такая утилита - AB. С помощью неё можно отправлять N запросов на определенный адрес. Строго говоря можно устроить простую DDos-атаку. Сразу скажу, что при отправке большого кол-ва запросов некоторые провайдеры могут всполошиться, потому что это может повлиять на стабильную работу серверов.
Но в целом для небольшого тестирования это хороший вариант. Короче устанавливаем AB и запускаем тест примерно с такой конфигурацией:
Отправить 100 запросов по 10 одновременно:
ab -n 100 -c 10 http://example.com
Отправить 1000 запросов по 100 одновременно:
ab -n 1000 -c 100 http://example.com
Отправить 10000 запросов по 500 одновременно:
ab -n 10000 -c 500 http://example.com
После завершения мы получаем полезную информацию, такую как кол-во неудачных запросов, время выполнения запроса, кол-во запросов в секунду и так дале. Нужно пробовать разные настройки, начиная с самых маленьких, чтобы намертво не перегрузить сервак. На основе этой информации можно делать выводы и докручивать серверы.
Как докручивать серверы? Есть несколько основных параметров, которые сразу можно редактировать. Во-первых конфигурацию Nginx (worker_connections), конфигурацию PHP-FPM (pm, max_children) и конечно конфигурацию сервера (процессор, память).
Еще полезно во время тестирования использовать утилиту HTOP в линукс, которая показывает потребление ресурсов сервера - процессора, памяти. Например если во время тестрования видим, что все ядра процессора загружены на 100%, значит логично увеличить параметры сервера, тк добавлять воркеров смысла скорее всего нет.
Тут сложно дать какие-то четкие рекомендации, потому что в каждом проекте всё индивидуально + могут быть другие факторы, оказывающие влияние, например удалённость сервера. Конечно оптимизация самого приложения и запросов к базе данных является важным фактором.
В целом это интересный опыт - отправить N запросов, посмотреть, добавить процессоров, опять запустить, посмотреть, добавить воркеров php-fpm, запустить, посмотреть и так далее. То есть пробовать разные варианты и смотреть как это влияет на результат.
Второй способ
Не многие знают, что в Postman (программа для отправки запросов) есть функция Runner, которая как раз нужна для теститрования производительности, например API нашего проекта. Честно я не пользовался этой штукой, просто знаю, что такая возможность есть. Мне больше нравится утилита AB, которую я могу запустить с отдельного сервера, отправить необходимое кол-во запросов на целевой сервер и посмотреть результат.
Заключение
Дополнительно хочу сказать, что кол-во запросов в секунду - это НЕ тоже самое, что кол-во пользователей онлайн. Например 1000 пользователей онлайн могут давать лишь 1-5 запросов в секунду, потому что юзеры не кликают кнопки постоянно, а читают контент, изучают и думают. Конечно это зависит от проекта, но в целом для ориентира даже 50 запросов в секунду по факту могут держать несколько тысяч пользователей онлайн.
Сделайте репост, пожаааалуйста @onecode_blog 👈
Нагрузочное тестирование - это отправка некоторого количества запросов для определения максимальной нагрузки, которую может держать приложение. То есть мы можем понять какое кол-во запросов способны обрабатывать наши серверы в секунду.
По факту мы можем получить лиш примерное представление, потому что запрос запросу рознь. У нас на сайте могут быть "лёгкие" разделы, которые не требуют обращения к базе данных, или наоборот "тяжелые" с большим кол-вом запросов к базе.
Поэтому здесь как вариант можно просто создать отдельный роут, в котором отправить несколько запросов к базе и получить таким образом что-то среднее для проведения нагрузочнгого тестирования этого роута. Конечно можно для этого использовать любые другие роуты нашего приложения.
Тут важно понимать, что опасно запускать такие тесты в продакшен, потому что сайт может сломаться вплоть до необходимости перезагрузки сервера, поэтому нужно действовать аккуратно и постепенно. Лучше сначала потренироваться отдельно на тестовом сервере.
Первый способ
В Linux есть такая утилита - AB. С помощью неё можно отправлять N запросов на определенный адрес. Строго говоря можно устроить простую DDos-атаку. Сразу скажу, что при отправке большого кол-ва запросов некоторые провайдеры могут всполошиться, потому что это может повлиять на стабильную работу серверов.
Но в целом для небольшого тестирования это хороший вариант. Короче устанавливаем AB и запускаем тест примерно с такой конфигурацией:
Отправить 100 запросов по 10 одновременно:
ab -n 100 -c 10 http://example.com
Отправить 1000 запросов по 100 одновременно:
ab -n 1000 -c 100 http://example.com
Отправить 10000 запросов по 500 одновременно:
ab -n 10000 -c 500 http://example.com
После завершения мы получаем полезную информацию, такую как кол-во неудачных запросов, время выполнения запроса, кол-во запросов в секунду и так дале. Нужно пробовать разные настройки, начиная с самых маленьких, чтобы намертво не перегрузить сервак. На основе этой информации можно делать выводы и докручивать серверы.
Как докручивать серверы? Есть несколько основных параметров, которые сразу можно редактировать. Во-первых конфигурацию Nginx (worker_connections), конфигурацию PHP-FPM (pm, max_children) и конечно конфигурацию сервера (процессор, память).
Еще полезно во время тестирования использовать утилиту HTOP в линукс, которая показывает потребление ресурсов сервера - процессора, памяти. Например если во время тестрования видим, что все ядра процессора загружены на 100%, значит логично увеличить параметры сервера, тк добавлять воркеров смысла скорее всего нет.
Тут сложно дать какие-то четкие рекомендации, потому что в каждом проекте всё индивидуально + могут быть другие факторы, оказывающие влияние, например удалённость сервера. Конечно оптимизация самого приложения и запросов к базе данных является важным фактором.
В целом это интересный опыт - отправить N запросов, посмотреть, добавить процессоров, опять запустить, посмотреть, добавить воркеров php-fpm, запустить, посмотреть и так далее. То есть пробовать разные варианты и смотреть как это влияет на результат.
Второй способ
Не многие знают, что в Postman (программа для отправки запросов) есть функция Runner, которая как раз нужна для теститрования производительности, например API нашего проекта. Честно я не пользовался этой штукой, просто знаю, что такая возможность есть. Мне больше нравится утилита AB, которую я могу запустить с отдельного сервера, отправить необходимое кол-во запросов на целевой сервер и посмотреть результат.
Заключение
Дополнительно хочу сказать, что кол-во запросов в секунду - это НЕ тоже самое, что кол-во пользователей онлайн. Например 1000 пользователей онлайн могут давать лишь 1-5 запросов в секунду, потому что юзеры не кликают кнопки постоянно, а читают контент, изучают и думают. Конечно это зависит от проекта, но в целом для ориентира даже 50 запросов в секунду по факту могут держать несколько тысяч пользователей онлайн.
Сделайте репост, пожаааалуйста @onecode_blog 👈
👍14❤5🔥3👏1
Forwarded from Denis R
Привет! Нужно сделать на Laravel магазин аналог rusavtomatika.ru, за плату. Желательно на двух языках. Обращайтесь пожалуйста в личку.
Forwarded from Макс Орлов Блог
Media is too big
VIEW IN TELEGRAM
Есть прикольные мысли на тему денег и свободы. Постараюсь найти время, чтобы поделиться на следующей неделе.
А пока, поделюсь небольшим достижением - прошел GTA Vice City 😁 Еще один шаг на пути к цели занял 25 часов.
Убедился, что это моя любимая часть из серии, потому что у неё какая-то прикольная атмосфера.
Ну и в детстве играл в неё больше всего. Тогда многие миссии казались сложными, а сейчас всё прошел довольно легко и с кайфом.
Кстати засомневался проходил ли я её раньше целиком? Чтобы прям до титров, потому что для этого нужно помимо основных миссий купить всю недвижимость в городе, типа таксопарка, и пройти эти миссии, чтобы получить звонок от Лэнса и доступ к финальной мисии.
Не скрою, что пару раз пришлось погуглить, а в детстве информация передавалась из уст в уста. Приятная ностальгия.
Установил San Andreas - моя нелюбимая часть. Графика там полная фигня, хотя в этой обновленной версии получше.
Хорошей недели, друзья!
А пока, поделюсь небольшим достижением - прошел GTA Vice City 😁 Еще один шаг на пути к цели занял 25 часов.
Убедился, что это моя любимая часть из серии, потому что у неё какая-то прикольная атмосфера.
Ну и в детстве играл в неё больше всего. Тогда многие миссии казались сложными, а сейчас всё прошел довольно легко и с кайфом.
Кстати засомневался проходил ли я её раньше целиком? Чтобы прям до титров, потому что для этого нужно помимо основных миссий купить всю недвижимость в городе, типа таксопарка, и пройти эти миссии, чтобы получить звонок от Лэнса и доступ к финальной мисии.
Не скрою, что пару раз пришлось погуглить, а в детстве информация передавалась из уст в уста. Приятная ностальгия.
Установил San Andreas - моя нелюбимая часть. Графика там полная фигня, хотя в этой обновленной версии получше.
Хорошей недели, друзья!
👍9🔥4👏1