Как оптимизировать эту функцию экспорта для веб-приложения LAMP? - PullRequest
1 голос
/ 05 января 2009

У меня есть функция, которая позволяет пользователю создавать проекты и просматривать его на этой странице. Они могут импортировать ресурсы (pdf, img и т. Д.), Чтобы сохранить их в своих проектах. Итак, теперь я хочу создать функцию, которая позволит пользователю экспортировать все свои вещи и тех людей, которые находятся в одной группе с ними аккуратно, с красивой лентой, привязанной в zip-файле.

В настоящее время я использую Archive: Zip для архивации файла с преимуществом, сохраняю контрольную сумму CRC32 и выполняю ее как ежедневный cronjob, чтобы сократить время ожидания пользователя. Но если есть какие-либо изменения в каком-либо из файлов, мне придется перезапустить все это.

Мой начальный тест показывает, что для запуска 103 МБ файла потребуется до 47 секунд. Процесс включает в себя создание XML, связывающего их с XSL, копирование изображений, HTML для iframes, а что нет.

Я думаю о создании таблицы или текстового файла, чтобы сохранить контрольную сумму CRC32 или дату последнего изменения для всех файлов во временной области хранения и сравнивать с этим списком каждый раз, когда пользователь нажимает на экспорт, и если есть какие-либо новые файлы, я удалю тот же файл из кэшированного zip-файла и добавлю новый файл. Или я просто сохраню все свободные файлы и скопирую и замению новые файлы, а затем буду делать архив при каждом клике.

Мои вопросы:

  1. Считается ли это преждевременным или плохая техника оптимизации?
  2. Как мне правильно оптимизировать это?
  3. Есть ли какая-нибудь книга или ресурсы, которые Я могу учиться для такого рода методы оптимизации?

1 Ответ

1 голос
/ 05 января 2009

Что не так с идеей:

  • установка какого-либо флага при изменении файлов пользователя (добавление, удаление или изменение файла).
  • запуск вашего ночного сжатия для каждого пользователя, чьи файлы были изменены, а затем сброс этого флага.
  • если пользователь запрашивает экспорт при установленном флаге, вам придется выполнить сжатие еще раз, прежде чем экспорт завершится (этого не избежать).

Чтобы еще больше ускорить работу пользователя, вы также можете отделить запрос на экспорт от операции экспорта. Например, когда пользователь (чей флаг установлен) запрашивает экспорт, уведомляет его о том, что это будет сделано, когда происходит сжатие, и устанавливает другой флаг. Затем измените второй шаг, описанный выше, чтобы также экспортировать вновь созданный пакет, если установлен этот второй флаг.

Это дает пользователю немедленную обратную связь о том, что что-то случится, но переносит тяжелую работу в будущее.

Кроме того, вам не нужно привязывать экспорт к компрессу. Вы можете сжимать каждую ночь, но при необходимости разрешать дополнительные задания сжатия / экспорта в течение дня. Однако все еще хорошо отделить запрос от события.

Отвечая на ваши конкретные вопросы.

1 / Я не считаю это преждевременной или плохой оптимизацией. «Код» функционально завершен, так как он выполняет все, о чем вы просите, поэтому настало время для оптимизации. Кроме того, вы определили узкое место и оптимизируете нужную область.

2 / См. Мой текст выше. Вы должны оптимизировать его, делая именно то, что вы сделали - выявить узкое место и сосредоточиться на его улучшении. Учитывая, что вы вряд ли получите намного лучшую производительность сжатия, предложенный мною «трюк» развязки хорош. Как и индикаторы выполнения и заставки, обычно это больше связано с восприятием скорости пользователями, а не самой скоростью.

3 / Книги? Не беспокойтесь, в сети тысячи ресурсов. Продолжайте спрашивать ТАК и распечатайте все ответы. В конце концов, ваш мозг будет полон моего, и каждый новый фрагмент кода заставит вас временно забыть имя вашей жены: -).

...