Распараллелить работу части скрипта?

В момент раздачи порций воркерам для отправки в API, данные хранятся в памяти большим массивом. И записываются в базу только когда слетают в API по частям, вернутся обратно, обработаются ещё раз. Зачем их в процессе снова писать в базу? (к тому же, данные не простые key-value, а массивы с несколькими уровнями вложенности).

Распараллелить работу части скрипта?

Посмотрел examples/parallel-download.php. Выглядит очень круто. Это магия прямо в моём старом-добром PHP.

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

Распараллелить работу части скрипта?

Почему не таким?

Я писал, что именно таким.

Правильно понимаю, что мне нужно будет запустить на reactphp простенький сервер, который будет ждать команд от моего приложения, а по ним запускать параллельное их выполнение? Если так, то это похоже на гораздо менее универсальную реализацию gearman. Возможно на её запуск потребуется меньше времени. Но я больше склоняюсь к Gearman.

Распараллелить работу части скрипта?

Мне предстоит форкаться в конроллере приложения, где есть открытые коннекты к БД, куча загруженных ресурсов. Коннекты придётся закрыть. Затем там же if (если я дочерний) {} else {}. При этом, в воркерах мне все эти ресурсы и коннекты не понадобятся. Но после их отработки понадобятся вновь.

Это вместо того, что бы просто $gearmanClient->doBackground('task1', 'task1_1');, а дальше только крутиться в while, дожидаясь когда все задачи будут выполнены, собрать результаты из memcache и работать с ними не теряя окружения.

А ещё, для сервера очередей, думаю, всегда найдётся больше задач, чем для для pcntl в PHP.

Распараллелить работу части скрипта?

Интересный фреймворк. Выглядит как какой-то NodeJS на PHP. Спасибо за указание.
Но у меня лишь одно место в проекте нужно распараллелить (может и несколько, но точно таким же образом).

Распараллелить работу части скрипта?

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

В любом случае, спасибо за ответ.

Распараллелить работу части скрипта?

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

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

Распараллелить работу части скрипта?

Более-менее понял, как работать с pcntl. Спасибо.

Однако звучит грязновато. Будь-то собираюсь писать свою реализацию xml-парсера. Думаю, если использую в этом проекте Gearman, получу более реюзабельные и высокоуровневые знания.

Распараллелить работу части скрипта?

В общем я бы вам посоветовался поближе разобраться с gearman

Да, мне и самому бы хотелось.

Сейчас я представляю себе это так: запускаю основной процесс, тот готовит данные, разбивает на партии, запускает n фоновых тасков и впадает в while (хотя бы один таск ещё выполняется) { sleep (1); }, затем собирает данные и работает дальше. Данные воркерам можно отдавать через memcache и через него же принимать результаты.

Звучит работоспособно, спасибо.

Какой путь выбрать для оптимизации ооочень большой страницы с кучей инпутов?

Спасибо. Решение о внедрении пагинации и фильтрации по другим параметрам вместо одной большой страницы уже начинает приживаться в моей голове.

Какой путь выбрать для оптимизации ооочень большой страницы с кучей инпутов?

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

Тоже думаю в эту сторону. Спасибо. Сделаю так даже если в итоге внедрю пагинацию.

Какой путь выбрать для оптимизации ооочень большой страницы с кучей инпутов?

У нас немного другая тема. Мы управляем ставками в Яндекс.Директ. Серверная часть много общается с их API, а клиентская позволяет редактировать ставки и другие параметры быстрее веб-интерфейса Яндекса.
Потому 1С, SAP, с учётом уже сделанного, не подойдут.
А за указание на работу Excel с внешними данными спасибо. Полезные знания для кругозора.

Какой путь выбрать для оптимизации ооочень большой страницы с кучей инпутов?

1. Конечно. jQuery Templates упоминал в роли синонима js-шаблонизаторов.
2. Рендерить кусками не понял зачем, если цель отрендерить страницу полностью любой ценой, то сразу всю будет быстрее ведь? Поиск не самое ценное, что потеряется, если показывать не сразу всё. Массовые операции гораздо важнее. Я бы даже сказал, что они критичны.

Понятно, что летать такое количество контролов всё равно не будет. Smarty делает fetch() почти 8 секунд, html весит > 80МБ и грузится в браузер полторы минуты (в gzip конечно меньше), после загрузки ещё секунд 20 работает js. И всё это жутко тормозит. Основной вопрос состоит в том, как это оптимизировать по максимуму. И довольно важно понять, стоит ли переходить на js-шаблоны.

Какой путь выбрать для оптимизации ооочень большой страницы с кучей инпутов?

Грубо говоря, есть сущность, её представление — строка. В строке несколько дивов/спанов с текстом, пять инпутов, один селект, ещё свёрнутый див с доп. информацией — опять спаны. Это управление ценами.
Поиск используется только через ctrl+f, что бы быстро перейти к сущности с каким-то словом, или конкретным id, и ввести для неё какие-то особые значения. Выбирать из сущностей ничего не нужно, только переходить к ним на этой странице. А основное количество операций массовое. Редко на всё страницу, часто на группы сущностей по 2-40 штук. Строки изначально сгруппированы по группам. И способ объединения в группы только один, потому фильтры не актуальны.
Всё одновременно видеть нужно потому, что во-первых, очень важна общая картина, во-вторых, здесь же рядом с ценами выводится некоторое количество аналитики.
В общем любая попытка показывать не сразу всё приведёт к тому, что пользоваться этим станет сразу не удобно. У системы всего два пользователя, но весь интерфейс создавался именно в работе с ними и сейчас там всё так, как им удобно. Варианты с пагинацией и фильтрацией сразу же отметались.

Какую CMS посоветуете для хомяка (блог+портфолио+пара свистелок)?

Ну, т.е. кэширование не используется или используется плохо.

ICQ-клиент, не страдающий ожирением и рекламой

А я использую самый новый (или почти самый) QIP — 2012 build 7210. Отключил доп. сервисы, вернул иконки от версии 2005, покопался в настройках и эта штука работает прекрасно, стабильно. Легко становится портабельной, если перенести в неё папку с профилем. Есть проверка орфографии, метаконтакты (объединённые контакты из разных протоколов), выделение особенных контактов разными цветами, глобальные хоткеи. Подключил учётки qip.ru, icq, gtalk и счастлив как слон.

Принцип построения моделей БД для PHP?

Спасибо за лог.

Нужна ли на Хабре статья с примером использования Twitter Bootstrap?

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

PhpStorm 2.0 + XDebug

Такая же проблема.