[Предварительный просмотр прямой трансляции] Облачная виртуальная машина за 99 юаней × Собственная облачная архитектура за 9 юаней √

Введение

Тестирование производительности программных систем является ключевой мерой для обеспечения пропускной способности и стабильности бизнеса. Если принять в качестве основного направления наращивание возможностей программных систем, то работа по проектированию возможностей системы и работа по тестированию производительности имеют как последовательность, так и взаимное влияние. Вышеизложенное, касающееся основных аспектов тестирования производительности, таких как принятие решений по сценарию, анализ архитектуры, анализ трафика, реализация стресс-тестов, а также анализ и оптимизация, вызвало множество мыслей об объединении возможностей системы и шасси и совершенствовании стратегий тестирования.

На этапе тестирования производительности проанализируйте реализацию возможностей системы и решения по настройке, а также изучите возможности для лучших решений и стратегий тестирования производительности.

2. Реальный бой и размышления о стресс-тестировании горячих моделей хранения данных

Посредством тестирования производительности мы можем строить предположения о сценариях использования запасов SKU, узких местах производительности и рисках в различных режимах хранения.

После обновления архитектуры данных эффективность резервирования запасов SKU (TPS) выросла на 2300%↑.

Тестирование в сочетании с внедрением системы демонстрирует необходимость предварительного нагрева кэша и использует анализ больших данных для изучения научных стратегий предварительного нагрева и изоляции кэша.

В сочетании с новыми бизнес-моделями подумайте о более научных идеях построения тестовых данных и планах повышения эффективности процесса тестирования.

1. Сценарий стресс-тестирования

Под резервированием запасов понимается обеспечение краткосрочного резервирования запасов SKU для документов в процессе приема заказа. В процессе приема заказов на логистический склад будет инициировано поведение преимущественного использования запасов в измерении SKU.

Центр инвентаризации предоставляет стандартные возможности преимущественного использования запасов SKU внешнему миру через интерфейс преимущественного права в «Основном приложении преимущественного использования запасов». В основном через три ключевых приложения: «управление логикой инвентаризации и взаимодействие уровня базы данных», «взаимодействие уровня кэша» и «планирование задач», он обеспечивает возможности расчета логики инвентаризации и взаимодействия уровня хранения.

С точки зрения модели данных существует два типа реализации возможности приоритетного вытеснения:

▪Преимущественное вытеснение запасов измерений бизнес-отдела в основном осуществляется через уровень кэша Redis.

▪Предварительная инвентаризация партий осуществляется непосредственно из базы данных.

Когда объем складских ассигнований во время крупной рекламной акции вступает в период взрывного роста, горячие запросы на приоритетное приобретение SKU быстро увеличиваются, а запросы на приоритетное приобретение запасов поступают непосредственно в базу данных, системный TP99 подскочит или даже продолжит расти, вызывая заказ. получение таймаута в серьезных случаях.

Выше мы планируем построить целевые сценарии стресс-тестирования и модели данных для подтверждения пиковой пропускной способности системы и эффективности стратегии настройки.

2. Первое давление и анализ

◦Цель стресс- теста: «Интерфейс упреждения» в разделе «Основное приложение упреждения инвентаризации», в базе данных, содержащей режим запроса на упреждение SKU точки доступа, изучить пиковый трафик, который может передавать целевой TP99 (≤3000 мс), и проверить оптимизированная пиковая пропускная способность (целевое значение TP99≤500 мс).

◦План стресс- тестирования : один номер SKU горячей точки постоянно подвергается нагрузке и предварительно занят. Нагрузка начинается с QPS=10 и увеличивается на QPS+10, чтобы определить верхний предел производительности, способной обрабатывать запросы.

◦Процесс испытания под давлением и его заключение

▪Когда QPS=50, система может стабильно поддерживать бизнес по преимущественному выкупу запасов (TP99≈100 мс).

▪Основное приложение «Предварительная инвентаризация»: загрузка ЦП ≤15%, использование памяти ≤35%

▪Приложение «Управление логикой инвентаризации и взаимодействие уровня базы данных»: загрузка ЦП ≤18%, использование памяти ≤65%

▪База данных: загрузка ЦП ≤7,8% (без медленного SQL)

▪Исходя из текущих характеристик системы, в ней имеются условия для постоянного поддержания давления.

▪Когда давление увеличивается до 60 с шагом QPS+10, TP99 быстро увеличивается до 7000 мс примерно за 2 минуты. Основное применение «вытеснения запасов» — TPS ≤ 60. Прогнозируется, что пропускная способность системы достигла узкого места и давление прекращается.

Основное приложение «Преимущество запасов» TP99+TPS тренд

Тенденция аппаратных ресурсов основного приложения «Преимущество инвентаризации»

Ключевые показатели базы данных (ЦП)

Ключевые показатели базы данных (медленный SQL)

Ключевые показатели базы данных (память)

◦ Прогнозирование узких мест : упреждение запасов в измерении документа выполняется путем сначала проверки (доступного запаса), а затем записи (предварительного вытеснения запасов).В процессе размещения высокочастотных заказов на горячие SKU база данных будет фиксировать это. строка в течение длительного времени. Для непрерывного чтения и записи уровень базы данных обеспечит атомарность одной транзакции с помощью механизма блокировки строк. Конкуренция блокировок, вызванная блокировками на уровне строк, скорее всего, приведет к тому, что вычислительная мощность системы достигнет узкого места. и ограничить эффективность выполнения системы. В то же время нет узких мест в аппаратных ресурсах от уровня приложений до уровня хранения, что исключает влияние нехватки аппаратных ресурсов.

3. Настройка и перепрессовка

◦Преобразование уровня хранилища ( см. Центр инвентаризации — Схема системной архитектуры сценария упреждения инвентаризации ): после первого раунда стресс-тестирования и анализа, чтобы устранить известные узкие места производительности, на уровне архитектуры данных, пакетное упреждение инвентаризации непосредственно переносится базой данных.Давление, обновление кеш-памяти Redis в основном несет в себе давление запроса. Высокопроизводительная пропускная способность Redis используется для решения проблемы эффективности чтения и записи данных в параллельных сценариях, а Redis используется для передачи основного трафика горячих продуктов впереди.

◦Гарантия согласованности ( см. Центр инвентаризации — упрощенная схема механизма мониторинга изменений запасов )

▪Чтобы обеспечить согласованность данных между уровнем кэша и уровнем базы данных, в случае попадания в кэш база данных записывается обратно асинхронно путем создания задачи планирования или метода MQ.

▪В случае сбоя в кэше результаты вытесняются путем сначала чтения (база данных), записи (Redis), а затем обратной передачи (API), а затем асинхронной записи обратно в базу данных для обеспечения согласованности данных.

Диаграмма архитектуры системы сценария подготовки инвентаризации Центра инвентаризации

Упрощенная схема механизма мониторинга изменений запасов в Центре инвентаризации

◦Вывод повторного давления

▪После завершения обновления архитектуры данных и прогрева кэша SKU точки доступа начальное значение QPS = 1100 и увеличивается на 100. Когда TPS достигает 1200, TP99 ≈ 130 мс, и система может стабильно поддерживать бизнес по предварительному заполнению пакетной инвентаризации.

▪Когда TPS достигает 1300, TP99 значительно колеблется (сбой ≈ 420 мс), а загрузка ЦП приложением «взаимодействие со слоем кэша» возрастает до 90%+.Стабильность основного канала ухудшается и нагрузка прекращается.

▪По сравнению с режимом переноса базы данных, после обновления кэша TP99 соответствует ожиданиям (≤500 мс), а пропускная способность TPS значительно увеличивается на 2300% = (1200-50)/50.

Основное приложение «Преимущество запасов» TP99+TPS тренд

Тенденция аппаратных ресурсов основного приложения «Преимущество инвентаризации»

Ключевые показатели базы данных (ЦП)

Ключевые показатели базы данных (медленный SQL)

Ключевые показатели базы данных (память)

Ключевые показатели кластера Redis

4. Думаем о надежности системы

◦**Недостатки полного кэширования: **Различные отрасли в модели цепочки поставок имеют большие различия в жизненном цикле категорий SKU (например, швейная промышленность ≈ 3 месяца).Режим полного кэширования приведет к большому количеству недействительных категории в Redis и потребление ресурсов.Расширение неконтролируемо и увеличивает затраты на ресурсы.Необходимо разработать более эффективное решение для кэширования.

◦**Необходимость предварительного нагрева кэша и сохранения тепла:**Частота попадания в кэш тесно связана с механизмом предварительного нагрева и стратегией сохранения тепла.

▪Необходимость: Регулярный большой ритм рекламной акции и период начала продаж вызовут первую инициализацию кэша. Перекрытие между рекламными категориями и категориями ежедневных продаж определяет вероятность первого выхода из строя кэша. Текущий период действия ключа = 7 дней, а период продаж → хороший старт → интервал пикового периода более 7 дней.Отсутствие необходимой стратегии изоляции увеличит вероятность отказа кэша перед следующим узлом продвижения.

Отличное начало тенденции попадания в кэш обновления 11.11.

Система в целом может плавно передавать трафик и одновременно кэшировать кривую частоты попаданий, поэтому есть возможности для улучшения.

▪Идеи по предварительному разогреву: как максимально поддерживать эффективность кэша в определенные периоды, например, при больших продажах, и повысить скорость попадания в кэш (уменьшить вероятность поломки). Это можно сделать с помощью предварительно обработанного многомерного анализа. и исследования, включая, помимо прочего, анализ на основе больших данных: централизованный анализ распределения категорий закупок перед продвижением, предыдущие крупные рекламные акции и анализ плотности и распределения категорий продвижения ключевых узлов, а также исследование плана продвижения ключевых клиентов и т. д. в сочетании с техническими средствами. , предварительный расчет, предварительный подогрев и изоляция.

◦** Практика предварительного разогрева кэша: ** Анализируя период централизованных закупок перед большой рекламной акцией клиента и перекрытием категорий SKU узлов больших рекламных акций, были обнаружены следующие правила.

▪Перспектива централизованной закупки: перекрытие категорий SKU в период большой акции составляет ≈69% относительно категории открытия и ≈75% относительно категории 11.11.

▪Перспектива продаж: категория SKU в начальный период продаж имеет степень совпадения ≈94% по сравнению с открывателем, а перекрытие открывателя относительно категории 11.11 составляет ≈75%.

▪Приведенные выше данные доказывают, что предварительный разогрев кэша доступных данных запасов SKU периода централизованной закупки и предыдущего периода продвижения перед ключевыми узлами продвижения, такими как хороший старт и продвижение 11.11, помогает улучшить частоту попадания в кэш предварительных запросы на освобождение.

Анализ совпадения категорий SKU в основных ссылках продвижения

◦**Идентификация аномального сценария:**Сценарии инвентаризации предъявляют высокие требования к трем свойствам данных (точность, своевременность и полнота).Во время процесса двусторонней синхронизации между базой данных и кэшем необходимо избегать бизнес-исключений, вызываемых по проблемам согласованности.

▪Идентификация исключений перепроданности: в период пиковых продаж в целях защиты безопасности основной базы данных используются синхронизация кэша и ограничение тока для снижения нагрузки на основную базу данных, что приводит к задержкам синхронизации между кэшем и базой данных. SKU не вычитается вовремя на уровне базы данных. В этом случае кеш накладывается. В случае истечения срока действия ключа интерфейс напрямую возвращает данные MySQL, что может вызвать бизнес-исключения перепроданности.

▪Идеи по оптимизации системы

▪Статический план: в период пиковой нагрузки одного тома срок действия ключа продлевается, чтобы охватить ключевые интервалы крупных рекламных акций.

▪Динамическое решение: добавьте стратегию задержки периода действия кэша SKU горячей точки. Срок действия ключа Т-1 дней, SKU со средним ежедневным объемом запросов на приоритетное использование больше 1 автоматически продлевают срок действия ключа.

5. Мысли об улучшении стратегий тестирования

◦Расширение сцены

▪Тенденция к внедрению модели электронной коммерции в прямом эфире сильна (за первые три квартала 2023 года объем продаж электронной коммерции в прямом эфире в стране достиг 1,98 трлн юаней, увеличившись на 60,6%, что составляет 18,3% розничных онлайн-продаж). а электронная коммерция в прямом эфире привела к росту онлайн-торговли на 7,7 процентных пункта), по сравнению с традиционной электронной коммерцией, ее ограниченная по времени модель продвижения накладывается на атрибуты социальной коммуникации и распространения, что приводит к большому мгновенному трафику для отдельных продуктов, меньшая перекрываемость категорий между различными сеансами продвижения и высокая частота продвижения, что выдвигает разные требования к производительности системы.

▪Стратегия обратного тестирования производительности с точки зрения платформы должна максимально увеличить разнообразие SKU, одновременно уменьшая перекрытие категорий SKU в одном запросе на стресс-тестирование и выявляя потенциальные риски производительности в реальных сложных сценариях.

◦Повышение эффективности : тестирование производительности заказов складского распределения в сложных сценариях требует большого запаса исходных данных (товар, инвентарь), а также подготовки данных запроса интерфейса высокой сложности. Как обеспечить быструю готовность основных данных, таких как продукты и запасы? При этом можно ли автоматически сконструировать и быстро собрать тело сообщения запроса заказа в соответствии с требованиями плотности и сложности SKU? Необходимо разработать расширенные функции на основе существующей структуры стресс-тестирования для поддержки возможностей быстрой инициализации построения в один клик от базовых данных до сложных документов, снижения сложности построения сложных сценариев и повышения эффективности работы по тестированию.

3. Анализ, выявление и оптимизация недействительных звонков.

На этапе анализа трафика и тестирования производительности в сочетании с исследованием бизнес-сценариев заранее выявляются предполагаемые узкие места в производительности.

После проведения расследования и корректировки логики вызовов основного канала в течение периода калиброванного бизнес-окна общее количество вызовов основного интерфейса сократилось на 60 %↓.

Глубоко сегментируйте бизнес-сценарии и определите потенциальное пространство для настройки.

1. История

После того, как заказ отправлен со склада, логистическая система использует приложение запроса сведений о заказе, чтобы предоставить возможности внешнего запроса для заказа и связанных с ним сведений о упаковке. В основном он вызывается внешними системами (вызывающие абоненты верхнего уровня 2: возврат доступа 67%, возврат выполнения 11%).После отгрузки документа со склада выводятся основные сведения о заказе, такие как количество и детали упаковки исходящего товара. .

Ключевая (Top2) топология вызывающего абонента

2. Расследование сценариев и выявление сомнительных моментов

◦Исследование сценариев и прогнозирование рисков (анализ производственных потоков)

▪Проведен анализ тенденций объема звонков в «Интерфейсе запроса сведений о заказах и пакетах», выборка 10.12 06:30~23:00 за 23 года (период анализа трафика) по сравнению с тем же периодом последней акции (пиковый период последней акции). большой запрос на продвижение), звонки Top2 Общее количество звонков в пик выросло на 305%.

▪Основываясь на предварительных исследованиях и с точки зрения количества звонков, при нормальных обстоятельствах средняя исходящая производительность склада составляет ≈ 400 000 заказов в минуту. Пиковый период исходящего склада — с 08:00 до 18:00 каждый день. Число исходящих складских операций : «Запрос деталей заказа и пакета «Интерфейс» пиковая громкость звонков ≈ 1:10 — это «обычное соотношение».

▪По данным онлайн-данных на 12 октября количество выходов со склада: пиковая стоимость звонка «Интерфейса запроса деталей заказов и пакетов» (400000/6532200) ≈ 1:16, что является большим отклонением, чем «обычный соотношение".

▪Вышеупомянутое, посредством анализа производственного трафика, было выявлено, что были сомнения в количестве обращений к «Интерфейсу запроса деталей заказов и пакетов» в пиковый период исходящих складских отгрузок, и был проведен дальнейший углубленный анализ. проведенный.

Количество обращений по ключевым приложениям за последний период акции

Объем обращений ключевых заявок на 12 октября 2023 г.

◦ Грубая сортировка цепочки вызовов

▪Размеры документов вне склада распределения склада, приложение обратного вызова выполнения, при отправке сведений о вне склада в систему заказов будет вызываться интерфейс запроса сведений о складе.

▪Подключиться к приложению возврата.При возврате информации о заказе будет вызван интерфейс запроса сведений о складе.

▪Пиковое значение обратного вызова состояния производительности/пиковое значение обратного вызова доступа ≈ 1: 9. Пиковое значение обратного вызова доступа явно больше, и подозрительная система (приложение обратного вызова доступа) постепенно блокируется.

◦Углубленный анализ сомнительных моментов

▪После тщательного расследования впервые было подтверждено, что первоначальные выводы о аномальном трафике и подозрительных системах были в основном верными.

▪На уровне технической архитектуры приложение обратного вызова доступа вызывает целевой интерфейс, не оценивая статус заказа. В результате возникло большое количество недействительных звонков, когда документы не были отгружены со склада и не было данных об отгрузке.

▪В то же время было обнаружено, что конфигурация псевдонимов тестовой среды AB была неправильной, что привело к ошибочному наложению производственного трафика.

3. Стратегия настройки

◦Регулировка логики вызова

▪ «I» На этапе возврата заказа бизнес-сценария, если документ находится в статусе «Перед отправкой», вызов «Интерфейса запроса сведений о пакете заказа» не будет инициирован, а недействительные запросы будут устранены.

▪На основании конечного возвращенного контента (требуется ли подробная информация) определить необходимость звонка и исключить ненужные запросы.

◦Настройте конфигурацию псевдонима тестовой среды AB, чтобы тестовый трафик не оказывал ненужной нагрузки на производственную среду.

Доступ к логике приложения обратной передачи перед оптимизацией

Оптимизированный доступ к логике приложения транспортной сети

4. Эффект настройки

◦По сравнению с состоянием до настройки (10.12), общее количество вызовов «Доступ к приложению Backhaul» уменьшено на 60%↓ (до: 2397252500, после: 925890100), а пиковое количество вызовов уменьшено на 64%↓ (до : 5921500, после: 2121800).

На следующем рисунке показано распределение громкости звонков до и после корректировки для сравнения.

5. Предварительная идентификация рисков производительности.

◦Этап внедрения стресс-тестирования — не единственный этап обнаружения рисков производительности.Если у вас есть возможность выявить риски производительности и обеспечить демонстрацию на этапе анализа трафика, чем раньше будет обнаружена проблема, тем меньше затраты (ресурсы) на контроль рисков. и тем ниже риск качества.

6. Нормализация OpsReview

◦Наблюдение за аномалиями трафика. Анализ трафика и выявление рисков производительности должны сочетать фактические характеристики производства и эксплуатации, а также ключевую цепочку вызовов интерфейса для определения общих правил объема системных вызовов. Вызываемой стороне необходимо постоянно определять источники и регулярные объемы вызовов, проводить инвентаризацию стратегий внешних вызовов и исследовать риски при изменении объема вызовов.

◦Стандарты кодирования. Необходимо абстрагировать логику вызова интерфейса в стандартный метод, чтобы избежать различий в кодировании, которые варьируются от человека к человеку во время совместной разработки, и снизить вероятность недопустимых запросов.

◦Устранение неполадок с настраиваемой логикой. В системе существует множество настраиваемых логик для нестандартных служб, поэтому необходимо устранять риски недопустимых запросов на основе специальной логики.

7. Потенциальное сокращение пространства для настройки.

◦На основе опыта тестирования и разбора бизнес-сценариев установлено, что в рамках «И-сценария» выделяются нестандартные заказные процессы, а также стандартный процесс «П-сценарий» параллельно со «И-сценарием».

◦Linked R&D провел углубленный анализ нестандартного заказного процесса в сценарии «I» и стандартного процесса в сценарии «P». Было подтверждено наличие возможностей для дальнейшей оптимизации и уточнен план оптимизации ( как показано ниже).

4. Резюме

Тестирование производительности является ключевой мерой по консолидации и обновлению возможностей системы. Путем представления и анализа типичных случаев исследуются возможности для улучшения возможностей системы и стратегий тестирования производительности. Обеспечьте стабильную и эффективную передачу пикового бизнес-трафика по каналам базовой системы, спокойно справляясь с экстремальными сценариями.

Автор: JD Logistics Лю Жуй и др.

Источник: Сообщество разработчиков JD Cloud Ziyuanqishuo Tech. При перепечатке указывайте источник.

[Накопленная работа] Практика и исследование производительности, оптимизации (оптимизация модели хранения + анализ ссылок на вызовы) | Техническая команда JD Logistics