2010-12-16 4 views
1

Я использую Web-формы и Asp.Net с MS SQL.Как хранить Javascript как HTML-код на веб-сайте

Для моего веб-сайта мне нужно хранить эти коды Белове, возможно, другие в будущем:

  • для Google Analytic Code
  • Некоторые коды JavaScript
  • HTML верхний и нижний колонтитулы для моего шаблона.

мне нужно решение, которое может быть централизовано, использование КЭШ, легко обновить:

Вот мои идеи, я хотел бы свое мнение:

  • 01 использует базу данных с таблицей (configure table), который для каждой записи (VARCHAR) позволит хранить эти шпинели кода в виде строки.
  • 02 Используйте простые текстовые файлы в определенной папке, поэтому я могу включить эти файлы в свой код. Я мог обновлять коды с помощью FTP и NotePad (здесь я обеспокоен кешем).
  • 03 Используйте файл Web.Conf.
  • 04 Используйте текстовый файл и класс, который будет управлять хранением в кеше содержимого этого файла.

Любые идеи? Спасибо за ваше время.

Здесь я хотел бы выделить и полезную статью по этой теме:

http://nathanaeljones.com/153/performance-killer-disk-io/

+0

Почему бы просто не поставить их на частичный вид? И html header/footer в главном представлении. – CodesInChaos

+2

Не беспокойтесь о диске IO. Сеть IO экспоненциально хуже. Кроме того, кеш не является аббревиатурой. – SLaks

+0

Ваши примеры, скорее всего, будут кэшироваться дисковым кэшем ОС, даже если вы используете простые файлы. Я знаю некоторые ограниченные диском приложения, но обычно у них есть несколько баз данных GB. – CodesInChaos

ответ

3

Прежде всего, ссылка на ссылку на блог Nathanael Jones, хотя диск IO намного медленнее, чем в операциях с памятью, большинство веб-сайтов не связаны с диском IO, а большинство его решений - откровенно необразованное дерьмо.

Вообще говоря, существует очень мало ситуаций, когда вы становитесь DISK io bound. Первый - это сам сервер базы данных. Если у него недостаточно памяти для хранения соответствующих частей базы данных в памяти, тогда скорость диска THAT-сервера имеет решающее значение; особенно в условиях высокой транзакции.

Во-вторых, вы можете привязать IO к диску, если ваше приложение напрямую читает и записывает много файлов. Очень немногие приложения делают это. Я не рассчитываю файлы .aspx или.html вашего приложения, потому что они могут кэшироваться существующей инфраструктурой и IIS.

В принципе, просто игнорируйте его.

Вся файловая система для синхронизации базы данных в качестве метода повышения производительности не имеет значения около 99,999% сайтов. Если ничего больше, база данных должна выталкивать файлы в файловую систему веб-сервера, а не наоборот. Я видел ровно 1 сайт за 20 лет развития, который требовал этого. Они обслуживают несколько миллионов просмотров страниц в день.Кроме того, он неверно говорит о том, что вызов базы данных по сети происходит быстрее, чем загрузка эквивалентного количества данных из локального файла.

Далее, фактическая область, с которой мы действительно связаны, заключается в отправке данных по сети в клиентский браузер. Это ВСЕГДА медленнее, чем чтение файла с диска; даже без трафика на линии. Жесткие диски перемещают данные намного быстрее, чем ваша сетевая карта. Сделав еще один шаг; современные жесткие диски на порядок быстрее, чем ваше интернет-соединение. Лучшее, что вы можете сделать для повышения производительности, - это просто ограничить количество запросов на подключение, требуемых для одной страницы. Оптимизация здесь означает наличие 1 css-файла, а не 20; имея только пару ссылок .js файлов, а не 100; и комбинировать графику с спрайтами, где это возможно. Благодаря тому, как работает TCP, быстрее передавать 1 большой файл, чем 100 небольших файлов.

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


С учетом этого, давайте рассмотрим вашу актуальную проблему.

Элементы javascript имеют два предпочтительных местоположения: 1. Как файлы .js на веб-сервере или 2. встроены в главную страницу. Просто выполните вариант 1, они будут кэшироваться веб-сервером. Кроме того, они будут кэшироваться браузером клиента, то есть вам не нужно будет

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

При обновлении содержимого заголовка или нижнего колонтитула просто передислоцируйте сайт.

+0

Спасибо за ваше сообщение, я подумаю об этом! Я также думаю, что SSI не является отличным решением и, может быть, немного устаревшим спасибо – GibboK

+0

Что касается добавления HEADER и FOOTER в БД и включение ссылки на главную страницу? Таким образом, я мог бы обновить веб-сайт без его повторного развертывания и иметь более управляемый сайт. Считаете ли вы, что у меня могут быть медленные выступления таким образом? Еще раз спасибо за ваше время. – GibboK

+0

@GIbboK: Вставить верхний/нижний колонтитул в БД. Их можно легко кэшировать и вашим уровнем доступа к данным; возможно, с истечением около 20 минут или около того. – NotMe

0

Храните ваши верхние и нижние колонтитулы в файлах и использовать Server Side Includes. Некоторые веб-серверы (IIS 6.0) могут позволить вам добавлять нижние колонтитулы документов ко всем страницам.

Храните свой Javascript в файлах и используйте на своих страницах. Это позволит кэшировать и улучшать производительность страницы.

+0

Как насчет SSI и CACHE? Сохранены ли в CACHE? Как насчет обновления? ЕСЛИ мне нужно изменить заголовок, мне нужно войти в систему IIS? спасибо – GibboK

+0

@GIbboK - см. «Включение срока использования контента» в http://flylib.com/books/en/3.202.1.31/1/ – DaveB