На каком языке лучше реализовать многопоточность в ~600 потоков?

[jeff.alex]

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

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

------
ПС: что делает один "поток" - подключается к АПИ по нужной ссылке, получает инфо и заносит в базу. Каждый "поток" обрабатывает свои N штук АПИ-ссылок.

 

[grigori]

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

потоки бывают разные
https://ru.wikipedia.org/wiki/Поток_данных
https://ru.wikipedia.org/wiki/Поток_выполнения
https://ru.wikipedia.org/wiki/Стандартные_потоки
https://ru.wikipedia.org/wiki/Процесс_(информатика)

 

[jeff.alex]

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

потоки бывают разные
https://ru.wikipedia.org/wiki/Поток_данных
https://ru.wikipedia.org/wiki/Поток_выполнения
https://ru.wikipedia.org/wiki/Стандартные_потоки
https://ru.wikipedia.org/wiki/Процесс_(информатика)

"потоки" тут скорее в кавычках. Подредактирвал пост сверху, чтобы было понятнее, что делает один "поток".

 

[grigori]

на php отлично реализуется - неблокирующий режим называется
curl_multi, reactphp, etc

 

[grigori]

интересно, через какой период времени админ ресурса-API забанит такого клиента с 600 вызовами в секунду?

 

[jeff.alex]

на php отлично реализуется - неблокирующий режим называется
curl_multi, reactphp, etc

на моей памяти работал с ним, и постоянно были какие-то глюки с ним... правда давненько это было, лет 8 назад..
А если тут будет 600 потоков, плюс прокси...ухх боюсь все к чертям полетит...


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

 

[jeff.alex]

интересно, через какой период времени админ ресурса-API забанит такого клиента с 600 вызовами в секунду?

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

Если вернуться к реализации через крон, можете чтото сказать, на сколько это вообще нормально будет, если занести в крон 600 задач? С запуском каждую минуту (+ конечно же проверка в скрипте - закончил ли работу "поток", чтобы не получилось наслаивания)

 

[AnrDaemon]

надеюсь обойдется.

То есть вы осознаёте, что нарушаете ToS?
Тогда нам с вами не по пути.

 

[С.]

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

Если вернуться к реализации через крон, можете чтото сказать, на сколько это вообще нормально будет, если занести в крон 600 задач? С запуском каждую минуту (+ конечно же проверка в скрипте - закончил ли работу "поток", чтобы не получилось наслаивания)

Изначально архитектурный подход тупиковый. Если ты не Гугл, то не могу себе представить задачу, чтобы понадобилось бы 600 конкурентных потоков. Наверняка замах можно поумерить и поставить в очередь.

 

[grigori]

ключевое слово было "неблокирующий", которое исключает крон

но плохой танцор идет искать другие ресурсы для обсуждения плохого php