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

:-)

Я уже где-то читал и понял о нулях, но ничего не выходило. Спасибо за напоминание. И вот как я сделал в итоге: поставил нули в трех параметрах совершенно без надежды, отключил xdebug (сам по себе уже был отключен, но я вырубил модуль полностью), включил memcached на 1 гиг для общего кеша сайта и просто для понта, удалил вручную кеш modx, ребутнул Apache2, ребутнул memcached — запустил… Ускорение где-то в пределах от 1,5 до 6 раз. (диапазон ранее был 1-3,5 секунды для тяжелой морды и для залогиненного юзера теперь снизился до 0.68-0,8 при нулевом изменении кода сайта при равных условиях нагрузки). А для анонимусов там вообще другая заварка. ?

В базовой версии это компенсировалось тем, что весь импорт выполнялся в рамках одного процессора, а в нем действия могут выполняться только последовательно. А веб-форма просто проверяла регистр на наличие новых сообщений. Таким образом логика работы процессора не могла нарушиться асинхронными запросами. А вы условие в топике читали: при чем так, чтобы уложиться в 30 секунд и 64 Mb памяти Уверены, что 30 секунд нам будет достаточно, чтобы прогрузить 13 000 товаров? Эту проблему данный компонент и решает — он в цикле шлет кучу запросов, на каждый из которых может уходить до 30-ти секунд. Таким образом импортер хоть сутки может крутиться и прогрузить хоть миллион товаров. Вы выполняете импорт в процессоре, а во время импорта процессор не может ответить на запрос формы, так как он уже начал свою работу и нужен какой-то промежуточный обмен данными между работающим процессором и формой. Вы в целом не уловили смысла этого решения. Смысл в том, что вся процедура разбивается на кучу шагов. То есть запрос отрабатывает запрос, возвращает ответ, консоль кушает ответ и опять шлет запрос, и т.д. и т.п., пока процессор не вернет «COMPLITED».

Асинхронные запросы без ожидания ответа — это и есть большая проблема. Здесь важно, чтобы каждый запрос обрабатывался последовательно, так как, к примеру, нельзя перейти к шагу импорта записей во временную таблицу, пока эта таблица не очищена. В базовой версии это компенсировалось тем, что весь импорт выполнялся в рамках одного процессора, а в нем действия могут выполняться только последовательно. А веб-форма просто проверяла регистр на наличие новых сообщений. Таким образом логика работы процессора не могла нарушиться асинхронными запросами. Все просто: идет запрос на сервер, и с сервера информация поступает в ответе через стандартное return $this->success($msg, $object); Мне непонятен следующий момент. Вы выполняете импорт в процессоре, а во время импорта процессор не может ответить на запрос формы, так как он уже начал свою работу и нужен какой-то промежуточный обмен данными между работающим процессором и формой. Он должен сохранять сообщения о ходе операции, чтобы форма запросом к промежуточному скрипту могла отобразить все сообщения работающего процессора. Так работает стандартная консоль + процессор. Сам процессор кладет сообщения в регистр и форма их потом забирает. Как вы смогли избавиться от промежуточного стека сообщений?

То есть реальных проблем со стандартной консолью не было, просто свое решение задачи? Асинхронные запросы без ожидания ответа — это и есть большая проблема. Здесь важно, чтобы каждый запрос обрабатывался последовательно, так как, к примеру, нельзя перейти к шагу импорта записей во временную таблицу, пока эта таблица не очищена. А вы как обошлись без передачи логов через файлы между работающим скриптом импорта и Javascript-формой? Все просто: идет запрос на сервер, и с сервера информация поступает в ответе через стандартное return $this->success($msg, $object);

То есть реальных проблем со стандартной консолью не было, просто свое решение задачи? (возможность переключить провайдер в синхронный режим я не нашел. Если вы знаете как, поделитесь, полезно будет). Нет, я ничего подобного в коде не видел, когда мне нужен был этот компонент. Чтобы все это дело заставить дожидаться ответа действительно придется переписывать консоль. А вы как обошлись без передачи логов через файлы между работающим скриптом импорта и Javascript-формой?

Добрый день. А чем именно не понравился стандартный компонент MODx.Console? 1. Тем, что он запросы шлет асинхроннонные, и не дожидаясь ответа, шлет новый запрос. (возможность переключить провайдер в синхронный режим я не нашел. Если вы знаете как, поделитесь, полезно будет). 2. Слишком хитрая система записи логов в файлы и чтения ответов из них. По-моему избыточная сложность. Я ранее уже делал импортер с использованием стандартной консоли MODX-а ( www.youtube.com/watch?feature=player_detailpage&v=fpkfFbInV88#t=44s ), и хочу сказать, что второй вариант мне показался более простым и гибким.

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

Добрый день, Николай. А чем именно не понравился стандартный компонент MODx.Console? Я делал на нем импорт 300 000 позиций и нареканий с ним не было. Конечно там может перекосить регистры, на которых он, собственно, и работает, но в целом компонент мне показался довольно стабильным.