Хорошая структура базы данных и правильные индексы могут сэкономить кучу процессорного времени при доступе к базе данных из Web приложения. Но даже не смотря на самые лучшие индексы и мега оптимизацию, если дергать сервер по каждой мелочи, то он не сможет потянуть даже средне нагруженное приложение.
Сервер приложений должен кэшировать как можно больше информации, особенно, если она изменяется редко или вообще не изменяется. В базах данных очень хранят конфигурационные параметры, которые не изменяются годами.
На больших сайтах очень часто создается множество маленьких табличек с двумя – тремя полями, в которой хранится какая-то информация, которая создается один раз и не меняется годами. Например, допустим, что у вас есть табличка, в которой валюты, принимаемые сервером к оплате. Как часто мы добавляем новые валюты? Да раз в год.
Можно в наглую прописать валюты прямо в тексте страниц и обновлять код страниц в случае необходимости, но от этого теряется гибкость. В тот момент, когда наступает необходимость добавить или изменить валюту, вы наткнетесь на серьезную проблему.
Вполне логично использовать данные из базы, но просто кэшировать их на стороне сервера приложения. Так как мы сегодня рассматриваем постоянные данные, которые меняются раз в год или реже, а доступ к ним идет часто, то для такого случая можно использовать статичные переменные.
Если мне не изменяет память, то статичные переменные используют разделяемую память в процессе w3svc.exe. Это значит, что при старте Web приложения будет создана копия, которая будет разделяться между всеми потоками. Таким образом данные будут храниться в памяти, постоянно под рукой сервера и не нужно будет постоянно обращаться к базе данных.
Лично я постоянно использую этот метод кэширования для статичных данных, которые не меняются. Когда наступает тот страшный момент необходимости изменить данные, я делаю изменения в базе и тут же делаю Recycle на Application Pool, чтобы сервер перегрузил все переменные.
Еще раз подчеркну, что этот метод нужно использовать только со статичными данными. Которые инициализируются из базы один раз и потом не изменяются в памяти.
Вообще статичные переменные нужно использовать осторожно с Web приложениями. Как я уже сказал, память будет разделяемой между потоками, и не является устойчивой к изменениям в потоках. Я как-то ни разу не пробовал изменять статичные переменные в Web приложениях, но боюсь, что это может закончится не желательным результатом.
Если вы хотите кэшировать изменяемые данные, такие как информация о продукте, список разделов статей или товаров на сайте (администраторы сайта могут менять эти данные), то эту информацию так же нужно и можно кешировать, но уже другими методами, а это уже отдельная история.
Понравилось? Кликни Лайк, чтобы я знал, какой контент более интересен читателям. Заметку пока еще никто не лайкал и ты можешь быть первым
В базах данных очень хранят конфигурационные параметры, которые не изменяются годами. - ошибочка
На самом деле классный пост.После РНР логично получается, наш гуру ударился в вэб. Только недавно смотрел общего развития ради на msdn "Пошаговое руководство. Использование кэширования выходных данных ASP.NET с SQL Server", если будете гуглить то есть возможность нараваться ещё вот на это "Кэширование данных приложения", так что тема эта весьма обширная. Да ну все эти web-matrix-сы. Как ни странно, но я последнии три сайта, хотя это очень не сложно, весь вэб оформил на Perl. Ничего сложного, верхний/нижний колонтитулы, форма обратной связи, личный кабинет для пользователей и т.п. Всё писал в Linux, и ничё так, нормально, ну да, не рнр и не asp, ну и что? А чем хуже?
Хотите найти еще что-то интересное почитать? Можно попробовать отфильтровать заметки на блоге по категориям.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
