- Регистрация
- 22.05.2010
- Сообщения
- 1 327
- Благодарностей
- 663
- Баллы
- 113
Оптимизация шаблонов - процесс призванный повышать эффективность шаблона путём устранения узких мест. В данном материале описываются базовые аспекты оптимизации и её уровни, цель которую я преследую - дать базовое понимание тем у кого отсутствуют соответствующие навыки - в основном это начинающие пользователи ZP.
Фронт работ визуально можно представить следующим наглядным изображением:
Направление фронта работ - начинаем внутри, по мере работ переходим во внешние блоки. Если внутренний блок не оптимизирован - то оптимизация внешних блоков крайне мало поможет делу, и будет серьёзно ограничена.
Блок шаблона
Архитектура
Разрабатывается исходя из следующих принципов
Настройка шаблона
Шаг шаблона
Очень обширная сфера оптимизации. Ориентиром здесь является время затрачиваемое на выполнение шага, если оно велико - можно задуматься над тем как работу шага вынести. Идеал - шаг надо выкинуть упростив работу так, чтобы в нём необходимости не было вообще.
На текущий момент оптимизации происходят такого рода:
В основном это требует определённого опыта внедрения, на этом уровне часто решается достаточно серьёзный блок задач.
Управление ZP
Потоки
Не всегда линейно влияют на производительность шаблона, здесь необходимо методом экспериментов находить рабочее значение. Оптимальное рабочее значение находится путём оптимизации шаблона на выдержку определённого времени выполнения, технически это выглядит как зацикливание действий на определённое число выполнений (это делается для исключения случаев когда потоки тупо не удаётся забить работой так как быстро слишком отрабатывают), и дальнейшим тестированием того при каком количестве потоков какую производительность выдаёт шаблон. Актуально для мощного железа. На малом таких эффектов проблем как правило не приходится ожидать.
Прокси
На паблике работать можно, но в таком случае придётся основательно оптимизировать шаблон под такой вариант, что ошибки будут везде, и всегда, и брать количеством попыток, чем больше действий с WEB частью, тем больше надо покрывать такой логикой работу. Лучшие прокси серверные. Стоит понимать что в зависимости от GEO расположения прокси сайт может менять элементы на своей страницы, и это большой источник проблем для многих, решения таких проблем в логгирование того что на сайте, и адаптированием шаблона под новые реалии, ещё можно использовать универсальные признаки поиска форм.
Групповая работа шаблонов
Шаблоны могут работать группой, и если между ними работа разделена по правилам описанным выше, то эффект от групповой работы возрастает основательно. Оптимизация группы состоит в том, чтобы оптимизировать шаблон под работу с другими шаблонами как описано выше было, если там всё правильно сделано, то такая работа будет быстрей давать конечный результат для шаблонов с большим количеством веб действий.
Железо
RAM
Потребляется инстансами как вода человеком, здесь стоит понимать что чем меньше ребутим инстанс - тем больше жрётся RAM, исходим исходя из этого
CPU
Чем чаще ребутится инстанс, тем больше потребляется CPU.
Балансируя между вышеописанными параметрами можно добиваться соответствующей нагрузки на нужный ресурс, если RAM мало то делаем упор на CPU (и теряем производительность шаблона так как инстансы своими перезапусками воруют время), если RAM много то забиваем только её, упор при покупке серверов стоит делать на RAM.
Канал
ZP его мягко говоря потребляет относительно слабо, исключение это большое количество GET/POST запросов. Как правило мне на достаточно мощных серверах 100 Мбит всегда хватало, и никогда я их не забивал достаточно сетевой нагрузкой.
На последок, главная оптимизация века - каждой задаче свой инструмент, если силами ZP парсить поисковики или писать спамилки то вся текущая информация в данной статье будет достаточно бестолковой, важно это понимать и исходить из этого.
Фронт работ визуально можно представить следующим наглядным изображением:
Направление фронта работ - начинаем внутри, по мере работ переходим во внешние блоки. Если внутренний блок не оптимизирован - то оптимизация внешних блоков крайне мало поможет делу, и будет серьёзно ограничена.
Блок шаблона
Архитектура
Разрабатывается исходя из следующих принципов
- Логика отдельно, исполнительная (многопоточная) часть отдельно (пример шаблона парсинга статей на сложном сайте: один шаблон в один поток составляет список ссылок разделов, второй многопоточно составляет список ссылок на статьи проходя по разделам, третий многопоточно парсит сами статьи по заранее спаршенному списку)
- Всё что делается два раза и более будь то блок действий или шаг - помещается в цикл, если понадобится третий раз что-то подобное выполнить то у нас добавляется к циклу итерация, а не размножается говнокод
- Блоки действий стремятся к тому, чтобы блок был ответственнен за конкретный участок работы, к примеру могут быть блоки: авторизация, постинг, голосование
- Всё подробно комментируется, блоки действий, шаги, неясности. Завтра может понадобится переделать шаблон, и эта мера упростит понимание что как устроено
- Стремимся при работе с WEB частью пропускать лишние этапы, примеры
- Авторизоваться можно не с тяжёлой главной, а со специальной формы входа которая легче
- Не обязательно гулять по сайту на пути к редатору добавления новости, а можно напрямую перейти по URL добавления новости
- Хитровыебанные защиты часто можно обходить переходом на WAP версию сайта (не забыв включить соответствующий мобильный User Agent)
Настройка шаблона
- Картинки, flash и прочее - часто можно не использовать, эмуляцию так же
- Картинки/flash/эмуляцию - можно включать к примеру только там, где необходимо, и тем самым повышать скорость загрузки страницы на остальных этапах работы
- Часто нет необходимости ожидать прогрузки всяких AJAX элементов, и можно так же воспользоваться данной настройках для оптимизации работы
Шаг шаблона
Очень обширная сфера оптимизации. Ориентиром здесь является время затрачиваемое на выполнение шага, если оно велико - можно задуматься над тем как работу шага вынести. Идеал - шаг надо выкинуть упростив работу так, чтобы в нём необходимости не было вообще.
На текущий момент оптимизации происходят такого рода:
- WEB часть управляемая браузером заменяется на скоростные GET/POST запросы
- Когда у нас много больших текстовых данных, то тяжёлые с точки зрения ZP шаги работы с таблицей/списками заменяются на использование баз типа SQLite, или работой с внешними PHP скриптами, откуда берётся задание, и закидывается результат (остальное в MySQL базе лежит)
- Когда нехватает скорости загрузки на FTP, шаблон формирует задание и отдаёт его сторонней самописной программе, которая заливает всё многопоточно
В основном это требует определённого опыта внедрения, на этом уровне часто решается достаточно серьёзный блок задач.
Управление ZP
Потоки
Не всегда линейно влияют на производительность шаблона, здесь необходимо методом экспериментов находить рабочее значение. Оптимальное рабочее значение находится путём оптимизации шаблона на выдержку определённого времени выполнения, технически это выглядит как зацикливание действий на определённое число выполнений (это делается для исключения случаев когда потоки тупо не удаётся забить работой так как быстро слишком отрабатывают), и дальнейшим тестированием того при каком количестве потоков какую производительность выдаёт шаблон. Актуально для мощного железа. На малом таких эффектов проблем как правило не приходится ожидать.
Прокси
На паблике работать можно, но в таком случае придётся основательно оптимизировать шаблон под такой вариант, что ошибки будут везде, и всегда, и брать количеством попыток, чем больше действий с WEB частью, тем больше надо покрывать такой логикой работу. Лучшие прокси серверные. Стоит понимать что в зависимости от GEO расположения прокси сайт может менять элементы на своей страницы, и это большой источник проблем для многих, решения таких проблем в логгирование того что на сайте, и адаптированием шаблона под новые реалии, ещё можно использовать универсальные признаки поиска форм.
Групповая работа шаблонов
Шаблоны могут работать группой, и если между ними работа разделена по правилам описанным выше, то эффект от групповой работы возрастает основательно. Оптимизация группы состоит в том, чтобы оптимизировать шаблон под работу с другими шаблонами как описано выше было, если там всё правильно сделано, то такая работа будет быстрей давать конечный результат для шаблонов с большим количеством веб действий.
Железо
RAM
Потребляется инстансами как вода человеком, здесь стоит понимать что чем меньше ребутим инстанс - тем больше жрётся RAM, исходим исходя из этого
CPU
Чем чаще ребутится инстанс, тем больше потребляется CPU.
Балансируя между вышеописанными параметрами можно добиваться соответствующей нагрузки на нужный ресурс, если RAM мало то делаем упор на CPU (и теряем производительность шаблона так как инстансы своими перезапусками воруют время), если RAM много то забиваем только её, упор при покупке серверов стоит делать на RAM.
Канал
ZP его мягко говоря потребляет относительно слабо, исключение это большое количество GET/POST запросов. Как правило мне на достаточно мощных серверах 100 Мбит всегда хватало, и никогда я их не забивал достаточно сетевой нагрузкой.
На последок, главная оптимизация века - каждой задаче свой инструмент, если силами ZP парсить поисковики или писать спамилки то вся текущая информация в данной статье будет достаточно бестолковой, важно это понимать и исходить из этого.
Для запуска проектов требуется программа ZennoPoster.
Это основное приложение, предназначенное для выполнения автоматизированных шаблонов действий (ботов).
Подробнее...
Для того чтобы запустить шаблон, откройте программу ZennoPoster. Нажмите кнопку «Добавить», и выберите файл проекта, который хотите запустить.
Подробнее о том, где и как выполняется проект.
