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

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

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

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

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

Мои вопросы:

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

person melaos    schedule 05.01.2009    source источник


Ответы (1)


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

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

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

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

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

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

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

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

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

person paxdiablo    schedule 05.01.2009
comment
хе-хе, смешно и полезно +1, хорошо, я искал больше способов, как подойти к этому. Тем не менее, было бы весело и интересно научиться находить больше паттернов по подобным вопросам. Благодарность - person melaos; 07.01.2009