Комментарии 13
Я тоже пытался работать с gearman, испытал много мучений. Для реализации «очередей» в конце концов использую redis для небольших проектов и RabbitMQ для крупных.
НЛО прилетело и опубликовало эту надпись здесь
Я раньше был на php5.3 :)
присоединяюсь
P.S. И да, Gearman великолепен.
присоединяюсь
а с какими потоками задач вам приходилось сталкиваться?
работа в несколько потоков (от 4 до 1000) с:
— API Яндекса (перевод)
— API Google (AdWods, Analytics, перевод)
— парсинг ресурсов
кинул задачи в очередь — сиди кури, смотри как выполняются
— API Яндекса (перевод)
— API Google (AdWods, Analytics, перевод)
— парсинг ресурсов
кинул задачи в очередь — сиди кури, смотри как выполняются
под потоком я имел в виду количество сообщений/задач в секунду.
вопрос, мне кажется, в другой плоскости лежит
примеры
1) мы запускаем 1000 воркеров. Они все коннектятся к одной БД, начинает сыпать исключениями PDO — много соединений слишком с базой. Быстрее не будет, 5000 воркеров мы не запустим
2) мы кинули в очередь 10000 задач на получение и обработку данных с внешнего сервиса. Хорошо бы воркеров побольше, но внешний сервис дает нам 100 коннектов в секунду, не больше (это Гугл). Больше чем 50+ воркеров нам запускать нет смысла, быстрее не поедем
Ваш вопрос: ну будет поток например 1к одновременных попыток получения данных. Быстрее чем смогут обработать воркеры не будет, задачи будут становиться в очередь, пока память не закончится
примеры
1) мы запускаем 1000 воркеров. Они все коннектятся к одной БД, начинает сыпать исключениями PDO — много соединений слишком с базой. Быстрее не будет, 5000 воркеров мы не запустим
2) мы кинули в очередь 10000 задач на получение и обработку данных с внешнего сервиса. Хорошо бы воркеров побольше, но внешний сервис дает нам 100 коннектов в секунду, не больше (это Гугл). Больше чем 50+ воркеров нам запускать нет смысла, быстрее не поедем
Ваш вопрос: ну будет поток например 1к одновременных попыток получения данных. Быстрее чем смогут обработать воркеры не будет, задачи будут становиться в очередь, пока память не закончится
В Debian Jessie уже всё ставится нормально. Можно попробовать сделать backport.
В PHP 5.5 у меня работает:
$ php -r '$gm = new GearmanWorker(); $gm->addServer(); var_dump($gm);';
object(GearmanWorker)#1 (0) {
}
$ php -v
PHP 5.5.18 (cli) (built: Oct 16 2014 12:21:51)
Copyright © 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright © 1998-2014 Zend Technologies
with Zend OPcache v7.0.4-dev, Copyright © 1999-2014, by Zend Technologies
А я когда-то столкнулся с тем, что получал Segmentation fault после:
Решилось на stackoverflow. Мне нравится Gearman, но описанные вещи портят впечатление.
<?php
$client->addTask('taskname', 10);
$client->runTasks();
Решилось на stackoverflow. Мне нравится Gearman, но описанные вещи портят впечатление.
Около полутора лет использовали Gearman, и, с ростом нагрузки, столкнулись с тем, что он стал все чаще и чаще тупить и подвисать. Приходилось за ним следить, часто перезагружать.
С переездом на Rabbitmq эти проблемы исчезли. Выбор однозначен…
С переездом на Rabbitmq эти проблемы исчезли. Выбор однозначен…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Gearman и PHP 5.4 (5.6): проблемы и решения