Вот и ставьте 4 константой, как вам тут уже неоднократно умные люди советовали, зачем макаронного монстра изобретать?
Есть еще и 2-ядерные процы. Предлагаете там тоже хардкодить?
Если будет стоять ограничение в 4 таска, на процессоре с 2 ядрами ни один таск не будет выполняться с максимально возможной скоростью. С этой точки зрения нет никакой разницы, ставить ограничение в 2 или в 4, общий экспорт завершится примерно одинаково. Но если впридачу к малому количеству ядер они еще и слабые, 4 высоконагруженных треда, если запустятся вместе, не дадут даже браузер в фоне открыть, а то и систему подвесят.
я предлагаю ограничиваться средним значением кокосов
Вы предлагаете захардкодить в скрипте значение 4. Это среднее значение для 4-ядерного проца, но не для 2-ядерного или 6-ядерного. Вариант с количеством ядер гибче.
Так откуда уверенность что ишаку именно длинны хвоста недостает? Логичнее предположить, что индизайну банально не хватает каких то внутренних обьектных буферов, необходимых для одновременного экспорта
Так, похоже, возникло недопонимание.
С самого начала:
Первое.
Если количество тасков равно количеству ядер проца, они собирают данные и стартуют почти одновременно без малейших неудобств, при этом производительность такого процесса если не максимальна, то приближена к максимальной. Я не вижу смысла задействовать еще и логические ядра в этом деле, поскольку FPU всего один на физическое ядро, скорость обработки графики будет ограничена производительностью FPU для этого таска. Да и встроенный ограничитель индизайна не даст запустить больше тасков, чем в системе есть ядер.
Второе.
Чем больше queued тасков стоит в очереди за выполняющимися, тем больше и больше ресурсов queued таски жрут на какие-то свои внутренние процедуры, отнимая время у тех тасков, которые должны выполняться, что в конечном итоге приводит к зависанию индизайна. В момент, когда индизайн зависает с кучей тасков, процессор обычно кипит, загрузка всех логических ядер 100% под гипертредингом, а диспетчер задач запускается с трудом. Речь идет об исчерпании ресурсов системы. Никогда не было такого, чтобы индизайн крутился на 2 ядрах из 4 и зависал.
Этой проблемы можно избежать, не допуская в очередь лишние таски раньше времени.
Решение, сколько все-таки тасков допускать в очередь, выясняется экспериментально, но стартовая точка - количество ядер. Причина все та же, повторюсь: если количество тасков равно количеству ядер проца, они собирают данные и стартуют почти одновременно без малейших неудобств. Я не вижу предпосылок, почему 8 тасков на 8-ядерном процессоре должны подвешивать индизайн.
indesign server по уму надо ставить, если такие серьезные объемы, что 40 секунд имеют значение.
сколько помню - вечно с этим фоновым экспортом проблемы. прервется например где-то посередине, и даже номер страницы, где произошла ошибка не понять.
Server нужно еще купить.
Не сказать, что объемы серьезные, но вот приходит мне пакет - два каталога и три брошюры, я с ними поработал и хочу правильно сохранить творение рук своих. Заказчик хочет PDF в высоком качестве, низком качестве, развороты и idml.
Казалось бы - простая задача, но 2 каталога и 3 брошюры в 4 форматах - это 20 тасков.
А вообще говоря, например, на си такая оптимизация на уровне компилятора вполне возможна и активно применяется.
