Я пытаюсь написать файл .tgz, содержащий десятки, если не сотни тысяч файлов, содержимое каждого из которых было получено из строка в базе данных. Каждая запись файла составляет около 2-5 тыс. Данных.Написание файла .tgz с использованием PHP с 100 000 + записей, но избегая отдельных записей файла
Я хочу избежать этого, не сначала записывая файлы. В настоящее время у меня есть PHP, создающий традиционную структуру каталогов, запись файлов, а затем создание tgz с самого конца с использованием shellexec.
Диск, который мы используем, медленный, поэтому запись десятков тысяч файлов занимает много времени. Даже запустив прототип на другой машине с быстрым диском с использованием ramdisk tmpfs и большого количества процессора, я получаю скорость около 100-200 записей в секунду в секунду, которая кажется медленной - полчаса для 150 000 файлов в структуре каталогов. После того, как это было написано, фактическое преобразование из исходной структуры каталога ОС в tgz не является проблематичным.
Я надеялся использовать PharData для написания. Тем не менее, PharData :: addFromString, похоже, записывает файл сразу после добавления файла, а не в шаблон Open-> Add-> Writeout.
Можно ли предложить какие-либо стратегии здесь?
Окончательный файл tgz затем будет доступен для скачивания и не будет обновляться часто. Но поскольку есть ряд этих файлов, которые нужно создать, нужно ждать 30-60 + минут, чтобы просто упаковать, это становится довольно блокирующим.
Можете ли вы дать какой-то контекст о том, какое улучшение производительности вам нужно, и для чего этот файл? Как часто требуется обновленный файл? Например, если это файл, доступный для загрузки на веб-сайте, он нуждается в обновлении более чем каждые полчаса? (Я согласен, что 200 записей/сек звучат медленно, но я считаю, что сжатие является процессом с интенсивным использованием процессора). – halfer
Если вы не беспокоитесь об увеличении размера выходного файла, попробуйте отключить уровень сжатия. У команды 'gzip' действительно есть опция' --fast', попробуйте? – halfer
Было бы интересно сравнить рабочую нагрузку, когда вы отключите сжатие, чтобы определить, где проблемы с производительностью. Я подозреваю, что ваша самая большая победа будет заключаться в использовании другой структуры для хранения данных - следовательно, каковы возможности ее изменения? – symcbean