Яндекс толока ответы: ручные и автоматические способы — Добро пожаловать в блог Яндекс.Толоки

ручные и автоматические способы — Добро пожаловать в блог Яндекс.Толоки

Добро пожаловать в блог Яндекс.Толоки

9 июня 2021, 12:00

В Толоке есть два способа принимать задания исполнителей: автоприёмка — когда ответ принимается сразу после того, как толокер его отправил и отложенная приёмка — после проверки заказчиком. Разбираемся, чем отличаются эти способы, для каких задач они подходят и как быстро и эффективно проверять задания с отложенной приёмкой.

Автоприёмка

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

Как только толокер отправит ответ — задание будет считаться принятым, и деньги за его выполнение перечислятся на счёт исполнителя. Вернуть оплату уже не получится: поэтому важно проверять действия исполнителей прямо в интерфейсе и эффективно настраивать контроль качества.

В интерфейсе можно проверять такие действия:

• Проигрывание медиаконтента — чтобы убедиться, что исполнитель правда посмотрел видео или послушал аудиозапись. Если в задании важно полностью изучить запись — проверяйте длительность прослушивания.
• Переход по внешней ссылке.
• Наличие ответов на определённые вопросы в задании.
• Формат данных, которые вводит исполнитель — это могут быть электронная почта, телефон или дата.

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

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

Подробнее о том, какие правила контроля качества существуют, и как правильно их настроить, читайте здесь.

Когда не получится воспользоваться автоприёмкой

Автоприёмка не подойдёт для задач, в которых нужно:

• Выделять области на картинке;
• Писать тексты;
• Выполнять полевые задания;
• Записывать речь на диктофон, снимать видео или выполнять другие задания, в которых требуется прикрепить файл.

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

Отложенная приёмка

Этот способ используют, когда нельзя проверить задания автоматически. Обычно это касается полевых и творческих заданий или задач по созданию контента (видео, аудио или фото). Чтобы определить, подходят ли ответы исполнителя — нужно проверить их перед приёмкой. Принятые задания будут оплачены, а отклонённые — нет.

Делать отложенную приёмку вручную необязательно. Если в проекте предстоит проверить тысячи заданий — можно упростить и автоматизировать процесс. Расскажем, как это сделать.

Способ № 1 — вручную в интерфейсе

Если заданий немного и разметка разовая — проще всего проверить их вручную:

1. Нажмите кнопку Проверить задания на странице пула.
2. Просмотрите ответы исполнителя, а затем нажмите Принять или Отказать.
3. Оставьте комментарий для ответов, которые вы отклонили: объясните толокеру, почему задание выполнено неверно и какие требования инструкции нарушены.

Нажмите кнопку «Принять» или «Отказать»

Если отклоняете задание, оставьте комментарий

Способ № 2 — в TSV-файле с результатами

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

1. Скачайте TSV-файл с ответами со страницы пула.
   
2. Обработайте файл и проставьте вердикты в столбце ACCEPT:verdict. Поставьте «+» для заданий, которые нужно принять, и «-» — для тех, которые нужно отклонить.
3. Для отклонённых заданий добавьте комментарий с объяснением причины в поле ACCEPT:comment.

   Если на странице несколько заданий, у них будет одинаковый ASSIGNMENT:assignment_id — уникальный идентификатор страницы с ответами. Поэтому сначала нужно решить, стоит ли принимать всю страницу. Расставьте плюсы и минусы для всех заданий на странице, подсчитайте результат, а затем оставьте в файле только одну строку для каждого assignment_id. Если на странице больше правильных ответов, её стоит принять, а если верных ответов мало — отклонить.

4. Загрузите готовый TSV-файл с вердиктами обратно в Толоку — и задания будут проверены.

   Важно удалить лишние строки: если загрузить файл с повторяющимися assignment_id, система случайным образом выберет любую из таких строк и применит ко всей странице указанный вердикт — примет её или отклонит. Поэтому после обработки файла некоторые задания могут получить не те статусы, которые вы ожидали.

Если пользователи прикрепляли к ответам файлы (картинки, аудио или видео), то проверять задания в TSV-файле будет неудобно: придётся скачивать файлы, просматривать их, а затем заносить вердикт в нужную строку. В этом случае лучше проверить задания в интерфейсе или воспользоваться способом № 3.

Способ № 3 — с помощью толокеров в отдельном проекте

Этот способ стоит освоить, если у ваших проектов большой и постоянный поток разметки. При желании метод конвейера можно автоматизировать с помощью API и освободить время для более высокоуровневых задач.

Для проверки заданий толокерами нужно создать отдельный проект. В нём вы покажете другим исполнителям полученные ответы и попросите оценить, верно ли выполнено задание. Например:

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

Расшифровка аудиозаписей

Проверка ответов

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

1. Если в первом проекте исполнители оправили вам файлы — скачайте их вместе с TSV-файлами и выложите на любую облачную платформу, например, в Yandex.Cloud. Это нужно, чтобы получить прямые ссылки на ответы и показать их исполнителям в задании.
2. Создайте интерфейс задания, чтобы исполнитель увидел данные из предыдущего проекта (исходные данные и полученные ответы). Не забудьте добавить скрытое входное поле assignment_id — исполнитель его не увидит, а вам будет проще разобраться, к какому заданию относится вердикт.

3. Добавьте в инструкцию требования к заданию и критерии оценки результатов: что считать правильным, а что нет.
4. Назначьте навык всем исполнителям, которые выполняли задания в первом проекте. Добавьте во второй проект фильтр для отбора исполнителей без навыка: так толокеры не смогут проверять свои же задания.

5. Поставьте автоприёмку, перекрытие 3 или динамическое перекрытие в пуле.
6. Загрузите задания и запустите пул.
7. Когда пул будет полностью выполнен — запустите агрегацию результатов.
8. На основе агрегированных данных подготовьте и загрузите файл с результатами проверки, как в способе № 2.

О том, как настроить проверку ответов с помощью исполнителей мы рассказывали в туториале по краудсорсингу на примере выделения областей на картинке. Пройдите туториал, чтобы этому научиться работать с такими задачами.

Способ № 4 — через API

Выполнять отложенную приёмку можно с помощью API. Чтобы принять или отклонить полученные ответы, измените статус страницы заданий с помощью PATCH-запроса к ресурсу /assignments/<assignment_id>:

1.      Принять ответы: измените статус SUBMITTED на ACCEPTED.

2.     Отклонить ответы: измените статус SUBMITTED на REJECTED.

3.     Изменить решение об отклонении: измените статус REJECTED на ACCEPTED.

Обратите внимание: принять или отклонить все задания по ID пула нельзя. Нужно указывать ID каждой страницы заданий.

Подробнее об отложенной приёмке через API можно узнать в справке. Если нужна помощь, обратитесь в службу поддержки — мы поможем написать запрос.

Полуавтоматическая приёмка

Так можно назвать комбинированный метод проверки: когда часть задания принимается автоматически правилом контроля качества, а оставшиеся задания — любым из перечисленных выше способов.

Если вы проверяете исполнителей контрольными заданиями, добавьте в пул правило, чтобы принимать все ответы пользователей, которые успешно справляются с заданием, например, с качеством 80% и выше:  

По аналогии можно настроить правило «Мнение большинства», чтобы принимать ответы исполнителей, которые совпадают с ответами других толокеров.

Что важно учесть при проверке ответов

• Ответы нужно полностью проверить в течение срока, который установлен в поле Срок проверки. Если не успеете — непроверенные задания будут приняты автоматически, а деньги на их оплату спишутся с вашего счёта.
• Исполнитель может подать апелляцию, чтобы попросить заново проверить и принять отклонённые задания. На это даётся 7 дней с того момента, как задание было отклонено. Если вы отклонили ответы по ошибке — примите их. Если всё верно — напишите сообщение толокеру и объясните, в чём он ошибся: в следующий раз исполнитель будет внимательнее. Рассматривайте обращения и отвечайте на них вовремя — в течение 9 дней с момента отклонения задания.
• Отклонённые задания можно отправить на повторное выполнение автоматически с помощью правила Обработка отклонённых и принятых заданий.
• Принять ранее отклонённое задание можно, а вот отклонить уже принятое — нет. Поэтому принимайте задания внимательно.
• Нельзя изменить статус задания, если пул, к которому оно относится, отправлен в архив. Обратите внимание: архивация произойдёт автоматически, если в пуле не было активности в течение месяца.
• Ответы из пула скачиваются в формате TSV, если нужен формат JSON — воспользуйтесь API.
• Если в ответах содержатся файлы, отправленные исполнителями, можно скачать их из пула в ZIP-архиве. Нажмите Скачать результаты → Скачать вложения на странице пула. Архив будет содержать папки с номерами выполненных заданий (assignment_id), в каждой из них будут лежать отправленные файлы. Имена файлов присваиваются автоматически при загрузке, изменить их нельзя. Названия вложений вы найдёте в TSV-файле с ответами, в тех выходных полях, куда они были загружены.

Как видите, в Толоке можно настроить быстрый и удобный способ проверки ответов для любого типа заданий. Если у вас остались вопросы напишите нам, и мы поможем подобрать настройки, которые подходят именно для вашего проекта.

Руководство заказчика (how to)

Обратная связьВсе блоги сервисов© 2013–2023  «Яндекс»

инструменты и правила «Яндекс.

Толоки» — Яндекс Реклама на vc.ru

Проблема качества — одна из ключевых в краудсорсинге. Когда работаешь с удалёнными, незнакомыми тебе исполнителями, невозможно угадать, кто возьмёт очередное задание. Достаточно ли он внимателен? Хорошо ли изучил инструкцию? И вообще, это человек или робот? Мы в Яндексе используем краудсорсинг каждый день. Создавать и развивать наши сервисы помогают миллионы пользователей. Как нам удалось не сойти с ума, пытаясь контролировать крауд, рассказывает Иван Карпеев, старший менеджер по развитию бизнеса Яндекс.Толоки.

5547 просмотров

Иван Карпеев, старший менеджер по развитию бизнеса Яндекс.Толоки

Яндекс начал использовать краудсорсинг в 2008 году — для оценки результатов поиска и обучения поисковых алгоритмов. Подход, при котором объёмная задача делится на множество небольших подзадач, позволил нам формализовать, автоматизировать и масштабировать процессы сбора данных. Но потребовал строгой, также автоматизированной системы контроля качества, и мы стали работать над ней.

Проектов с машинным обучением в компании становилось больше. Росла потребность в данных и исполнителях, которые бы эти данные генерировали. А значит — и в инструментах контроля с гибкими настройками для разных задач. В 2014-м мы запустили собственную краудсорсинговую платформу — Толоку. В 2015–2019 годах количество проектов на ней увеличилось в девять раз — с 443 до 4055 — и продолжает расти. Многолетний опыт работы с краудом позволил нам выстроить в Толоке ступенчатую систему управления качеством.

Основное правило краудсорсинга — отдавать в крауд задания, которые не требуют специальной квалификации. Чтобы справиться с ними, исполнителям достаточно изучить инструкцию. Удалённые пользователи классифицируют тексты и фото, выделяют области на изображениях, расшифровывают короткие аудиозаписи. Например, отвечают на вопросы: «На фотографии есть домашнее животное? Это кот или собака?» Ничего сложного, но ошибки возможны из-за спешки и невнимательности.

Сейчас на платформе зарегистрировано более 8 млн исполнителей — толокеров. Они выполняют около 13 млн заданий в день и тратят порядка 1,2 млн человеко-часов в месяц. При таких объёмах контролировать процессы вручную невозможно. В Толоке мы делаем это автоматически на всех этапах разметки — от поиска исполнителей до обработки результатов.

Обучение и экзамены: тренируем исполнителей

Первая ступень контроля — отбор исполнителей. С помощью обучения и экзаменов мы отсеиваем невнимательных и оставляем тех, кто ответственно относится к задачам.

Обучение — это тест, задания с правильными ответами и подсказками.

Пример обучающего задания, в котором допущена ошибка. Исполнитель пытается отправить неверный ответ и видит подсказку

Если задача сложная и требует строгого отбора, заказчики дополняют обучение экзаменом. Это тоже комплект заданий с ответами, но уже без подсказок. В итоге к основной разметке приступает лишь тот, кто потренировался и успешно сдал экзамен.

Пример настройки доступа: к разметке приступят только исполнители, которые правильно ответили на 80% (или больше) экзаменационных вопросов

Капча и контроль действий: отстраняем читеров

Вторая ступень — правила контроля качества, которые в режиме реального времени регулируют выполнение заданий и доступ толокеров к ним.

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

Например, задача исполнителя — выделить на фотографии объекты для обучения алгоритмов компьютерного зрения. Чтобы обвести объект аккуратно, нужно делать это медленно. Правило «Быстрые ответы» ограничит скорость разметки и отстранит исполнителей, которые отправят несколько заданий подряд быстрее контрольного времени.

Пример настройки правила «Быстрые ответы» в интерфейсе Толоки: если исполнитель выполнит 3 задания из 10 быстрее, чем за 15 секунд, то потеряет доступ к разметке на 5 дней

Лимиты полезны и в опросах, и в проектах по генерации контента. С помощью правила «Выполненные задания» мы ограничиваем число задач, доступных одному пользователю. Это позволяет привлечь больше исполнителей и получить больше уникальных ответов.

Пример настройки правила «Выполненные задания»: исполнитель может отправить только одну страницу с заданиями, после чего будет заблокирован

Контрольные задания, мнение большинства, результаты проверки: выбираем лучших

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

Например, толокерам нужно выбрать один из нескольких вариантов ответа: «Что изображено на фотографии — легковой автомобиль, грузовик, автобус, мотоцикл, другое транспортное средство?» Вперемешку с основными мы загружаем контрольные задания — фотографии, про которые точно знаем, что на них изображено. По количеству верных ответов на эти задания проверяем исполнителей и присваиваем им навыки — оценки по шкале от 0 до 100.

Пример настройки правила «Контрольные задания»: навык (оценка) исполнителя будет равен проценту правильных ответов на эти задания

Те, кто набрал критическое число ошибок, потеряют доступ к разметке. А толокеров с высоким навыком можно поощрить повышенной оплатой.

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

Пример настройки правила «Мнение большинства»: навык исполнителя будет равен проценту ответов, совпавших с мнением минимум двух других толокеров

Контрольные задания и мнение большинства не работают там, где каждый исполнитель должен дать уникальный ответ: записать аудио, снять фото или сочинить текст. Заказчики или другие толокеры проверяют их вручную и отклоняют ошибки. Итоги такой проверки тоже используются для настройки доступа к заданию. С помощью правила «Результаты проверки» мы автоматически отбираем тех, кто редко ошибается в заданиях с ручной приёмкой, и выдаём задания только им.

Пример настройки правила «Результаты проверки»: система заблокирует пользователя, если больше половины его ответов окажутся отклонёнными

Работа над ошибками: просим переделать

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

Мы сделали так, чтобы с помощью правил контроля качества в Толоке можно было автоматически отправлять на переразметку все сомнительные результаты. И каждый отклонённый ответ по отдельности, и сразу все задания, которые успел выполнить пользователь до того, как отправился в бан.

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

Агрегация результатов: выбираем достоверные ответы

Третья ступень — работа с результатами разметки.

Собрав нескольких мнений, легче получить объективную картину. Мы запускаем задания с «перекрытием» — задаём один и тот же вопрос разным исполнителям. А когда все задания выполнены, чтобы не разбирать ответы вручную, запускаем агрегацию. Система сама определяет наиболее достоверный ответ — оценивает статистическую значимость всех вариантов и учитывает навыки пользователей.

Комбинируем и экспериментируем

Правила и инструменты можно и нужно сочетать. Например, вот как с помощью толокеров мы сортируем упоминания компании в социальных сетях. Одна большая задача — фильтрация сообщений — разбита на три простые: 1) оценить важность упоминания; 2) понять, о каком продукте или сервисе речь; 3) определить тональность. Все три задания предполагают выбор ответа из нескольких вариантов. Стоит использовать:

• капчу — для защиты от автоматического прокликивания;
• ограничение быстрых ответов — чтобы исполнители не спешили и внимательно читали посты и комментарии;
• контрольные задания, проверку мнением большинства, чтобы отсеять исполнителей, которые допускают много ошибок;
• агрегацию ответов, чтобы получить более точный результат.

Проектам с генерацией контента подойдёт другое сочетание. Компания ID R&D с помощью Толоки собрала датасеты из оригинальных фотографий. В подобных задачах можно настроить:

• лимит на выполненные задания, чтобы не доверять значительную их часть одному исполнителю;

• доступ по результатам проверки, чтобы не выдавать задания тем, кто ошибается;

• обработку отклонённых заданий, чтобы собрать столько данных, сколько запланировано.

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

Как очистить кеш «Яндекса». Инструкция для начинающих

Новички могут еще не знать, как очистить кэш «Яндекса» или другого веб-браузера. Кроме того, не все «пользователи» знают, что такое кеш браузера и зачем нужно удалять из него информацию.

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

Кстати, в некоторых браузерах есть специальная опция, позволяющая установить определенное значение, которого, к сожалению, нет в «Яндексе». Так что придется использовать небольшую хитрость. Но обо всем по порядку.

Что такое кэш браузера?

Прежде чем получить ответ на вопрос: «Как очистить кеш Яндекс.Браузера?», необходимо выяснить, для чего он предназначен, что в нем есть, какая от него польза?

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

Стоит отметить, что в кеш может попасть как целая страница, так и ее отдельный фрагмент — изображение, видео. Вы замечали, что страницы ресурса, который вы регулярно посещаете, загружаются быстрее, чем на сайте, просматриваемом впервые? Это связано с тем, что информация берется из специального хранилища — кэша. Как видите, все очень просто.

Однако иногда кэш «Яндекса» или любого другого браузера необходимо почистить. Почему? Это будет обсуждаться ниже. Сразу нужно сказать, что эту процедуру может выполнить даже неопытный «пользователь», ведь ничего сложного в ней нет.

Зачем чистить кеш браузера?

Итак, как было сказано ранее, нужно периодически удалять сохраненные данные из кеша браузера. Когда вам нужно это сделать? Здесь все зависит от ситуации. Если вы заметили, что веб-браузер стал чаще «зависать», «глючить» или реагировать на ваши команды, то в первую очередь рекомендуется почистить кеш в «Яндекс.Браузере».

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

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

Как почистить кэш «Яндекса»

Пользователи, которые только начали осваивать компьютер и интернет, как правило, боятся самостоятельно разбираться в настройках устройства и ПО, поэтому ищут ответы на свои вопросы на просторах сети. Мы им тоже поможем.

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

• Запустите веб-браузер и откройте его меню, нажав на кнопку с изображением горизонтальных линий;
• Обратитесь к разделу «История» и выберите в выпадающем списке опцию «Менеджер истории»;
• Слева найдите кнопку «Очистить историю» и в открывшемся окне установите флажок «Файлы, хранящиеся в кеше»;
• Задав период, например «За прошедшую неделю», нажмите на кнопку «Очистить историю».

Вот и все! Кэш «Яндекса» (браузера) очищен. Вся процедура занимает не более 2 минут, конечно, если не удалять выборочно информацию о посещенных ресурсах.

Полезные советы

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

• Для быстрого открытия окна «Очистить историю» можно использовать комбинацию кнопок Delete, Ctrl и Shift. Если пользователю необходимо открыть раздел «История», то сделать это можно с помощью клавиш Ctrl и H.
• Не удаляйте всю информацию из кеша, оставьте данные тех сайтов, которые посещаете регулярно.
• Вместо того, чтобы тратить время (даже немного) на эту операцию, лучше установить лимиты на количество хранимой в кэше информации. В браузерах, установленных на «движке» Chromium, нужно открыть свойства ярлыка и в поле «Объект» отредактировать ссылку. После элемента «.exe» вставьте следующую команду: «-disk-cache-size=X», где «X» — размер кеша (в байтах). Например, если вы хотите установить ограничение в 150 МБ, то вместо «Х» укажите число «157286400» (150*1024*1024).
• При удалении данных из кеша не забудьте поставить галочку напротив опции отвечающей за куки.

Следуйте этим советам, чтобы работать в веб-браузере Яндекс было максимально комфортно.

Заключение

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

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

Туториалы — Документация Яндекс.Танк 1.15.12

Итак, вы установили Яндекс.Танк на нужную машину, он близок к цели, доступ разрешен и сервер настроен. Как сделать тест?

Примечание

Это руководство предназначено для генератора нагрузки phantom .

Создать файл на сервере с Яндекс.Танком: load.yaml

 фантом:
  address: 203.0.113.1:80 # [Адрес цели]:[порт цели]
  урис:
    - /
  Загрузить профиль:
    load_type: rps # запланировать загрузку, определяя количество запросов в секунду
    график: линия(1, 10, 10м) # начиная с 1рс линейно увеличиваясь до 10рс в течение 10 минут
консоль:
  enabled: true # включить вывод консоли
телеграф:
  enabled: false # давайте отключим мониторинг телеграфа в первый раз
 

И запустите: $ yandex-tank -c load. yaml

---

фантом имеют 3 примитива для описания схемы загрузки:

1. step (a,b,step,dur) выполняет ступенчатую нагрузку, где a,b — значения начальной/конечной нагрузки, step — величина приращения, dur — продолжительность шага.

Примеры:

• шаг(25, 5, 5, 60) — ступенчатая нагрузка от 25 до 5 р/с, с шагом 5 р/с, длительность шага 60с.
• шаг(5, 25, 5, 60) — ступенчатая нагрузка от 5 до 25 об/с, с шагом 5 об/с, длительность шага 60с

2. строка (a,b,dur) создает линейную нагрузку, где a,b — начальная/конечная нагрузка, dur — время увеличения линейной нагрузки от a до b.

Примеры:

• линия(10, 1, 10м) — линейная нагрузка от 10 до 1 об/с, продолжительность — 10 минут
• линия(1, 10, 10м) — линейная нагрузка от 1 до 10 об/с, продолжительность — 10 минут

3. const (нагрузка,длительность) обеспечивает постоянную нагрузку. load — количество rps, dur — продолжительность загрузки.

Примеры:

• const(10,10м) — постоянная нагрузка на 10 об/с в течение 10 минут.
• const(0, 10) — 0 об/с в течение 10 секунд, фактически 10-секундная пауза в тесте.

Примечание

Вы можете установить дробную нагрузку следующим образом:

строка(1.1, 2.5, 10) — с 1.1р/с до 2.5 на 10 сек.

Примечание

Шаг и строка могут использоваться с увеличением и уменьшением интенсивности:

С помощью этих примитивов можно задавать сложные схемы нагрузки.

Пример:

расписание: линия(1, 10, 10м) константа(10,10м)

линейная нагрузка от 1 до 10 об/с в течение 10 минут, затем 10 минут постоянной нагрузки 10 об/с.

Продолжительность времени может быть указана в секундах, минутах (м) и часах (ч). Например: 27х203м645

Для теста с постоянной нагрузкой при 10 об/с в течение 10 минут load.yaml должен имеют следующие строки:

 фантом:
  address: 203.0.113.1:80 # [Адрес цели]:[порт цели]
  урис:
    - /ури1
    - /ури2
  Загрузить профиль:
    load_type: rps # запланировать загрузку, определяя количество запросов в секунду
    расписание: const(10, 10m) # начиная с 1р/с линейно увеличивая до 10р/с в течение 10 минут
консоль:
  enabled: true # включить вывод консоли
телеграф:
  enabled: false # давайте отключим мониторинг телеграфа в первый раз
 

Подготовка запросов

Существует несколько способов настройки запросов:

• Режим доступа
в стиле URI
• URI+POST
• стиль запроса.

Примечание

Стиль запроса — тип боеприпасов по умолчанию.

Примечание

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

Чтобы указать внешний файл боеприпасов, используйте ammofile 9вариант 0074.

Примечание

Вы можете указать URL ammofile, http(s). Небольшие аммофайлы (~<100 МБ) будут загружены как есть, в каталог /tmp/ , большие файлы будут считываться из потока.

Примечание

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

Пример:

 фантом:
  адрес: 203.0.113.1:80
  ammofile: https://yourhost.tld/path/to/ammofile.txt
 

URI-стиль, URI в load.yaml

Конфигурация YAML-файла: не указывать ammo_type явно для этого типа боеприпасов.

Обновить файл конфигурации с заголовками HTTP и URI:

 фантом:
  адрес: 203.0.113. 1:80
  Загрузить профиль:
    load_type: об/с
    график: линия(1, 10, 10м)
  заголовок_http: "1.1"
  заголовки:
    - "[Хост: www.target.example.com]"
    - "[Соединение: закрыть]"
  урис:
    - "/ури1"
    - "/купить"
    - "/sdfg?sdf=rwerf"
    - "/sdfbv/swdfvs/ssfsf"
консоль:
  включено: правда
телеграф:
  включено: ложь
 

Параметр uris содержит uri, который следует использовать для формирования запросов.

Примечание

Обратите внимание на пример выше, потому что пробелы в многострочных uris и заголовках параметров важны.

URI-стиль, URI в файле

Конфигурация YAML-файла: ammo_type: uri

Создать файл с объявленными запросами: ammo.txt

 [Соединение: закрыть]
[Хост: target.example.com]
[Файл cookie: нет]
/?drg тег1
/
/купить тег2
[Файл cookie: тест]
/купить/?rt=0&station_to=7&station_from=9

Файл состоит из списка URI и заголовков, которые должны добавляться к каждому запросу, определенному ниже. Каждый URI должен начинаться с новой строки с ведущими /. Каждая строка, начинающаяся с [ , считается заголовком. Заголовки могут быть (пере)определены в середине URI, как в примере выше.

Пример:

Запрос /buy/?rt=0&station_to=7&station_from=9 будет отправлен с Cookie: test , а не Cookie: None .

Запрос может быть отмечен тегом, вы можете указать его с пробелом после URI.

URI+POST-стиль

Конфигурация YAML-файла: ammo_type: uripost

Создать файл с объявленными запросами: ammo.txt

 [Хост: example.org]
[Подключение: закрыть]
[Агент пользователя: Танк]
5 /маршрут/?rll=50.262025%2C53.276083~50.056015%2C53.495561&origin=1&simplify=1
сорт
10 /маршрут/?rll=50.262025%2C53.276083~50.056015%2C53.495561&origin=1&simplify=1
привет!клас
7 /маршрут/?rll=37,565147%2C55,695758~37.412796%2C55.691454&origin=1&simplify=1
урипост
 

Файл начинается с необязательных строк […], содержащих заголовки, которые добавляться к каждому запросу. После этого раздела идет список URI и тел POST. Каждая строка URI начинается с числа, равного размеру следующего тела POST.

Request-style

Конфигурация YAML-файла: ammo_type: phantom

Полные запросы перечислены в отдельном файле. Для более сложных запросы, такие как POST, вам придется создать специальный файл. Формат файла это:

 [размер_запроса] [тег]\n
[заголовки_запроса]
[тело_запроса]\r\n
[размер_запроса2] [тег2]\n
[request2_headers]
[тело_запроса2]\r\n
 

где size_of_request – размер запроса в байтах. символы ‘rn’ после тело игнорируется и никуда не отправляется, но требуется включать их в файл после каждого запроса. Обратите внимание на образец выше потому что символы «r» строго обязательны.

Примечание

Параметр ammo_type необязателен, тип боеприпаса по умолчанию — стиль запроса.

---

образец запроса GET (пустое тело)

 73 хорошо
ПОЛУЧИТЬ/HTTP/1. J...p.ifTF0<.s.9..
 

---

образец POST составной:

 533
ПОСТ /updateShopStatus? HTTP/1.0
Агент пользователя: xxx/1.2.3
Хост: xxxxxxxxx.dev.example.com
Поддержание жизни: 300
Content-Type: multipart/form-data; граница = АГТУНГ
Длина содержимого: 334
Соединение: Закрыть
--АГТУНГ
Content-Disposition: данные формы; имя = "хост"
load-test-shop-updatestatus.ru
--АГТУНГ
Content-Disposition: данные формы; имя = "идентификатор_пользователя"
1
--АГТУНГ
Content-Disposition: данные формы; name="wsw-поля"
отключить
--АГТУНГ--
 9Образцы генераторов патронов 0081 
 вы можете найти на странице Генераторы боеприпасов. 
  
 Выполнить тест! 
  
 
 Запрос спецификаций в load.yaml — запустить как  yandex-tank -c load.yaml  
 
 Запрос спецификаций в ammo.txt — запустить как  yandex-tank -c load.yaml ammo.txt  
 
 
 Яндекс. Танк определяет формат запросов и формирует предельные запросы
версии. 
 
  yandex-tank  здесь имя исполняемого файла Яндекс.Танка. 
 
 Если Яндекс.Танк установлен правильно и файл конфигурации
правильно, нагрузка будет дана в ближайшие несколько секунд. 
  
 Результаты 
  
 Во время выполнения теста вы увидите ошибки HTTP и сети, время ответа
раздача, прогрессбар и другие интересные данные. В то же время
файл  phout.txt  пишется, который можно было проанализировать позже. 
 
 Если вам нужен более удобочитаемый отчет, вы можете попробовать плагин Report,
Вы можете найти его здесь 
 
 Если вам нужно загрузить результаты во внешнее хранилище, например Graphite или InfluxDB, вы можете использовать один из существующих модулей загрузки артефактов Модули 
  
 Теги 
  
 Запросы могут быть сгруппированы и отмечены каким-либо тегом. 
 
 Пример: 
 
 73 хорошо
ПОЛУЧИТЬ/HTTP/1.0
Хост: xxx.tanks.example.com
Агент пользователя: xxx (оболочка 1)
77 плохо
ПОЛУЧИТЬ /abra HTTP/1. 0
Хост: xxx.tanks.example.com
Агент пользователя: xxx (оболочка 1)
75 неизвестно
ПОЛУЧИТЬ /ab HTTP/1.0
Хост: xxx.tanks.example.com
Агент пользователя: xxx (оболочка 1)
 
  хорошо  ,  плохо  и  неизвестно  вот теги.
 Примечание
  ОГРАНИЧЕНИЕ: только символы utf-8 
 SSL 
 Для активации SSL добавьте  phantom: {ssl: true}  к  load.yaml  .
Теперь наша базовая конфигурация выглядит так:
 фантом:
  адрес: 203.0.113.1:443
    Загрузить профиль:
      load_type: об/с
      график: линия(1, 10, 10м)
  SSL: правда
 
 Примечание
 Не забудьте указать ssl порт на  адрес  . В противном случае вы можете получить «ошибки протокола».
 Автостоп 
 Автостоп — это возможность автоматически останавливать выполнение теста
если выполняются некоторые условия.
 Условия кодов HTTP и Net 
 Существует возможность определить конкретные коды (404,503,100), а также код
группы (3хх, 5хх, хх). Также вы можете определить относительный порог (проценты
от всего количества ответов в секунду) или абсолютное (количество
ответов с указанным кодом в секунду).
 Примеры:
  autostop: http(4xx,25%,10)  – проверка остановки, если количество 4xx http кодов в каждую секунду последних 10 секунд превышает 25% ответов (относительный порог).
  autostop: net(101,25,10)  – проверка остановки, если количество 101 net-кода в каждую секунду периода последних 10 с больше 25 (абсолютный порог).
  autostop: net(xx,25,10)  – проверка остановки, если количество ненулевых net-кодов в каждую секунду последних 10 секунд превышает 25 (абсолютный порог).
 Условия среднего времени 
 Пример:
  autostop: time(1500,15)  – останавливает тест, если среднее время ответа превышает 1500мс.
 Итак, если мы хотим остановить тест, когда все ответы в 1-секундном периоде будут 5xx плюс некоторые сетевые и временные факторы - добавьте строку autostop в load. yaml:
 phantom:
  адрес: 203.0.113.1:80
  Загрузить профиль:
    load_type: об/с
    график: линия(1, 10, 10м)
авто стоп:
  авто стоп:
    - время (1 с, 10 с)
    - http(5xx,100%,1с)
    - нетто(хх,1,30)
 
 Результаты в phout 
 phout.txt - это журнал для каждого запроса. Это может быть использовано для поведения службы
анализ (Excel/gnuplot/и т.д.) Он имеет следующие поля:  time, tag, interval_real, connect_time, send_time, latency, Receive_time, interval_event, size_out, size_in, net_code proto_code 
 Пример Phout:
 1326453006.582 1510 934 52 384 140 12 49 37 478 0 404
1326453006,582 прочие 1301 674 58 499 70 1116 37 478 0 404
1326453006.587 тяжелый 377 76 33 178 90 180 37 478 0 404
1326453006.587 294 47 27 146 74 147 37 478 0 404
1326453006,588 345 75 29 166 75 169 37 478 0 404
1326453006,590 276 72 28 119 57 121 53 476 0 404
1326453006,593 255 62 27 131 35 134 37 478 0 404
1326453006,594 304 50 30 147 77 149 37 478 0 404
1326453006,596 317 53 33 158 73 161 37 478 0 404
1326453006,598 257 58 32 106 61 110 37 478 0 404
1326453006. 602 315 59 27 160 69 161 37 478 0 404
1326453006,603 256 59 33 107 57 110 53 476 0 404
1326453006,605 241 53 26 130 32 131 37 478 0 404
 
 Примечание
 содержимое phout зависит от версии фантома, установленной в вашей системе Яндекс.Танк.
 сетевые коды — это системные коды из errno.h, в большинстве систем на основе Debian это:
 1 EPERM Операция не разрешена
2 ENOENT Нет такого файла или каталога
3 ESRCH Нет такого процесса
4 EINTR Прерванный системный вызов
5 Ошибка ввода/вывода EIO
6 ENXIO Нет такого устройства или адреса
7 E2BIG Слишком длинный список аргументов
8 Ошибка формата ENOEXEC Exec
9 EBADF Неверный файловый дескриптор
10 ECHILD Нет дочерних процессов
11 Ресурс EAGAIN временно недоступен
12 ENOMEM Не удается выделить память
13 EACCES Отказано в доступе
14 EFAULT Неверный адрес
15 ENOTBLK Требуется блочное устройство
16 EBUSY Устройство или ресурс занят
17 EEXIST Файл существует
18 EXDEV Недопустимая ссылка между устройствами
19ENODEV Нет такого устройства
20 ENOTDIR Не каталог
21 EISDIR — это каталог
22 EINVAL Неверный аргумент
23 ENFILE Слишком много открытых файлов в системе
24 EMFILE Слишком много открытых файлов
25 ENOTTY Неподходящий ioctl для устройства
26 ETXTBSY Текстовый файл занят
27 EFBIG Файл слишком большой
28 ENOSPC На устройстве не осталось места
29 ESPIPE Незаконный поиск
30 EROFS Файловая система только для чтения
31 EMLINK Слишком много ссылок
32 EPIPE Сломанная труба
33 EDOM Числовой аргумент вне домена
34 ERANGE Числовой результат вне допустимого диапазона
35 EDEADLOCK Устранена взаимоблокировка ресурсов
36 ENAMETOOLONG Имя файла слишком длинное
37 ENOLCK Нет доступных замков
38 ENOSYS Функция не реализована
39ENOTEMPTY Каталог не пустой
40 ELOOP Слишком много уровней символических ссылок
42 ENOMSG Нет сообщения нужного типа
43 Идентификатор EIDRM удален
44 ECHRNG Номер канала вне допустимого диапазона
45 EL2NSYNC Уровень 2 не синхронизирован
46 EL3HLT Уровень 3 остановлен
47 EL3RST Уровень 3 сброс
48 ELNRNG Номер канала вне допустимого диапазона
49 Драйвер протокола EUNATCH не подключен
50 ENOCSI Нет доступной структуры CSI
51 EL2HLT Уровень 2 остановлен
52 EBADE Неверный обмен
53 EBADR Неверный дескриптор запроса
54 EXFULL Полный обмен
55 ЭНОАНО Без анода
56 EBADRQC Неверный код запроса
57 EBADST Недопустимый слот
59EBFONT Неверный формат файла шрифта
60 ENOSTR Устройство не является потоком
61 ЭНОДАТА Данных нет
62 ETIME Время таймера истекло
63 ENOSR Ресурсы вне потока
64 ENONET Машина не в сети
65 Пакет ENOPKG не установлен
66 EREMOTE Объект удален
67 ENOLINK Ссылка была разорвана
68 Ошибка рекламы EADV
69 ESRMNT Ошибка запуска
70 ECOMM Ошибка связи при отправке
71 Ошибка протокола EPROTO
72 EMULTIHOP Многоскачковая попытка
73 EDOTDOT специфическая ошибка RFS
74 EBADMSG Плохое сообщение
75 EOVERFLOW Слишком большое значение для определенного типа данных
76 ENOTUNIQ Имя не уникально в сети
77 EBADDFD Файловый дескриптор в плохом состоянии
78 EREMCHG Удаленный адрес изменен
79ELIBACC Не удается получить доступ к необходимой общей библиотеке
80 ELIBBAD Доступ к поврежденной общей библиотеке
81 Раздел ELIBSCN . lib в a.out поврежден
82 ELIBMAX Попытка связать слишком много разделяемых библиотек
83 ELIBEXEC Не удается напрямую запустить разделяемую библиотеку
84 EILSEQ Недействительный или неполный многобайтовый или расширенный символ
85 ERESTART Прерванный системный вызов должен быть перезапущен
86 ESTRPIPE Ошибка канала потоков
87 EUSERS Слишком много пользователей
88 ENOTSOCK Операция сокета без сокета
89EDESTADDRREQ Требуется адрес назначения
90 EMSGSIZE Сообщение слишком длинное
91 EPROTOTYPE Протокол неправильного типа для сокета
92 ENOPROTOOPT Протокол недоступен
93 Протокол EPROTONOSUPPORT не поддерживается
94 ESOCKTNOSUPPORT Тип сокета не поддерживается
95 ENOTSUP Операция не поддерживается
96 Семейство протоколов EPFNOSUPPORT не поддерживается
97 EAFNOSUPPORT Семейство адресов не поддерживается протоколом
98 EADDRINUSE Адрес уже используется
99 EADDRNOTAVAIL Невозможно назначить запрошенный адрес
100 ENETDOWN Сеть не работает
101 ENETUNREACH Сеть недоступна
102 ENETRESET Сеть разорвала соединение при перезагрузке
103 ECONNABORTED Программное обеспечение вызвало разрыв соединения
104 ECONNRESET Сброс соединения узлом
105 ENOBUFS Нет свободного места в буфере
106 Транспортная конечная точка EISCONN уже подключена
107 ENOTCONN Транспортная конечная точка не подключена
108 ESHUTDOWN Не удается отправить после отключения конечной точки транспорта
109ETOOMANYREFS Слишком много ссылок: невозможно соединить
110 ETIMEDOUT Время ожидания соединения истекло
111 ECONNREFUSED В соединении отказано
112 EHOSTDOWN Хост не работает
113 EHOSTUNREACH Нет маршрута к хосту
114 EALREADY Операция уже выполняется
115 EINPROGRESS Выполняется операция
116 ESTALE Устаревший дескриптор файла
117 EUCLEAN Структура нуждается в очистке
118 ENOTNAM Не является файлом именованного типа XENIX
119 ENAVAIL Нет доступных семафоров XENIX
120 EISNAM Является файлом именованного типа
121 EREMOTEIO Ошибка удаленного ввода/вывода
122 EDQUOT Дисковая квота превышена
 
 Ограничение потоков 
  экземпляров: N  в  load.