Спамилка

[Hector]

Комуто интересно нечто подобное апостеру, без прокси забивает 100мбит канала влегкую, и проц с оперативкой сильно не жрутся. Проц на процентов 30%, оперативу не помню... но не много. При этом скорость 8к ресурсов в минуту. И сервер еще может работать нормально. Жаль нет возможности потестить на боле широком канале.

С прокси забивает 30мбит при 1000 потоках. 70мбит добивался тоже но жрет много оперативы (1500 потоков = 1.5 гига оперативы), НО проц всего 12-15%. Скорость 3к ресурсов в минуту на 1000 потоках, оперативы сжирает гиг примерно. На 1500 потоках умножайте.....но 2 гига оперативы мало уже.... уходит в своп. Скорость 5к/минута примерно на 1500 потоках.

Тестили на DualCore Xeon 2.33Ghz, 2GB RAM, Linux

Написана на пхп.

Ща сделали что работает на мозгах апостера и пробивает по актив базе.

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

По мере совершенствования буду отписывать ))


APOSTER:
40*40 потоков
30мбит забитого канала
спам через прокси с проверкой поста
60-70% CPU Load
920мб использованной оперативы

Моя Спамилка:
1000 потоков
30мбит забитого канала
спам через прокси с проверкой поста
10-15% CPU Load
1300мб использованной оперативы

[JMen]

Гектор, чтобы скрипт не жрал память - перед циклом форкания освобождай всё что можешь (потом наберёшь) + данные для нити получай внутри нити. Т.е. не въезжай в новый поток с общими данными.

[gcc]

гектор сам писал?

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

[Hector]

Сообщение от JMen

Гектор, чтобы скрипт не жрал память - перед циклом форкания освобождай всё что можешь (потом наберёшь) + данные для нити получай внутри нити. Т.е. не въезжай в новый поток с общими данными.

Это не я писал, но я передам. Спасибо. Может поможет, тогда будет ваще бомба )

gcc я руковожу ) и плачУ
А так да - пол года назад начал. У меня есть более простые спамилки например спам вордпресс блогов. Этой спамилкой небыло времени заниматься... проще хорошему прогеру платить

[XeonN]

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

[solar]

Сообщение от Hector

forks + curl

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

нужна эффективность = юзайте асинхронные сокеты, даже треды тормозят.

[Hector]

Сообщение от XeonN

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

мультикурл это вообще херня, на сокетах делать не хочецца
у меня такое предчувствие что на сокетах мы упремся в загрузку проца (аля апостер)

solar форки - это пока что лучшее решение что я для себя нашел, у меня масса скриптов на них работает, всё очень стабильно и предсказуемо )

[solar]

сокеты не грузят проц, они шлют данные по сети.

проц грузит переключение контекста между процессами(тредами), плохая логика программы, кривые регулярные выражения, кривой select(), кривые запросы к БД и т.д.

это ж прописные истины

[Hector]

окей, пробанем сокетами, авось будет лучше

[elkipalki]

Hector, а чем собственно чем мulticurl херня ?

[dveredel]

Я не Гектор, но отвечу от себя.

Я писал мультипоточный движок и на курле и на сокетах.

Минусы мультикурла:
- глючность и вылеты библиотеки при определенных условиях.
- глючные таймауты с коннектом через прокси (игнорирует устанавливаемое значение и использует внутреннее на 30+ секунд, особенно проблема всплывает с соксами)
- БЛОКИРУЕМЫЙ коннект (на 100% не уверен, но по наблюдениям и тестам так и есть)
- постоянные утечки памяти.
- невозможность принудительно закрыть соединение в процессе загрузки страницы (даже если вешать read handler, то из него курл не позволяет закрыть коннект)

Плюсы курла:
- готовая либа с полной реализацией ХТТП и ХТТПС
- относительная простота использования и логики написания
- внутренняя логика написана на си, соотв. скорость.
- встроенная поддержка всех типов прокси
-----------------------

Под сокетами мы понимаем чистые пхпшные обертки на сишными функциями, т.е. никаких fsockopen и стримов, поскольку в пхп НЕБЛОКИРУЮЩИЙ (асинхронный) коннект можно реализовать только на чистых сокетах.

Минусы сокетов:
- очень сложно-программируемая логика, требующая внимательности и полного понимания процесса.
- всю логику отсылки запросов и парсинг ответа приходится реализовывать самому (т.е. весь HTTP).
- если требуется HTTPS (на чистых сокетах, без стримов), то это практически анрил, из за отсутствии документации и нереального гемора при написании самому с нуля.
- при работе через соксы требуется знание протокола и отличие сокс4 от сокс5

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

-------

Ну а, как писалось выше, форки и\или запуск копий скрипта - это верный пусть к полной загрузке сервака.