1. Что такое кэширование ASP/почему его следует кэшировать. Когда ваш веб-сайт изначально создан с использованием технологии ASP, вы можете ощутить удобство, предоставляемое технологией динамических веб-страниц ASP, а также свободу внесения изменений и бесплатное управление HTTP. Однако по мере увеличения количества посещений вы обязательно обнаружите, что скорость доступа к вашему сайту становится все медленнее и медленнее, а IIS перезапускается все чаще и чаще. Далее вам необходимо оптимизировать asp, например, заменить базу данных на более производительную, создать индексы, написать хранимые процедуры и т. д. Некоторые из этих мер не требуют увеличения затрат, в то время как другие требуют значительного давления (например, кластеризация доступа к SQL), и эффект не обязательно очевиден.
Столкнувшись с давлением веб-доступа, я считаю, что наиболее экономичным способом является использование технологии оптимизации кэша, чтобы снизить нагрузку на веб-сервисы.
Увеличение веб-трафика часто означает быстрый рост спроса на следующие ресурсы:
1. Увеличение трафика сетевых карт требует большего количества процессоров для обработки сетевого трафика и сетевых потоков ввода-вывода.
2. Необходимость чаще открывать/закрывать соединения с базами данных (если используется технология баз данных - обычно ASP использует базы данных в качестве хранилища данных), количество вещей, которые серьезно потребляют ресурсы, а также взаимоблокировки, вызванные транзакциями, конкурирующими за ресурсы, увеличат сетевой I/ O Или потребление процессора.
3. Если используется сеанс, IIS будет потреблять больше памяти для поддержания состояния, а потребление памяти может привести к нехватке физической памяти, что приведет к частому обмену между физической памятью и вспомогательной памятью, что приведет к приостановке выполнения кода и блокировке веб-ответа. .
4. Из-за отсутствия своевременного ответа на доступ это приведет к сбою доступа к веб-странице, что приведет к необходимости обновления пользователями, что приведет к увеличению спроса на такие ресурсы, как ЦП и память.
Фактически, учитывая распространенные веб-приложения, во многих случаях динамическое выполнение кода не является необходимым.
2. Классификацию кэша ASP можно обобщить без авторизации. Кэш ASP можно разделить на две категории:
1. Кэширование файлов. Так называемое кэширование файлов основано на логическом суждении о том, что конкретное выполнение определенного ASP не будет существенно меняться в течение определенного периода времени. Поэтому контент сохраняется в виде статического HTML, а затем в виде статического HTML. Технология веб-перенаправления используется, чтобы предоставить клиентам сквозной доступ к статическим файлам, чтобы уменьшить потребность в процессоре, ресурсах базы данных и т. д. Таких приложений много. Например, многие форумы восстанавливают все сообщение в статический файл при ответе на сообщение, а затем перенаправляют его, например форум donews.com. У статичности есть и побочный эффект (преимущество) — ее легко индексировать поисковыми системами, такими как Google. Некоторые так называемые системы выпуска новостей приняли эту технологию.
2. Кэширование фрагментов файлов. Так называемое кэширование файлов также основано на логическом суждении. Определенная часть данных (обычно получаемая путем запроса к базе данных большой емкости, потребляющей ресурсы) не изменится в течение определенного периода времени. мы можем хранить эти данные в виде файлов, при необходимости данные можно получить путем чтения файлов, чтобы избежать увеличения нагрузки на базу данных. Например, мы обычно храним некоторые данные в формате XML, а затем используем Вот как работает форум CSDN.
3. Кэш основной памяти. Кроме того, вы также можете рассмотреть возможность кэширования в памяти, сохраняя в памяти контент, требующий своевременного ответа, и как только потребуется доступ, он будет немедленно перенесен из быстрого хранилища. Если очень большое количество требований к доступу сосредоточено на нескольких небольших страницах или если основная память достаточно велика, я думаю, что использование кэширования основной памяти определенно может значительно улучшить производительность веб-доступа.
3. Как реализовать/использовать кеш. Для реализации кеширования необходимо учитывать следующие вопросы:
1. Какие страницы не изменятся за короткий период времени?
Проанализируйте собственный сайт, таких страниц много. Например, на веб-сайте обычно есть столбцы новостей и информации. Эти столбцы обычно публикуются администраторами сайта в определенное время дня, и после этого страницы редко изменяются. Тогда эти страницы подходят для статического кэширования файлов. Фактически, это то, что делает так называемая система выпуска новостей, поэтому вы также можете обратиться к идеям этих систем для преобразования ваших исходных динамических страниц ASP.
2. Эти страницы генерируются с использованием одной и той же логики для всех посетителей (то есть посетители не различаются).
В дополнение к таким столбцам, как новости и информация, где все посетители видят один и тот же интерфейс, ресурсоемкие приложения, такие как форумы, обычно могут быть спроектированы так, чтобы генерировать единую логику (один и тот же пост будет одинаково просматриваться тремя людьми и тремя людьми). такие страницы приложений мы также можем достичь с помощью статического кэширования. Вы также можете рассмотреть возможность фрагментации данных и использования технологии сценариев для их обработки, выходящей за рамки возможностей обработки сервера, то есть клиентского браузера.
3. Затраты и выгоды от использования кэширования.
Главное — «пространство для времени (ответа)». Используйте технологию кэширования для предварительной обработки контента, который часто понадобится в будущем, чтобы улучшить скорость реагирования веб-сервера и, что более важно, завоевать расположение посетителей.
Цена в том, что спрос на веб-пространство увеличивается, и в то же время может пострадать эффект доступа.
Но я думаю, что правильное кэширование имеет больше преимуществ, чем недостатков.
4. Эти места не подходят для кэширования страниц динамических запросов. Содержимое запросов у всех разное, поэтому результаты отображения различаются, поэтому кэширование результатов запроса более сложное, а коэффициент использования кэша низкий. вызывает проблемы с управлением. Стоимость высока (при условии, что вы кэшируете 1000 ключевых слов запроса, тогда управление соответствием между этими ключевыми словами и кэшем также затруднительно).
4. Анализ примера Предположим, что первоначальная структура форума предложений выглядит следующим образом:
В корневом каталоге:
Домашняя страница default.asp, обычно основные моменты, рекомендации и т. д.
listBorad.asp В этом файле перечислены имена и описания всех столбцов. Если он содержит параметр MainBID, это означает, что столбцы в разделе должны быть перечислены.
listThread.asp Если этот файл не содержит никаких параметров, это означает перечисление всех сообщений, а если он содержит MainBID, это означает перечисление всех сообщений в определенном блоке. Если указан subBID, это означает размещение сообщений в определенных столбцах. Если указан параметр страницы, темы перечислены в страницах.
ViewThread.asp перечисляет содержимое сообщения. Мы предполагаем, что сообщение отображается как комментарий, а все комментарии перечислены в конце. Параметр ID — это пост, который будет отображаться.
Reply.asp отвечает на определенное сообщение и содержит параметр Id для ответа на определенное сообщение. Остальные пока не будут обсуждаться.
Из вышесказанного мы видим, что если все сделано с использованием исходного ASP/PHP, то выполнение почти каждого файла asp требует операций с базой данных, частых запросов и запросов к нескольким таблицам. Вы должны знать, что запрос к базе данных в конечном итоге приведет к снижению производительности и скорости ответа, что повлияет на медленный просмотр посетителей и не будет способствовать качеству Интернета. Что еще более важно, так это то, что для двух людей, A и B, если они обращаются к ViewThread.asp и тому подобному, если идентификатор один и тот же, то они много раз увидят один и тот же контент (HTML-код, полученный их браузерами, почти полностью соответствует то же самое), но для этого «Того же контента» серверу необходимо открывать соединения с базой данных, запросы, читать записи, отображать, закрывать записи и соединения с базой данных. . . . Если больше людей получат доступ к следующим операциям, которые потребляют ресурсы сервера, конечным результатом будет то, что эти люди будут потреблять ресурсы сервера больше. Фактически, этих повторяющихся попыток получения «одного и того же контента» можно избежать, используя для оптимизации технологию кэширования. например:
После отправки содержимого в ответ.asp мы немедленно вызываем статическую функцию и сохраняем весь контент сообщения в виде статического HTML-файла, например viewThread_xxxx.htm. В обычных обстоятельствах при доступе к viewThread.asp?ID=xxxx система автоматически перенаправляет. в соответствующий статический файл viewThreadxxxx.htm. Таким образом, если публикация не имеет последней версии, она всегда будет предоставляться зрителям статическим контентом; при появлении новой отправки она будет обновлена до статического файла. Таким образом, многие операции с базой данных будут сохранены. и скорость реакции значительно улучшится.
listBorad.asp также можно реализовать статически. Мы можем проанализировать параметры, которые он может содержать, установить имя файла кэша listBoard_xx.htm и обновлять listBoard_xxx.htm при добавлении новых столбцов. listThread.asp аналогичен, за исключением того, что из-за большего количества параметров в нем будет много файлов кэша. Если вы хотите кэшировать listThread.asp? subBID=xxx&page=2, то соответствующий статический файл — listThread_xxx_p2.htm. То же самое касается default.asp.
Так как же узнать, когда обновляться? Когда он будет обновлен?
Обсуждая listThread.asp?subBID=xxx&page=2, мы извлекаем subID и страницу при выполнении listThread.asp, а затем определяем, существует ли listThread_xxx_p2.htm. Если он не существует, вызываем функцию статической генерации для создания файла и, наконец, перенаправляем. здесь статические файлы. Обратите внимание, что отсутствие здесь означает, что имеется новый контент, который необходимо обновить.
Итак, как сделать так, чтобы файл не существовал? удалить. Когда мы публикуем новое сообщение, удаляем сообщение или перемещаем сообщение, мы можем удалить все статические файлы, такие как listThread_xxx_p2.htm. Это говорит вам, когда кэшировать.
Теперь остался один вопрос: как генерировать статические файлы?
Отметим, что «тот же контент», о котором мы упоминали ранее. Мы можем сделать копию default.asp, listThread.asp и т. д. перед преобразованием с именем default_d.asp, listThread_2.asp и в том же каталоге (теоретически listThtrad.asp?subID=123 совпадает с LISTtHREAD_D.ASP). ? Результатом доступа SUBID=123 будет то же содержимое), поэтому в логике, которая должна генерировать статические файлы, мы вызываем копию перед преобразованием через запрос веб-доступа, получаем HTML-код и сохраняем его как статический файл. Этот веб-запрос на самом деле эквивалентен тому, что сам сервер просматривает HTML-код, который будет выведен до того, как какой-либо реальный браузер получит доступ к статическому содержимому, а затем возвращает эти коды и сохраняет их в виде статических файлов с помощью функции операции с файлами. Таким образом, файл кэша создается раньше реального средства просмотра.
Такое решение вряд ли затронет исходный макет и почти никогда не вызовет ошибки типа 404 из-за модификации. Во-вторых, статические файлы также помогут вашему сайту легко индексироваться поисковыми системами, такими как Google. Почему нет?
Наконец, напоминаем, что через веб-доступ в среде программирования ASP многие люди используют для доступа компонент xmlHTTP, что вызывает множество проблем. Сам xmlhttp будет кэшировать запрошенные ресурсы, в результате чего контент, который мы запрашиваем через этот компонент, будет не самым последним, что приводит к логической путанице. Поэтому для реализации ресурсов веб-запросов вам следует выбрать объект http xml-сервера или компонент winhttp.
Использование технологии кэширования в ASP может значительно повысить производительность вашего веб-сайта. На самом деле эти методы реализации очень просты. Здесь объясняется, как работает кэширование на сервере и как можно использовать метод, называемый технологией отключения ADO.
Прежде чем представить эти технологии, давайте объясним, что такое технология кэширования ASP.
Так называемый кеш на самом деле предназначен для освобождения места в памяти для сохранения данных. Используя кеш, вам не нужно часто обращаться к данным, которые вы сохраняете на жестком диске. Гибкое использование кеша позволяет избежать этого. горе от того, что плохой жесткий диск заполняется. Меня мучает чтение данных. Выполнив запрос и поместив результаты запроса в кеш, вы сможете быстро и повторно получать доступ к данным. И если вы не поместите данные в кеш, то при повторном выполнении запроса сервер потратит весь процесс на получение и сортировку их из базы данных.
Когда данные хранятся в кеше, время, затрачиваемое на повторный запрос, в основном приходится на отображение данных.
Другими словами, мы не должны помещать в кеш сервера данные, которые необходимо часто изменять. Мы должны помещать в кеш данные, которые изменяются меньше, но к которым необходимо часто обращаться.
Теперь мы обсудим, как ASP использует технологию кэширования на стороне сервера, а затем обсудим, как ASP использует технологию кэширования на стороне клиента.
Если у вас есть большой объем данных (статических, то есть менее изменяющихся), которые необходимо отобразить клиенту, вы можете рассмотреть возможность использования технологии кэширования на стороне сервера. Эта технология особенно подходит для веб-сайтов с строго согласованным стилем отображения (ха-ха, ее нелегко использовать для неосновных веб-сайтов).
На самом деле метод реализации очень прост. Чтобы понять, достаточно взглянуть на простой пример ниже.
Это пример программы для отображения категорий книг.
Файл DisplayBooks.ASP:
< %@ LANGUAGE=JavaS
сценарий % >
<html>
<тело>
<метод формы=сообщение>
Классификация книг < %= getBooksListBox() % >;
<р>
< тип ввода = отправить >
<%
функция getBooksListBox()
{
BooksListBox = Приложение("BooksListBox")
если (BooksListBox != null) вернуть BooksListBox;
crlf = String.fromCharCode(13, 10)
BooksListBox = «<select name=Books>» + crlf;
SQL = «Выбрать * ИЗ Книг в порядке В СРАВНЕНИИ ПО ИМЕНИ»;
cnnBooks = Server.CreateObject("ADODB.Connection");
cnnBooks.Open("Книги", "Администратор","");
rstBooks = cnnBooks.Execute(SQL);
fldBookName = rstBooks("ИмяКниги");
в то время как (!rstBooks.EOF){
BooksListBox = BooksListBox + ” <опция>” +
fldBookName + "" + crlf;
рстBooks.MoveNext();
}
BooksListBox = BooksListBox + ""
Приложение("BooksListBox") = BooksListBox
вернуть BooksListBox;
}
%>
Это очень просто. На самом деле здесь используется очень простая технология приложений, и разница всего в одном предложении:
Приложение("BooksListBox") = BooksListBox
Вы можете проверить это и обнаружить, что количество запросов на сервере значительно сократится. Эта ситуация особенно подходит для тех сайтов, контент которых обновляется не очень часто, например, вы обновляете его только один раз в день (или в течение длительного времени).
Далее мы обсудим технологию кэширования на стороне клиента. Эту технологию еще называют технологией отключенного соединения ADO (уровень трансляции слишком низкий, почему это звучит так неловко). Эта технология в основном используется для сохранения личной информации пользователей, такой как пароли пользователей, кодовые имена и т. д. В основном он использует некоторые свойства ADO. В то же время это также отвечает на вопрос, который упомянули некоторые пользователи сети, о том, можно ли использовать объекты ADO в Applocation. Объяснение неясно, пусть говорит код:
Файл GLOBAL.ASA:
< !–METADATA TYPE="TypeLib" FILE="C:Program FilesCommon
Файлысистемаadomsado15.dll»–>
< SCRIPT LANGUAGE=VBScript RUNAT="Сервер" >
Подприложение_OnStart
SQL = «Выберите имя пользователя и пароль из информации о пользователе»
cnnUsers = «DSN=Пользователь»
Установите rsUsers = Server.CreateObject("ADODB.Recordset")
«Обратите внимание, что следующие два предложения используются для реализации технологии ADO, называемой доступным отключением.
rsCustomers.CursorLocation = adUseClient
rsCustomers.Open SQL, cnnAdvWorks, adOpenStatic, AdLockReadOnly
'Отключаем RecordSet от базы данных
rsCustomers.ActiveConnection = Ничего
Установить Приложение("rsCustomers") = rsCustomers
Конец субтитра
Файлусерс.ASP
<%
'Метод Clone позволяет каждому пользователю иметь свою собственную коллекцию RecordSet.
Установите yourUsers = Application("rsUsers").Clone
Установите имя пользователя = yourUsers («Имя пользователя»)
Установить пароль = yourUsers("Пароль")
Делайте до тех пор, пока yourUsers.EOF
%>
Имя пользователя: < %= Имя пользователя % > Пароль пользователя: < %= Пароль % >
<%
yourUsers.MoveNext
Петля
%>