ЗАДАЧИ: IP-синхронизация / Асинхронный режим работы

ОБЩАЯ ИНФОРМАЦИЯ

Режим IP-синхронизации является уникальной разработкой команды SocialKit. Этот режим позволяет в асинхронном режиме (попеременно) работать большому числу Instagram-аккаунтов на одном IP с минимальными задержками между действиями, что, в свою очередь, позволяет практически полностью решить проблему спам-блокировок.

Как известно, SocialKit - многопоточное, многозадачное приложение, в котором вы можете запускать в одновременную работу на подписку, лайки, комментарии, автопостинг и другие действия сотни аккаунтов. Однако, чем больше Instagram-аккаунтов в работе, тем выше вероятность, что вы столкнетесь с массовыми спам-блокировками, которым может быть проблематично противостоять. Это связано с тем, что большинство даже опытных пользователей недооценивают силу аналитических алгоритмов Instagram, которые способны достаточно точно выявлять сетки аккаунтов и раздавать им спам-блокировки. В основе этих алгоритмов лежит выявление однотипности в действиях от имени разных аккаунтов при схожих технических данных. Особенно ситуация усугубляется, когда используются прокси из минимально обобщенных подсетей. По теме спам-блокировок есть отдельная статья, в которой мы описываем все известные нам способы противодействия спам-блокировкам, приводим рабочие кейсы. В одном из пунктов в этой статье идёт отсылка как раз к асинхронному режиму работы, который вышеизложенную схему блокировки делает неработоспособной.

В режиме IP-синхронизации группа Instagram-аккаунтов в пределах одного IP (прокси), в качестве которого может выступать и "родной" IP-адрес, работает попеременно, а не одновременно, что не позволяет аналитическому алгоритму Instagram с легкостью выявить всю сетку аккаунтов, даже если IP остаётся неизменным, а технические данные устройства и выполняемые действия однотипными. Это связано с тем, что выполняемые однотипные действия могут быть достаточно сильно растянуты во времени и не пересекаться. Чем больше Instagram-аккаунтов работает на одном IP в асинхронном режиме, тем ниже вероятность того, что они будут получать спам-блокировки в ходе работы. Т.е. мы имеем эффект, противоположный эффекту при продвижении в одновременном (синхронном) режиме, именно из-за увеличения длины очереди при фиксированных тайм-аутах между действиями. Разумеется, при этом пропорционально будет уменьшаться и число выполненных действий в сутки от имени каждого из Instagram-аккаунтов, синхронизируемых в пределах того или иного IP. Потому при работе в режиме IP-синхронизации важно найти "золотую середину" - это оптимальное число аккаунтов в пределах одного IP и особая настройка самой задачи для того, чтобы потери в суточных объёмах выполненных действиях были минимальны. Всё это более детально поясняется ниже. В том числе на конкретных примерах в разделах "Расчёты" и "Кейсы".

ВАЖНО! Обратите внимание, что каждая IP-группа работает друг от друга независимо и Instagram-аккаунты в пределах каждой IP-группы синхронизируются, соответственно, независимо друг от друга.

Управлять количеством синхронизируемых IP-групп и числом аккаунтов в каждой из них вы можете при помощи самих IP-адресов (прокси). В каждой IP-группе может быть произвольное число Instagram-аккаунтов.

▼ ПЕРЕЙТИ К ВЫВОДАМ ▼

▼ ПЕРЕЙТИ К FAQ ▼

КРАТКОЕ ОПИСАНИЕ НАСТРОЕК

По умолчанию асинхронный режим работы настроен так, что Instagram-аккаунты будут сменять друг друга по кругу каждые 6-12 подписок, лайков и т.д. (смотря какая задача настраивается), в зависимости от того, на каком из аккаунтов действия были выполнены позже всего. Для каждой задачи, где поддержка асинхронного режима работы реализована, соответствующий блок настроек находится на закладке "Тех. настройки" -> "IP-синхронизация".

Блок, отвечающий за активацию и настройку режима IP-синхронизации.

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

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

Активация режима сёрфинга для аккаунта, находящихся в состоянии синхронизации.

Отметим, что этот режим сёрфинга никак не связан с сёрфингом с привязкой к действиям, который находится на закладке "Тех. настройки" -> "Алгоритмы". Использовать оба режима сёрфинга особого смысла нет, т.к. это будет лишь затормаживать общую производительность синхронизируемой IP-группы.

Тайм-аут между действиями также можно поставить предельно маленький. Достаточно будет задержки в несколько секунд, но только в случае, если переход к следующему аккаунту в пределах IP-группы будет осуществлён достаточно быстро. Например, согласно настройкам умолчания в 6-12 действий.

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

Режим "Игнорировать тайм-аут при спам-блокировке, но не завершать работу" - активирован по умолчанию.

Другая очень важная настройка - "Игнорировать тайм-аут при спам-блокировке", которая активирована по умолчанию. Как известно, по умолчанию программа настроена таким образом, что при обнаружении спам-блокировки в той или иной задаче программой предпринимается несколько попыток пропустить заблокированное действие (по умолчанию 3 попытки), а после вся задача или заблокированное действие (в зависимости от настроек и типа задачи) переводится в режим ожидания на указанное в экспертных настройках или в настройках перекрытия задачи время. После истчечения тайм-аута задача продолжается и так по кругу, до тех пор, пока не будет выполнена поставленная задача.

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

Разумеется, можно настроить задачу, поддерживающую режим IP-синхронизации, так, что при обнаружении спам-блокировки на том или ином Instagram-аккаунте из той или иной IP-группы в конечном итоге не будет выполняться перевод задачи на тайм-аут, а будет выполнено её завершение, после чего программа перейдёт к другим аккаунтам, или продолжение выполнения не заблокированных действий (для составных задач). Это не всегда удобно, т.к. спам-блокировку, когда она выдаётся на связку "аккаунт<->прокси(IP)" легко разрушить сменой оконцовочного IP - этим свойством с той или иной периодичностью обладают, пожалуй, все популярные мобильные прокси на рынке. Соответственно, остановленный аккаунт придется либо перезапускать вручную, либо он будет простаивать зря. С активной же опцией "Игнорировать тайм-аут при спам-блокировке" программа просто приостановит работу по проблемному аккаунту вместо перевода задачи на тайм-аут и перейдёт к следующим аккаунтам из текущей IP-группы. Кстати, отметим, что блокировку на связку "аккаунт<->прокси(IP)" можно разрушить не только сменой оконцовочных IP, а и сменой технических данных. Больше информации об этом виде блокировок можно найти в данной большой статье.

РАСЧЁТЫ

Главным недостатком такого подхода может стать количество выполненных действий в целом, в срезе всех работающих Instagram-аккаунтов. Немного математики, чтобы понять и по максимуму избежать простоев. Допустимая интенсивность подписок в современных реалиях не может превышать 1000 действий в сутки, что соответствует примерно 1 действию в 70 секуд (сделаем небольшую погрешность). Группа из 10 аккаунтов в самых идеальных условиях сможет сделать не более 10 000 подписок в сутки. Соответственно, тайм-ауты рассчитываются по простой формуле: T = Ds / E, где T - тайм-аут между целевыми действиями, Ds - количество секунд в сутках (константа = 86400), E - число целевых действий для всей группы аккаунтов. Учитывая, что рекомендованный тайм-аут при суточном распределении 1000 подписок равен 66-86 секунд, то для 10 000 подписок он, соответственно, будет равен 6-8 секундам.

Режим IP-синхронизации позволяет снизить тайм-ауты ещё сильнее - примерно до 5 секунд между действиями, что в 14 раз меньше рекомендованного тайм-аута при одновременном режиме работы для каждого аккаунта. Таким образом, мы получаем максимальный предел производительности для самого режима примерно в 17 000 подписок в сутки. Т.е. это означает, что в идеальных условиях в режиме IP-синхронизации при всех отключенных дополнительных действиях можно выжать из каждого IP до 17 000 целевых действий в сутки. Однако, 10 аккаунтов не смогут реализовать этот потенциал из-за ограничений на суточный объём от имени каждого аккаунта. При такой интенсивности нужно не менее 16-17 аккаунтов - это и есть максимально допустимая (гипотетическая) планка для числа последовательно работающих аккаунтов в пределах одного IP без потерь в объёме.

Как известно, один приватный мобильный канал без слишком большого числа спам-блокировок не потянет более 18-20 аккаунтов, работающих параллельно со средним безопасным тайм-аутом в 70 секунд. Если говорить об обычных прокси, то отношение вообще должно быть 1 к 1. Следовательно, режим IP-синхронизации при определённых подходах может: 1 - экономить деньги, 2 - кратно снижать спам-блокировки.

ВАЖНО! Таким образом, в режиме IP-синхронизации важно найти удачный баланс между числом аккаунтов, асинхронно работающих в пределах каждой IP-группы, тайм-аутом между действиями и числом дополнительных действий помимо подписок (лайки, просмотр Stories, синхронизация, сёрфинг и т.д.), чтобы не терять в суточном объёме при работе группы аккаунтов асинхронно. Однако, следует понимать, что лимитов на число аккаунтов, работающих асинхронно с одного IP (прокси) нет. Это может быть и 10 аккаунтов, и 100 аккаунтов и даже 1000. Чем больше аккаунтов в группе, тем реже каждый из них будет выполнять целевые действия (подписка, лайки, комментарии и т.д.). Следует также понимать, что особенность работы мобильных прокси (с автосменой оконцовочного IP) также нужно учитывать при расчётах.

Если, скажем, группа из 10 аккаунтов в режиме IP-синхронизации не успевает выполнить по 1000 действий в сутки из-за того, что мобильный прокси во время смены оконцовочного IP оказывается неработоспособным (нормальное явление), то нужно: уточнить у поставщика прокси, нет ли ограничений на объём действий с этих прокси, пересмотреть настройки тайм-аутов в экспертных настройках в соответствующем блоке (см. ниже), отключить дополнительные действия (просмотры Stories, например, и/или синхронизацию виртуального устройства), уменьшить число синхронизируемых аккаунтов в каждой IP-группе, скажем, до 8 или до 5 - по ситуации.

ВАЖНО! Обратите внимание, что прокси, рассчитанные на работу ограниченного числа аккаунтов, т.е. имеющие некую ограничительную логику на своей стороне могут не допускать работу на таких объёмах в режиме IP-синхронизации. Например, это касается мобильных прокси, что могут быть ограничены на работу с одним аккаунтом или небольшим их числом. Организовать на таких лимитированных прокси очень быструю работу большого числа аккаунтов (даже попеременно) не получится из-за ограничительных мер на стороне поставщика прокси. Потому такой метод работы хорошо будет показывать себя лишь в том случае, если ваши прокси не имеют жестких ограничительных мер или рассчитаны на работу соответствующего или примерно соответствующего числа аккаунтов. Кейсы, демонстрирующие, как можно найти оптимальное соотношение числа попеременно работающих аккаунтов на максимальном объёме к тайм-аутам между каждым целевым действием на лимитированных прокси, также представлены ниже.

КЕЙС 1

Теоретическая часть может показаться сложной для восприятия, но на практике всё более, чем просто. Рассмотрим пример, в котором у нас есть 10 Instagram-аккаунтов. Также имеется 1 мобильный IP (в данном кейсе использовался приватный прокси-канал от SocProxy) и "родной" IP (Интернет-соединение по умолчанию). Требуется разбить аккаунты на две асинхронные IP-группы, работающие параллельно.

Аккаунты - трастовые возрастные бруты, подготовленные к работе согласно нашим рекомендациям.

Чтобы во время выполнения задачи была правильная реакция на потенциально возможные спам-блокировки, а также на потенциально возможные ошибки прокси, возникающие при изменении оконцовочных IP, на изменим несколько блоков в экспертных настройках, как показано на скриншоте ниже.

Состояние экспертных настроек в главном окне программы для рассматриваемого примера

Первый изменённый блок - это уменьшение диапазона для выбора тайм-аута при обнаружении спам-блока для того или иного действия (поля ввода "Тайм-аут при временной спам-блокировке"). По умолчанию эти значения значительно больше - около 700 минут, что рассчитано на случай, когда блок тому или иному действию выдаётся не на связку "аккаунт<->прокси(IP)" за подозрение в спам-действиях, а на само действие за превышение допустимых суточных лимитов. Как бы там ни было, в нашем примере это не важно, т.к. в режиме IP-синхронизации нам нужно пропускать эти тайм-ауты, чтобы ко всем аккаунтам из поточной IP-группы доходила очередь на выполнение.

Следующий изменённый блок - "Уровень применения логики". По умолчанию в программе выставлено "Ко всей задаче". Это говорит о том, что при обнаружении спам-блока на какое-то действие в составных задачах (например, МФ + МЛ) после установленного числа повторов (поле "Число пропусков перед тайм-аутом") заблокированного действия для других доноров из списка, по которому идёт работа в задаче она будет продолжаться до тех пор, пока работает хотя бы одно из действий. Например, для задачи МФ + МЛ, если спам-блокировка будет выдана на МФ, то будут продолжаться МЛ, если спам-блокировка будет выдана на МЛ, то будет продолжаться МФ. В нашем примере это не очень удобно, т.к. мы точно знаем, что суточные лимиты для аккаунтов превышены не будут ни для МФ, ни для МЛ, а вот блокировка какого-то действия вида "аккаунт<->прокси(IP)" в ходе работы задачи гипотетически возможна - её будет автоматически разрушать смена оконцовочного IP у используемого мобильного прокси. Т.е. нам нужно просто переждать немного времени, переключившись на другие аккаунты из поточной IP-группы. Потому в нашем примере мы использовали уровень применения логики "К действиям". Таким образом, если МФ или МЛ получит спам-блокировку, то вся задача будет переведена на тайм-аут, а не какое-то одно из действий. Общий же тайм-аут для спам-блокировки поможет проигнорировать переключатель "Игнорировать тайм-аут при спам-блокировке, но не завершать работу" в настройках задачи, о котором мы упоминали выше - он активирован по умолчанию при работающей IP-синхронизации.

Напоминаем, что объяснение многих специальных терминов можно найти в этой статье.

Все остальные изменённые опции из экспертных настроек не особо важны в данном примере, что следует из их названия. Основное их предназначение - экономия временных затрат при ожидании. Можно выделить разве что увеличенный с нулевых значений "Тайм-аут при массовом запуске заданий". Не смотря на то, что аккаунты всё равно не будут стартовать одновременно в пределах каждой IP-группы, т.к. в примере подразумевается не параллельная работа, а асинхронная мы рекомендуем всегда по возможности выставлять хотя бы минимальные тайм-ауты в 2-3 секунды при массовом запуске заданий - это позволяет уменьшать пиковые нагрузки на аппаратное обеспечение в определённых ситуациях и делать работу с Instagram более рандомной даже в мелочах.

Если же вы пытаетесь достигнуть максимального объёма по действиям у максимально возможного числа аккаунтов в пределах синхронизируемой группы, то настройки прочих тайм-аутов (в выделенных блоках на скриншоте) для вас также будут важны. Например, "Тайм-аут между проверками при ошибке соединения" и "Тайм-аут после восстановления".

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

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

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

Остальные настройки асинхронной работы мы оставили по умолчанию.

Настройка тайм-аутов для подписок и настройка случайных лайков в диапазоне.

Настройка тайм-аутов для лайков и активация режима просмотра Instagram Stories.

Число действий по умолчанию для перехода к следующему аккаунту в пределах каждой IP-группы мы снизили в два раза (до 3-6 действий), т.к. каждая IP-группа содержит всего 5 аккаунтов, а тайм-ауты по той же причине немного увеличили. К тому же, исходя из того, что мы будем дополнительно расставлять случайное число лайков (от 0 до 2) с минимальным интервалом в 1-2 секунды, то требование к общему тайм-ауту между действиями вычисляется по формуле: произведение максимально возможного числа лайков в пределах каждого донора на максимально возможный тайм-аут между лайками в пределах каждого донора. В нашем примере это 2 лайка * 2 секунды = 4 секунды.

Не стоит забывать также, что процедура просмотра Stories тоже требует расходов по времени - это минимум 3-4 секунды.

ВАЖНО! Ещё раз подчеркнём, если ваши мобильные прокси не обладают хорошей пропускной способностью (а такое бывает очень часто, как минимум, из-за смены оконцовочных IP), то каждое дополнительное действие в ходе подписок увеличивает расход времени и потому все действия могут просто не успеть вписаться в установленный между подписками тайм-аут в 4-8 секунд. Это легко можно определить по логу любого целевого аккаунта из той или иной синхронизируемой IP-группы. Если это так и вы хотите выжимать из каждого работающего аккаунта максимально возможный суточный объём действий, то выход очень прост - либо немного уменьшить число синхронизируемых аккаунтов (например, с 10 до 5-8) в той или иной группе при тех же тайм-аутах, либо отключить часть дополнительных действий, либо сделать и то, и другое.

Пример успешной работы двух IP-групп из 10 аккаунтов (по 5 аккаунтов в каждой) в режиме IP-синхронизации.

Режим контролируемых потоков отключён.

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

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

КЕЙС 2

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

Под фразой "рассчитан на массовую работу" понимается в принципе любой прокси, не имеющий ограничений на стороне прокси-провайдера. Т.е. это тариф, позволяющий использовать вам и только Вам весь приватный канал. Иными словами, только вы имеете доступ к SIM'ке, на которой работает этот прокси. Такие приватные каналы рассчитаны, как правило, на одновременное продвижение до 20 Instagram-аккаунтов.

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

Сформируем две группы: из 15 и из 10 аккаунтов с одинаковыми настройками.

Экспертные настройки взяты из предыдущего кейса. Настройки тайм-аутов для лайков и подписок:

Настройка тайм-аутов для подписок и лайков, отключение режима просмотра Instagram Stories.

Объём лайков будет выбираться случайным образом до 0 до 2, просмотры Stories отключим, а также отключим синхронизацию виртуальных устройств с серверами Instagram, как показано на скриншоте ниже.

Отключение режима синхронизации виртуальных устройств с серверами Instagram.

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

Число подписок для каждого аккаунта перед переключением:

Число действий, необходимых для перехода к следующему аккаунту в IP-группе.

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

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

Производительность 10 аккаунтов (подписки + лайки) на мобильных прокси в часовом срезе.

Режим контролируемых потоков в задачах активирован.

Архив с логами по всем 10 аккаунтам находится по этой ссылке. Если ваш антивирус будет "ругаться" на ссылку, то просто добавьте домен "http://admin.had.su/" в список исключений антивируса - это просто архив с текстовыми файлами.

За час группа из 10 аккаунтов выполнила 331 действие. В суточном срезе это даёт почти 8000 подписок (7944) с переменным числом лайков от 0 до 2 из предельно допустимых 10 000 подписок для группы из 10 аккаунтов. Понятно, что какой-то час может быть более эффективным, а какой-то менее - это тоже переменные величины, зависящие, как минимум, от скорости и стабильности мобильных прокси, скорости отклика серверов Instagram при обращении через них, стабильности Интернет-соединения по умолчанию и от того, как и сколько аккаунтов будет пропущено в ходе работы задачи. Так, например, по графе "Прогресс" из кейса выше видно, что для некоторых продвигаемых аккаунтов были пропуски доноров, т.к. они уже были подписаны (никаких других условий в настройках задачи активировано не было) на того или иного донора. Не забываем, что это тоже время, т.к. перед подпиской на того или иного донора программа, как минимум, проверяет, а не подписаны ли мы на него уже. Каждая такая проверка - это запрос к серверу Instagram через прокси, а, следовательно, временные растраты.

Таким образом, у нас получается ориентировочный суточный объём в 800 подписок из предельных 1000 для каждого из 10 аккаунтов - это отличный по эффективности результат в современных реалиях продвижения.

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

Производительность 10 аккаунтов (подписки + лайки) на мобильных прокси в часовом срезе.

Режим контролируемых потоков в задачах отключён.

За час группа из 10 аккаунтов выполнила приблизительно 396 действий (~9500 за сутки). Т.е. результат получился ощутимо лучше, чем в предыдущем тесте группы из 10 аккаунтов. Следовательно, режим контролируемых потоков влияет на объём выполненных действий тем сильнее, чем минимальнее тайм-ауты между целевыми действиями и чем больше дополнительных действий совершает каждый из аккаунтов в той или иной IP-группе.

Запускаем задание для 15 аккаунтов с указанными выше настройками.

Производительность 15 аккаунтов (подписки + лайки) на мобильных прокси в часовом срезе.

Режим контролируемых потоков в задачах активирован.

За час группа из 15 аккаунтов выполнила 329 действий - почти такой же результат, как и выше для группы из 10 аккаунтов в режиме контролируемых потоков только от имени большого числа аккаунтов. Следовательно, суточный объём всей группы будет таким же, а вот суточный объём выполненных действий у каждого аккаунта уменьшится. Таким образом, он будет составлять уже не ~800 подписок, а ~520 в зависимости от эффективности на том или ином часе работы.

Производительность 15 аккаунтов (подписки + лайки) на мобильных прокси в часовом срезе.

Режим контролируемых потоков в задачах отключён.

Архив с логами по всем 15 аккаунтам находится по этой ссылке. Если ваш антивирус будет "ругаться" на ссылку, то просто добавьте домен "http://admin.had.su/" в список исключений антивируса - это просто архив с текстовыми файлами.

Практические идеальное сходство по объёму действий в пределах всей группы. За час группа из 15 аккаунтов выполнила приблизительно 396 действий (~9500 за сутки). Т.е. результат получился ощутимо лучше, чем в предыдущем тесте группы из 15 аккаунтов с активированным режимом контролируемых потоков и таким же точно по общему объёму выполненных действий, как в тесте группы из 10 аккаунтов с отключенным режимом контролируемых потоков. Таким образом, суточный объём каждого аккаунта получится в районе 630 целевых действий (подписок в нашем тесте).

Обратите внимание, что во всех тестах из данного кейса мы акцентируем внимание только на целевых действиях (в кейсах выше это подписки). Т.к. лайки являются второстепенным действием и расставляются случайным образом от 0 до 2, то их объём рассматривать смысла нет.

Сравниваем результаты.

Совершенно очевидно, что объём аккаунтов в группе напрямую влияет на объём выполненных действий от имени каждого из синхронизируемых аккаунтов. Только лишь уменьшая или увеличивая число Instagram-аккаунтов в каждой IP-группе, легко можно управлять объёмом выполненных действий от имени каждого аккаунта - запомните этот тезис.

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

КЕЙС 3

В данном кейсе мы рассмотрим пример того, как можно подобрать оптимальное число попеременно работающих аккаунтов (в режиме IP-синхронизации) на шаред мобильных прокси. По мере проведения тестов мы начнём с прокси, предназначенного для 1го аккаунта, и постепенно будем увеличивать число аккаунтов в настройках самих прокси, наблюдая за тем, какой объём при этом выдаёт группа Instagram-аккаунтов превышающая лимит из настроек самих прокси.

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

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

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

Попробуем использовать его для того, чтобы выжать суточный максимум из трёх Instagram-аккаунтов, объёдинённых в данную IP-группу. Это 3000 целевых действий (подписок) со всей группы.

Т.к. аккаунты работают попеременно, объединяясь в одно целое, то средний тайм-аут рассчитывается по простой формуле: 1000 * 3 / 24 = ~125 целевых действий (подписок) в час должна сделать вся группа. На основе этой информации рассчитываем средний тайм-аут: 60*60 / 125 = ~29 секунд.

Корректируем блок с тайм-аутами в настройках задачи соответствующим образом.

Установка настроек тайм-аутов в соответствии с проведенными рассчётами.

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

Производительность 3 аккаунтов (подписка + лайк) на лимитированных мобильных прокси в часовом срезе.

Режим контролируемых потоков в задачах отключён.

Архив с логами по всем 3 аккаунтам находится по этой ссылке. Если ваш антивирус будет "ругаться" на ссылку, то просто добавьте домен "http://admin.had.su/" в список исключений антивируса - это просто архив с текстовыми файлами.

За чуть более, чем час работы аккаунты сделали в сумме ~66 целевых действий (подписок) из ожидаемых ~125, что в два раза ниже той производительности, на которую способны три одновременно работающих Instagram-аккаунта. Это указывает на то, что система защиты на стороне поставщика услуг прокси очень часто лимитировала частоту, с которой выполнялись действия. Возможно, некоторый прирост по подпискам можно будет получить, если отключить расстановку лайков в ходе выполнения подписок.

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

Т.к. аккаунты работают попеременно, объединяясь в одно целое, то средний тайм-аут рассчитывается по простой формуле: 1000 * 2 / 24 = ~83 целевых действия (подписок) в час должна сделать вся группа. На основе этой информации рассчитываем средний тайм-аут: 60*60 / 83 = ~43 секунды.

Корректируем блок с тайм-аутами в настройках задачи соответствующим образом.

Установка настроек тайм-аутов в соответствии с проведенными рассчётами.

Производительность 2 аккаунтов (подписка + лайк) на лимитированных мобильных прокси в часовом срезе.

Режим контролируемых потоков в задачах отключён.

Архив с логами по всем 2 аккаунтам находится по этой ссылке. Если ваш антивирус будет "ругаться" на ссылку, то просто добавьте домен "http://admin.had.su/" в список исключений антивируса - это просто архив с текстовыми файлами.

За час работы аккаунты сделали в сумме ~61 целевое действие (подписки) из ожидаемых ~83, что, опять же, ниже той производительности, на которую способны два одновременно работающих Instagram-аккаунта. Это указывает на то, что система защиты на стороне поставщика услуг прокси снова периодически лимитировала частоту, с которой выполнялись целевые действия. Однако, если принять за допустимую норму не 1000 подписок в сутки для каждого аккаунта, а, скажем, 800 (безопасная верхняя граница), то мы как раз получим идеальное соотношение числа действий к цене этого действия. Стоимость продвижения одного аккаунта при этом будет равняться всего лишь 40 рублям в месяц, т.е. режим IP-синхронизации позволил снизить затраты вдвое путем небольшого снижения суточных объёмов для целевых действий.

Тест 2. Мобильный прокси, предназначенный для продвижения 2ух аккаунтов.

Попробуем использовать прокси, который лимитирован для одновременного продвижения 2ух аккаунтов для того, чтобы выжать суточный максимум из 4ёх Instagram-аккаунтов, работающих попеременно в бъёдинённой IP-группе. Идеальный максимум при этом будет составлять 4000 целевых действий (подписок) со всей группы.

Т.к. аккаунты работают попеременно, объединяясь в одно целое, то средний тайм-аут рассчитывается по простой формуле: 1000 * 4 / 24 = ~167 целевых действий (подписок) в час должна сделать вся группа. На основе этой информации рассчитываем средний тайм-аут: 60*60 / 167 = ~22 секунды.

Корректируем блок с тайм-аутами в настройках задачи соответствующим образом.

Установка настроек тайм-аутов в соответствии с проведенными расчётами.

Производительность 4 аккаунтов (подписка + лайк) на лимитированных мобильных прокси в часовом срезе.

Режим контролируемых потоков в задачах отключён.

Архив с логами по всем 4 аккаунтам находится по этой ссылке. Если ваш антивирус будет "ругаться" на ссылку, то просто добавьте домен "http://admin.had.su/" в список исключений антивируса - это просто архив с текстовыми файлами.

За час работы аккаунты сделали в сумме ~204 целевых действия (подписки) из ожидаемых ~167, что существенно выше ожидаемого результата. Это указывает на то, что можно смело попробовать на лимитированном прокси для двух аккаунтов продвигать 5, снижая стоимость продвижения одного аккаунта до 30 рублей без потерь или практически без потерь в предельно допустимых суточных объёмах каждого аккаунта.

Обратите внимание, что во всех тестах из данного кейса мы акцентируем внимание только на целевых действиях (в кейсах выше это подписки). Т.к. лайки являются второстепенным действием и расставляются случайным образом от 0 до 2, то их объём рассматривать смысла нет.

Также все тестовые прогоны в этом кейсе осуществлялись с отключенным режимом контролируемых потоков. Если используемые вами прокси подвержены проблеме неконтролируемых прерываний запросов, описываемой в данной статье, и требуется работать с активированным режимом контролируемых потоков, то выход на те же объёмы будет достигаться незначительным уменьшением тайм-аутов между действиями. Исходя из расчётов, проведенных в Кейсе 2, в режиме контролируемых потоков объём снижается примерно на 10%. Следовательно, нужно уменьшить тайм-ауты на эти же 10%. Т.к. на рассматриваемых лимитированных прокси есть запас времени между действиями, то учесть данную погрешность не составит труда.

ВЫВОДЫ

ВАЖНО! Таким образом, исходя из практических кейсов, можно сделать вывод, что:

I). На объём выполненных целевых действий от имени всей синхронизируемой группы влияют как прямые, так и косвенные факторы. Прямые факторы это: а) - тайм-ауты между целевыми действиями, тайм-ауты при возникновении различных ошибок и нарушениях в логике, пользовательские перерывы; б) - дополнительные действия и технические настройки, которые могут сопровождать целевые действия, например, просмотр Stories, частота синхронизация виртуального устройства с серверами Instagram, частота сёрфинга и т.п. Косвенные факторы это: а) - число пропущенных аккаунтов, на которые уже осуществлена подписка (если речь о задаче "Подписка (+Лайки)"); б) - различные фильтры, которые также приводят к пропуску аккаунтов; в) - временные спам-блокировки в процессе выполнения тех или иных целевых действий и т.п.

II). На объём выполненных целевых действий от имени всей синхронизируемой группы влияет также Интернет-соединение. Причем, нужно не забывать о каждом из узлов в общей цепи: а) - пропускная способность и стабильность канала у "родного" Интернет-соединения (Интернет-соединение по умолчанию на ваше рабочем месте); б) - пропускная способность и стабильность прокси, если они используются, время отклика этих прокси при доступе с вашего рабочего места; в) - время отклика серверов Instagram для прокси, если они используются; г) - наличие ограничительных мер со стороны поставщика услуг прокси на объём выполняемых действий с этого прокси.

III). На объём выполненных целевых действий от имени всей синхронизируемой группы влияет работа в режиме контролируемых потоков, если этот режим был активирован в настройках задачи. Основной "тормозящий" фактор при этом - способ выполнения запросов. Большая часть запросов в этом режиме выполняются в отдельных подпотоках. При таком подходе перед выполнением целевого GET- или POST- запроса необходимо выполнить, так называемое, SSL-рукопожатие (CONNECT-запрос), т.к. "общаться" с Instagram можно только по протоколу HTTPS. Это создаёт практически для всех ключевых запросов дополнительный расход времени в размере от 200 до 400 мс. Таким образом, если тайм-ауты слишком малы, то, например, подписка и расстановка лайков могут не вписаться в отведенный для них тайм-аут и выйдут за его пределы в ущерб объёмам. Второй момент - это повтор "зависших" запросов. Такой режим работы обычно активируют в качестве экстренной меры, если задачи "зависают" из-за некорректно работающей логики автосмены оконцовочных IP на стороне провайдера мобильных прокси (см. статью по ссылке). Однако, при этом также следует учитывать то время, что программа тратит на поиск и устранение проблемы через аварийное завершение "зависшего" запроса и на его повторное выполнение.

ВОПРОСЫ

- Если я планирую работать только в режиме IP-синхронизации, то какие прокси лучше всего использовать? Стоит ли тратиться на дорогие прокси или подойдут обычные IPv6 / IPv4 ?

Требования к прокси при работе в режиме IP-синхронизации такие же, как и для привычного одновременного режима работы. Чем менее заспамлен IP-адрес и его подсеть, тем лучше. В идеале использовать сквозное 3g/4g Интернет-соединение мобильного оператора или приватные мобильные прокси от проверенных поставщиков.

- Синхронизация идёт только в пределах IP? Что будет если запустить разные задачи в пределах одной IP-группы?

На данный момент синхронизация осуществляется только в пределах IP. Мы считаем, что такой подход наиболее верен и вот почему. Это позволяет вносить ещё больше разнообразия в выполняемые действия, т.к. можно настроить для каждого синхронизируемого аккаунта выполнение различных задач, в том числе и с использованием циклов. Фактически мы создали уникальный конструктор, который позволяет свести к нулю какую-либо системность в пределах каждой IP-группы (IP-адреса), победить спам-блокировки и работать на больших объёмах.

- Почему у меня не получается на мобильных прокси получить такие же объёмы как у вас в кейсах?

Мобильные прокси у каждого поставщика услуг работают уникальным образом. Обычные прокси (IPv4 / IPv6) настраиваются очень похожим образом, если это все делается на *nix-платформе. С мобильными же прокси ситуация гораздо сложнее, т.к. задействовано больше программно-аппаратных инструментов. Соответственно, пропускная способность мобильных прокси, организация процесса смены оконцовочных IP у каждого мобильного прокси-провайдера будет своей и может сильно отличаться даже в пределах разных прокси одного и того же тарифного плана. Если по логам вы замечаете, что прокси чаще уходят в ошибку, чем это должно быть согласно выбранному тарифному плану или недоступны более заявленного времени (на смену оконцовочного IP должно уходить не более 10-15 секунд раз в 2 минуты), то следует обратиться с претензией к поставщику услуг мобильных прокси и/или сменить их на другие.

ДРУГИЕ СТАТЬИ ПО ТЕМЕ

Спам-блокировки - методы противостояния и борьбы

Сервис поддержки клиентов работает на платформе UserEcho