Оптимизация: используйте локальные файлы или базы данных для HTML

Question

Это следует из этого вопроса , где я получал несколько ответов, предполагая, что я использовал файлы для хранения своих шаблонов HTML.

До недавнего времени я всегда сохранял «скомпилированные» шаблоны в виде html-файлов в каталоге (над корнем). Мои шаблоны обычно имеют два типа переменных - «статические» переменные, которые не заменяются при каждом использовании, но используются по всему сайту - в основном для простоты обслуживания, если я решу, например, изменить имя сайта; и динамические переменные, которые меняются при каждой загрузке страницы.

Я всегда сохранял их в виде файлов на сервере - но мой друг указал на то, что я упустил из виду: зачем делать 5-10 вызовов файловой системы, когда вы можете иметь один вызов базы данных?

Что я хочу знать, что является более эффективным? Вызов нескольких файлов HTML из системы или вызов нескольких строк шаблонов из базы данных (в одном запросе / вызове).

Answer 1

Не хранить редактируемый HTML в базе данных

Серьезно, потому что затраты на обслуживание простых изменений становятся исчерпывающими, как только вы понимаете, что больше не можете просто открывать текстовый редактор.

Я работал над многими проектами, в которых содержался HTML-контент в базе данных, и это был постоянный кошмар "найти ту строку, в которой находится контент", и мне бы очень хотелось, чтобы выстрелил человек, который сделал Это.

Кроме того, НЕ ПРЕДВАРИТЕЛЬНО ОПТИМИЗИРУЕТ . Если вы обнаружили проблему, которая замедляет проект, то измените ее. Потому что делает код менее понятным, чтобы сэкономить миллисекунду. Но спроектируйте код достаточно хорошо, и если вам потребуется изменить источник контента, это будет легко сделать.

Конечно, это можно решить, если подходящий веб-интерфейс для редактирования шаблоны?

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

On FileIO

Несмотря на то, что File IO может быть узким местом, имейте в виду, что при правильной установке linux и большом количестве памяти действует удобная вещь, известная как «дисковый кэш», которая фактически, файлы сохраняются в памяти, поэтому файловый ввод-вывод становится просто memcpy.

Напротив, в реальных стресс-тестах для любого кода, который я использовал, самые большие замедления были в базе данных, в первую очередь - это хорошая медленная строка CONNECT, время анализа запроса, дополнительные взаимодействия php <-> mysql. Вы на самом деле не хотите ничего получить. Поиск в файловой системе близок к поиску по индексу базы данных, и у вас нет никаких неизвестных, кроме «вам нужно потоковое воспроизведение с диска», нет необходимости блокировать таблицы!

Возможно, вам стоит попробовать что-то вроде библиотеки кеширования, очень рекомендуется X-Cache, который, скорее всего, даст вам ощутимый прирост производительности.

Answer 2

Я в значительной степени согласен с сутью ответа Кента Фредрика. Но, если вы действительно хотите знать, что является более эффективным / быстрым, вы не можете ожидать, что получите ответ здесь. Если вы хотите получить этот ответ, есть только один способ получить его: профилировать приложение в обоих направлениях.