Кэширование данных: Кэширование данных для оптимизации производительности — Microsoft Azure Well-Architected Framework

05.08.1985 alexxlab

Содержание

Кэширование данных для оптимизации производительности — Microsoft Azure Well-Architected Framework

Twitter LinkedIn Facebook Адрес электронной почты

Статья
09/22/2022
Чтение занимает 2 мин

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

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

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

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

Кэширование может значительно повысить производительность, масштабируемость и доступность данных. Преимущества кэширования становятся все заметнее с увеличением объемов данных и числа пользователей, которым необходим доступ к этим данным. Это происходит потому, что кэширование снижает задержку и число конфликтов, связанных с обработкой больших объемов параллельных запросов в хранилище исходных данных.

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

Дополнительные сведения см. в разделе Кэширование.

Кэш Azure для Redis

Кэш Azure для Redis повышает производительность и масштабируемость приложения. Он обрабатывает большие объемы запросов приложений, сохраняя часто используемые данные в памяти сервера, в которой их можно быстро записать и считать. Кэш Azure для Redis на основе программного обеспечения Redis предоставляет хранилище данных с критически низкой задержкой и высокой пропускной способностью для современных приложений.

Кэш Azure для Redis также повышает производительность приложений за счет поддержки стандартных шаблонов архитектуры приложений. Некоторые из наиболее распространенных шаблонов включают кэш данных и кэш содержимого. Наиболее распространенные шаблоны и их описания см. в разделе Общие шаблоны архитектуры приложений.

Сеть доставки содержимого (CDN) Azure

Сеть доставки содержимого (CDN) является распределенной сетью серверов, которая позволяет эффективно доставлять пользователям веб-содержимое. Сети CDN хранят кэшированное содержимое на пограничных серверах в расположениях точек подключения, находящихся рядом с пользователями. Это позволяет свести задержки к минимуму. Дополнительные сведения о CDN см. в статье Что такое сеть доставки содержимого в Azure?

Azure CDN предлагает следующие основные возможности:

Динамическое ускорение сайтов (DSA) — предоставляет пользователям быстрые, надежные и настраиваемые веб-решения, которые не зависят от браузера, местоположения, устройства или сети.
Правила кэширования CDN — управление режимом кэширования Azure CDN.
Поддержка пользовательского домена HTTPS — безопасная доставка конфиденциальных данных при их передаче через Интернет и защита веб-приложений от атак.
Журналы диагностики Azure — экспорт основных метрик использования из конечной точки CDN в различные типы источников для их последующей настройки.
Сжатие файлов — увеличение скорости передачи файлов и повышение производительности загрузки страницы за счет уменьшения размера файлов перед их отправкой с сервера.
Геофильтрация — ограничение доступа к содержимому по стране или региону путем создания правил для конкретных путей в конечной точке CDN.

Секция

Кэширование данных в web приложениях. Использование memcached / Хабр

Я немного расскажу вам про кэширование. Кэширование, в общем-то, не сильно интересно, берешь и кэшируешь, поэтому я еще расскажу про memcached, довольно интимные подробности.

Про кэширование начнем с того, что просят вас разработать фабрику по производству омнониевых торсиометров. Это стандартная задача, главное делать скучное лицо и говорить: «Ну, мы применим типовую схему для разработки фабрики».

Вообще, это ближе к фабричному производству, т.е. откуда проблема пошла? Фабрика работает очень быстро, производит наши торсиометры. А для калибровки каждого прибора нужен чистый омноний, за которым надо летать куда-то далеко и, соответственно, пока мы в процессе добычи этого омнония, приборы лежат некалиброванные, и, по сути дела, все производство останавливается. Поэтому мы строим рядом с фабрикой склад. Но это не бесплатно.

Переходим к терминологии. Просто, чтобы мы общались про кэширование на одном языке есть довольно устоявшаяся терминология.

Источник называется origin; объем склада, т.

е. размер кэша — cache size; когда мы идем на склад за образцом нужной формы, и кладовщик выдает то, что мы просили — это называется cache hit, а если он говорит: «Нет такого», это называется cache miss.

У данных — у нашего омнониума — есть freshness, буквально — это свежесть. Fresheness используется везде. Как только данные теряют свою природную свежесть, они становятся stale data.

Процесс проверки данных на годность называется validation, а момент, когда мы говорим, что данные негодные, и выбрасываем их со склада — это называется

invalidation.

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

Схема такая, что от нашего браузера до бэкенда есть масса звеньев в цепи. Вопрос: где кэшировать? На самом деле, кэшировать надо абсолютно везде. И, хотите вы этого или нет, данные будут кэшироваться, т.е. вопрос, скорее, — как мы можем на это повлиять?

Для начала нужно найти хорошие данные для кэширования. В связи с тем, что мы делаем какой-то кэш, у нас появляется еще одно промежуточное звено в цепи, и необязательно, что кэш что-то ускорит. Если мы плохо подберем данные, то, в лучшем случае, он не повлияет на скорость, а в худшем — еще и замедлит процесс всего производства, всей системы.

Нет смысла кэшировать данные, которые часто меняются. Нужно кэшировать данные, которые используются часто. Размер данных имеет значение, т.е. если мы решаем кэшировать в памяти blu-ray фильм — классно, мы его очень быстро достанем из памяти, но, скорее всего, нам потом его придется перекачать куда-нибудь по сети, и это будет очень медленно. Такой большой объем данных не соизмерим со скоростью доставки, т.е. нам нет смысла держать такие данные в памяти. Можем на диске держать, но нужно сравнивать по скорости.

Кстати, можете погуглить «programming latencies». Там на сайте очень хорошо даны все стандартные задержки, например, скорость доступа в CPU cache, скорость отправки Round Trip пакета в дата-центре. И когда вы проектируете, что-то прикидываете, хорошо смотреть, там очень наглядно показано, что сколько времени и по сравнению с чем занимает.

Это готовые рецепты для кэширования:

Это релевантный HTTP Headers:

Я немного расскажу про некоторые, но, вообще-то, про это надо читать. В принципе, в вебе единственное, как мы можем влиять на кэширование — это правильно устанавливая вот эти header’ы.

Expires использовался раньше. Мы устанавливаем freshness для наших данных, мы буквально говорим: «Все, этот контент годен до такого вот числа». И сейчас этот header нужно использовать, но только как fallback, т.к. есть более новый header. Опять-таки, эта цепочка очень длинная, вы можете попасть на какую-то прокси, которая понимает только вот этот header — Expires.

Новый header, который сейчас отвечает за кэширование, — это Cache-Control:

Тут вы можете указать сразу же и freshness, и validation механизм, и invalidation механизм, указать, это public данные или private, как их кэшировать…

Кстати, no-cache — это очень интересно.

По названию очевидно, что мы говорим: кэшируйте везде, пожалуйста, как угодно кэшируйте, если мы говорим «no-cache». Но каждый раз, когда мы используем какие-то данные из этого контента, например, у нас есть формочка, и мы в этой формочке делаем submit, то мы говорим, что в любом случае все ваши закэшированные данные не актуальны, вам надо их перепроверить.

Если мы хотим, вообще, выключить кэширование для контента, то говорим «no-store»:

Эти «no-cache», «no-store» очень часто применяются для форм аутентификации, т.е. мы не хотим кэшировать неаутентифицированных пользователей, чтобы не получилось странного, чтобы они не увидели лишнего или не было недопонимания. И, кстати, про этот Cache-Control: no-cache… Если, допустим, Cache-Control header не поддерживается, то его поведение можно симулировать. Мы можем взять header Expires и установить дату какую-нибудь в прошлом.

Эти все header’ы, включая даже Content-Length, для кэша актуальны. Некоторые кэшируюшие прокси могут просто даже не кэшировать, если нет Content-Length.

Собственно, мы приходим к memcached, к кэшу на стороне бэкенда.

Опять же мы можем кэшировать по-разному, т.е. мы достали какие-то данные из базы, что-то в коде с ними делаем, но, по сути дела, это кэш, — мы один раз их достали, чтобы много раз переиспользовать. Мы можем использовать в коде какой-то компонент, фреймворк. Этот компонент для кэширования нужен, потому что у нас должны быть разумные лимитэйшны на наш продукт. Все начинается с того, что приходит какой-то инженер по эксплуатации и говорит: «Объясни мне требования на свой продукт». И вы должны ему сказать, что это будет столько-то оперативной памяти, столько-то места на диске, такой-то прогнозируемый объем роста у приложения… Поэтому, если мы что-то кэшируем, мы хотим иметь ограничения. Допустим, первое ограничение, которое мы можем легко обеспечить, — по числу элементов в кэше. Но если у нас элементы разного размера, тогда мы хотим это закрыть рамками фиксированного объема памяти. Т.е. мы говорим какой-нибудь размер кэша — это самый главный лимит, самый главный boundary. Мы используем библиотеку, которая может такую штуку делать.

Ну, или же мы используем отдельный кэширующий сервис, вообще stand-alone. Зачем нам нужен какой-то отдельный кэширующий сервис? Чаще всего бэкенд — это не что-то такое монолитное, один процесс. У нас есть какие-то разрозненные процессы, какие-то скрипты, и если у нас есть отдельный кэширующий сервис, то есть возможность у всей инфраструктуры бэкенда видеть этот кэш, использовать данные из него. Это здорово.

Второй момент — у нас есть возможность расти. Например, мы ставим один сервис, у нас заканчивается кэшсайз, мы ставим еще один сервис. Естественно, это не бесплатно, т.е. «а сегодня мы решили отмасштабироваться» не может случиться. Нужно планировать такие вещи заранее, но отдельный кэширующий сервис такую возможность дает.

Кэш еще дает нам availability практически за бесплатно. Допустим, у нас есть какие-то данные в кэше, и мы пытаемся достать эти данные из кэша. У нас что-то где-то падает, а мы делаем вид, что ничего не упало, отдаем данные с кэша. Оно, может, в это время переподнимется как-то, и будет даже availability.

Собственно, мы подобрались к memcached. Memcached — это типичный noSQL.

Почему noSQL для кэширования — это хорошо?

По структуре. У нас есть обычная хэш-таблица, т.е. мы получаем низкий latency. В случае с memcached и аналогичными key-value storage’ами — это не просто низкий latency, а в нотации big-O у нас сложность большинства операций — это константа от единицы. И поэтому мы можем говорить, что у нас какой-то временной constraint. У нас, например, запрос занимает не больше 10 мс., т.е. можно даже договариваться о каком-то контракте на основании этих latency. Это хорошо.

Чаще всего мы кэшируем что попало — картинки вперемешку с CCS’ом с JS’ом, какие-то фрагменты форм прирендеренных, что-то еще. Это непонятно, какие данные, и структура key-value позволяет их хранить довольно легко. Мы можем завести нотацию, что у нас account.300.avatar — это картинка, и оно там работает. 300 — это ID аккаунта в нашем случае.

Немаловажный момент — то, что упрощается код самого storage’а, если у нас key-value noSQL, потому что самое страшное, что может быть — это мы как-то испортим или потеряем данные. Чем меньше кода работает с данными, тем меньше шанса испортить, поэтом простой кэш с простой структурой — это хорошо.

Про memcached key-value. Можно указывать вместе с данными expiration. Поддерживается работа в фиксированном объеме памяти. Можно устанавливать 16-битные флаги со значением произвольно — они для memcached прозрачны, но чаще всего вы будете с memcached работать и с какого-то клиента, и скорее всего, этот клиент уже загреб эти 16 бит под себя, т.е. он их как-то использует. Такая возможность есть.

memcached может работать с поддержкой викшинов, т.е. когда у нас кончается место, мы самые старые данные выпихиваем, самые новые добавляем. Или же мы можем сказать: «Не удаляй никакие данные», тогда при добавлении новых данных она будет возвращать ошибку out of memory — это флажок «-М».

Структурированной единой документации по memcached нет, лучше всего читать описание протокола. В принципе, если вы наберете в Google «memcached протокол», это будет первая ссылка. В протоколе описаны не только форматы команд — отправка, что мы отправляем, что приходит в ответ… Там описано, что вот эта команда, она будет вести себя вот так и так, т.е. там какие-то корнер кейсы.

Коротенько по командам:

get — получить данные;

set/ add/ delete/ replace — как мы сторим эти данные, т.е.:

set — это сохранить, добавить новые, либо заменить,
add — это добавить только, если такого ключа нет,
delete — удалить;
replace — заменить, только если такой ключ есть, иначе — ошибка.

Это в среде, когда у нас есть шард. Когда у нас есть кластер, это никакой консистентности нам не гарантирует. Но с одним инстансом консистанси можно поддерживать этими командами. Более или менее можно такие constraint’ы выстраивать.

prepend/ append — это мы берем и перед нашими данными вставляем какой-то кусочек или после наших данных вставляем какой-то кусочек. Они не очень эффективно реализованы внутри memcached, т.е. у вас все равно будет выделяться новый кусок памяти, разницы между ними и set функционально нет.

Мы можем данным, которые сохраняем, указать какой-то expiration и потом мы можем эти данные трогать командой touch, и мы продляем жизнь конкретно вот этому ключу, т.е. он не удалится.

Есть команды инкремента и декремента — incr/decr. Работает оно следующим образом: вы сторите какое-то число в виде строки, потом говорит incr и даете значение какое-то. Оно суммирует. Декремент — то же самое, но вычитает. Там есть интересный момент, например, 2 — 3 = 0, с точки зрения memcached, т.е. она автоматически хэндлит андерфлоу, но она не дает нам сделать отрицательное число, в любом случае вернется ноль.

Единственная команда, с помощью которой можно сделать какую-то консистентность, — это cas (это атомарная операция compare and swap). Мы сравниваем два каких-то значения, если эти значения совпадают, то мы заменяем данные на новые. Значение, которое мы сравниваем, — это глобальный счетчик внутри
memcached, и каждый раз, когда мы добавляем туда данные, этот счетчик инкрементится, и наша пара key-value получает какое-то значение. С помощью команд gets мы получаем это значение и потом в команде cas мы его можем использовать. У этой команды есть все те же проблемы, которые есть у обычных атомиков, т.е. можно наделать кучу raise condition’ов интересных, тем более, что у memcached нет никаких гарантий на порядок выполнения команд.

Есть у memcached ключик «-С» — он выключает cas. Т.е. что происходит? Этот счетчик пропадает из key-value pair, если вы добавляете ключик «-С», то вы экономите 8 байт, потому что это 64-хбитный счетчик на каждом значении. Если у вас значения небольшие, ключи небольшие, то это может быть существенная экономия.

Как работать с memcached эффективно?

Она задизайнена, чтобы работать с множеством сессий. Множества — это сотни. Т.е. начинается от сотен. И дело в том, что в терминах RPS — request per second — вы не выжмете из memcached многого, используя 2-3 сессии, т.е. для того, чтобы ее раскачать, надо много подключений. Сессии должны быть долгоиграющие, потому что создание сессии внутри memcached — довольно дорогостоящий процесс, поэтому вы один раз прицепились и все, эту сессию надо держать.

Запросы надо batch’ить, т.е. мы должны отправлять запросы пачками. Для get-команды у нас есть возможность передать несколько ключей, этим надо пользоваться. Т.е. мы говорим get и ключ-ключ-ключ. Для остальных команд такой возможности нет, но мы все равно можем делать batch, т.е. мы можем формировать запрос у себя, локально, на стороне клиента с использованием нескольких команд, а потом этот запрос целиком отправлять.

memcached многопоточна, но она не очень хорошо многопоточна. У нее внутри много блокировок, довольно ad-hoc, поэтому больше четырех потоков вызывают очень сильный контеншн внутри. Мне верить не надо, надо все перепроверять самим, надо с живыми данными, на живой системе делать какие-то эксперименты, но очень большое число потоков работать не будет. Надо поиграться, подобрать какое-то оптимальное число ключиком «-t».

memcached поддерживает UDP. Это патч, который был добавлен в memcached facebook’ом. То, как использует facebook memcached — они делают все сеты, т.е. всю модификацию данных по TCP, а get’ы они делают по UDP. И получается, когда объем данных существенно большой, то UDP дает серьезный выигрыш за счет того, что меньше размер пакета. Они умудряются больше данных прокачать через сетку.

Я вам рассказывал про incr/decr — эти команды идеально подходят для того, чтобы хранить статистику бэкенда.

Статистика в HighLoad’e — это вещь незаменимая, т.е. вы не сможете понять, что, как, откуда происходит конкретная проблема, если у вас не будет статистики, потому что после получаса работы «система ведет себя странно» и все… Чтобы добавить конкретики, например, каждый тысячный запрос фейлится, нам нужна какая-то статистика. Чем больше статистики будет, тем лучше. И даже, в принципе, чтобы понять, что у нас есть проблема, нам нужна какая-то статистика. Например, бэкенд отдавал за 30 мс страницу, начал за 40, взглядом отличить невозможно, но у нас перформанс просел на четверть — это ужасно.

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

Первое — по каждой команде есть hits и misses. Когда мы обратились к кэшу, и нам отдали данные, поинкрементился hit по этой команде. Например, сделали delete ключ, у нас будет delete hits 1, так по каждой команде. Естественно, надо, чтобы hits была 100%, misses не было вообще. Надо смотреть. Допустим, у нас может быть очень высокий miss ratio. Самая банальная причина — мы просто лезем не за теми данными. Может быть такой вариант, что мы выделили под кэш мало памяти, и мы постоянно переиспользуем кэш, т. е. мы данные какие-то добавили-добавили-добавили, на каком-то моменте там первые данные выпали из кэша, мы за ними полезли, их там уже нет. Мы полезли за другими, их там тоже нет. И оно вот так все крутится. Т.е. надо либо со стороны бэкенда уменьшить нагрузку на memcached, либо можно увеличить параметром «-m» объем памяти, который мы разрешаем использовать.

Evictions — это очень важный момент. Ситуация, про которую я рассказываю, она будет видна из того, что evictions rate будет очень высокий. Это количество, когда пригодные данные не експайред, т.е. они свежие, хорошие выбрасываются из кэша, у нас тогда растет число evictions.

Я говорил, что надо использовать batch’и. Как подобрать размер batch’a? Серебряной пули нет, надо экспериментально это все подбирать. Зависит все от вашей инфраструктуры, от сети, которую вы используете, от числа инстансов и прочих факторов. Но когда у нас batch очень большой… Представьте ситуацию, что мы выполняем batch, и все остальные конекншны стоят и ждут, пока batch выполнится. Это называется starvation — голодание, т.е. когда остальные конекшны голодают и ждут, пока выполнится один жирный. Чтобы этого избежать, внутри memcached есть механизм, который прерывает выполнение batch’a насильно. Реализовано это довольно грубо, есть ключик «-R», который говорит сколько команд может выполнить один конекшн подряд. По умолчанию это значение 20. И вы, когда посмотрите на статистику, если у вас conn_yields stat будет каким-то очень высоким, это значит, что вы используете batch больше, чем может memcached прожевать, и ему приходится насильно часто переключать контекст этого конекшна. Тут можно либо увеличить размер batch’а ключиком «-R», либо не использовать со стороны бэкенда такие batch’и.

Еще я говорил, что memcached выбрасывает из памяти самые старые данные. Так вот, я соврал. На самом деле это не так. Внутри memcached есть свой memory менеджер, чтобы эффективно работать с этой памятью, чтобы выбрасывать эти атомы. Он устроен таким образом, что у нас есть slabs (буквально «огрызок»). Это устоявшийся термин в программировании memory менеджеров для какого-то куска памяти, т.е. у нас есть просто какой-то большой кусок памяти, который, в свою очередь, делится на pages. Pages внутри memcached по Мб, поэтому вы не сможете создать там данные «ключ-значение» больше одного Мб. Это физическое ограничение — memcached не может создать данные больше, чем одна страница. И, в итоге, все страницы побиты на чанки, это то, что вы видите на картинке по 96, 120 — они определенного размера. Т.е. идут куски по 96 Мб, потом куски по 120, с коэффициентом 1.25, от 32-х до 1 Мб. В пределах этого куска есть двусвязный список. Когда мы добавляем какое-то новое значение, memcached смотрит на размер этого значения (это ключ + значение + экспирейшн + флаги + системная информация, которая memcached нужна (порядка 24-50 байт)), выбирает размер этого чанка и добавляет в двусвязный список наши данные. Она всегда добавляет данные в head. Когда мы к каким-то данным обращаемся, то memcached вынимает их из двусвязного списка и опять бросает в head. Т.о., те данные, которые мало используются, переползают в tail, и в итоге они удаляются.

Если памяти нам не хватает, то memcached начинает удалять память с конца. Механизм list recently used работает в пределах одного чанка, т.е. эти списки выделены для какого-то размера, это не фиксированный размер — это диапазон от 96 до 120 попадут в 120-ый чанк и т.д. Влиять на этот механизм со стороны memcached мы никак не можем, только со стороны бэкенда надо подбирать эти данные.

Можно посмотреть статистику по этим slab’ам. Смотреть статистику по memcached проще всего — протокол полностью текстовый, и мы можем Telnet’ом подсоединиться, набрать stats, Enter, и она вывалит «простыню». Точно так же мы можем набрать stats slabs, stats items — это в принципе, похожая информация, но stats slabs дает картину, больше размазанную во времени, там такие stat’ы — что было, что происходило за весь тот период пока memcached работал, а stat items — там больше о том, что у нас есть сейчас, сколько есть чего. В принципе, обе эти вещи надо смотреть, надо учитывать.

Вот мы подобрались к масштабированию. Естественно, мы поставили еще один сервер memcached — здорово. Что будем делать? Как-то надо выбирать. Либо мы на стороне клиента решаем, к какому из серверов будем присоединяться и почему. Если у нас availability, то все просто — записали туда, записали сюда, читаем откуда-нибудь, не важно, можно Round Robin’ом, как угодно. Либо мы ставим какой-то брокер, и для бэкенда у нас получается, что это выглядит как один инстанс memcached, но на самом деле за этим брокером прячется кластер.

Для чего используется брокер? Чтобы упростить инфраструктуру бэкенда. Например, нам надо из дата-центра в дата-центр поперевозить сервера, и все клиенты должны об этом знать. Либо мы можем хак за этим брокером сделать, и для бэкенда все прозрачно пройдет.

Но вырастает latency. 90% запросов — это сетевой round trip, т.е. memcached внутри себя запрос обрабатывает за мкс — это очень быстро, а по сети данные ходят долго. Когда у нас есть брокер, у нас появляется еще одно звено, т.е. все еще дольше выполняется. Если клиент сразу знает, на какой кластер memcached ему идти, то он данные достанет быстро. А, собственно, как клиент узнает, на какой кластер memcached ему идти? Мы берем, считаем хэш от нашего ключа, берем остаток от деления этого хэша на количество инстанса в memcached и идем на этот кластер — самый простой солюшн.

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

Для этого есть механизм — consistent hashing ring. Т.е. что мы делаем? Мы берем хэш значения, все возможные хэш значения, например int32, берем все возможные значения и располагаем как будто на циферблате часов. Так. мы можем сконфигурировать — допустим, хэши с такого-то по такой-то идут на этот кластер. Мы конфигурируем рэнджи и конфигурируем кластеры, которые отвечают за эти рэнджи. Таким образом, мы можем тасовать сервера как угодно, т.е. нам надо будет поменять в одном месте это кольцо, перегенерировать, и сервера, клиенты или роутер, брокер — у них будет консистентное представление о том, где лежат данные.

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

memcached плохо подходит для consistancy каких-то решений, т.е. это больше решения на availability, но в то же время, есть какие-то возможности с cas’ом что-то наколхозить.

Контакты

» cachelot@cachelot. io
» http://cachelot.io/

Этот доклад — расшифровка одного из лучших выступлений на обучающей конференции разработчиков высоконагруженных систем HighLoad++ Junior.
Также некоторые из этих материалов используются нами в обучающем онлайн-курсе по разработке высоконагруженных систем HighLoad.Guide — это цепочка специально подобранных писем, статей, материалов, видео. Уже сейчас в нашем учебнике более 30 уникальных материалов. Подключайтесь!
Ну и главная новость — мы начали подготовку весеннего фестиваля «Российские интернет-технологии», в который входит восемь конференций, включая HighLoad++ Junior.

Кэширование данных Tile-сервера

При работе с Tile-сервером кэширование – это сохранение на жестком диске полученных с сервера растровых изображений с целью их дальнейшего многократного использования без повторных обращений к серверу.

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

Изображения, сохраняемые на диске, должны быть определенным образом организованы.

Текущая версия ZuluGIS и ZuluServer для организации кэшируемых файлов использует файловую структуру кэша программы Sas.Планета.

<Корневая папка>\z[Z+1]\[X/1024]\x[X]\[Y/1024]\[Y].<EXT>

Следует отметить, что независимо от системы отсчета плиток в исходной тайловой-системе, в кэш плитки складываются всегда в системе координат Lat0 = 90, Lon0 = -180, ось X – на восток, ось Y — на юг. То есть для записи в кэш нового файла, его исходные параметры X, Y, Z сначала преобразуются в новые параметры X, Y, Z для кэша. При совпадении систем координат тайлового слоя и кэша, параметры X, Y, Z не изменятся.

Корневая папка

Местоположение корневой папки кэша, создаваемого ZuluGIS или ZuluServer на компьютере, определяется следующим образом:

<Папка приложений для всех пользователей>\Zulu\ztc_<Код кэша>\

Папка приложений для всех пользователей – это системная папка, для создания приложениями данных для всех пользователей компьютера.

В зависимости от используемой операционной системы, путь папки может быть разным.

Windows XP:

C:\Documents and Settings\All Users\Application Data\

Windows 7:

C:\ProgramData\

Код кэша – числовой код, автоматически формируемый ZuluGIS, как контрольная сумма строки с шаблоном запроса (значение параметра Address в описателе).

Пример:

Address:

http://www.maps-for-free.com/layer/relief/

Папка кэша:

WindowsXP

C:\Documents and Settings\All Users\Application Data\Zulu\ztc_2138735954\

Windows 7

C:\ProgramData\Zulu\ztc_2138735954\

Для плитки Z = 15, X = 19141, Y = 9525 имя файла в формате PNG в Windows 7 сформируется так:

C:\ProgramData\Zulu\ztc_2138735954\z16\18\x19141\9\y9525.png

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

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

Варианты кэширования

Возможны несколько вариантов использования механизма кэширования.

Первый вариант. Описатель слоя расположен на том же компьютере и в шаблоне запроса указана связь с данными по протоколу HTTP.

Address: http://<шаблон запроса>

В этом случае запросы на получение плиток идут непосредственно к указанному в шаблоне серверу. Полученные плитки складываются в кэш на этом компьютере.

При этом если в организации несколько компьютеров обращаются к одному и тому же ресурсу глобальной сети, на каждой машине будет создаваться свой кэш, а общая нагрузка на глобальную сеть возрастет пропорционально количеству пользователей.

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

Например, если в область данных сервера поместить описатель sample.zww, то для его публикации на сервере достаточно создать в той же папке текстовый описатель sample.zl с одной строкой:

Path: sample.zww

В этом случае клиенты ZuluServer будут обращаться за данными не прямо к серверу тайловых данных, а к тайловому слою, опубликованному на ZuluServer (например, Zulu://zs_host:6473/sample.zl).

При обращении клиента к ZuluServer за плиткой, ZuluServer проверит, нет ли такого изображения в кэше сервера. Если изображение найдено в кэше сервера, оно будет отправлено клиенту без обращения в глобальную сеть. Если изображение в кэше отсутствует, ZuluServer запросит его из глобальной сети, положит себе в кэш и отправит клиенту.

Таким образом, ZuluServer может выступать как посредник в предоставлении данных тайл-сервера клиенту.

Удобство такого варианта в том, что для всех клиентов ZuluServer кэш будет создаваться в одном месте, на диске сервера, сильно сокращая количество запросов в глобальную сеть и существенно экономя дисковое пространство клиентских машин.

Кроме того, при таком подходе клиентские машины вообще могут не иметь доступа в интернет.

Третий вариант. Кэш располагается на локальном компьютере, но данные для него получать не из глобальной сети, а от ZuluServer.

Для этого нужно создать на локальной машине описатель, с моделью «Тайловый слой ZuluServer» и в шаблоне запроса указать имя тайлового слоя на сервере:

Method: ZS Address: Zulu://zs_host:6473/sample.zl

В этом случае для получения изображения клиент проверяет, нет ли его в локальном кэше. Если нет, клиент обращается за изображением на ZuluServer. ZuluServer проверяет, нет ли изображения в его кэше.

Если нет, ZuluServer обращается за изображением в глобальную сеть, получает изображение, сохраняет его в своем кэше, и отправляет клиенту.

Клиент, получив изображение от ZuluServer, кладет изображение в свой кэш.

При таком комбинированном варианте клиент нагружает ZuluServer только по необходимости, а ZuluServer только по необходимости загружает глобальную сеть.

Новости компании

Предлагаем ознакомиться с переводом статьи Антонелло Занини о кешировании: что это такое, как оно работает и какие типы кеширования являются наиболее важными.

За последние несколько лет информационные технологии значительно улучшили любой вид бизнеса. Между тем архитектуры программного обеспечения становятся все более сложными, и число их пользователей растет в геометрической прогрессии. Это вызывает проблемы с точки зрения работы любого приложения. Низкая производительность может подорвать стратегические цели любой компании, поэтому очень важно найти разумные способы ее улучшения. Как следствие, необходимо избежать накладных расходов и сократить время поиска и обработки данных. Вот почему в игру вступает кеширование, и ни один разработчик больше не может его игнорировать.

Сперва углубимся в концепцию кеширования, поймем, почему это важно, и возможные риски, связанные с этим. Затем мы изучим наиболее важные типы кеширования.

Что такое кеширование

Кеширование — это механизм повышения производительности любого типа приложений. Технически кеширование — это процесс хранения и доступа к данным из кеша. Но подождите, что такое кеш? Кеш — это программный или аппаратный компонент, предназначенный для хранения данных, будущие запросы на которые могли бы обслуживаться быстрее.

Основная причина появления кеширования заключается в том, что доступ к данным из постоянной памяти занимает значительное время. Таким образом, всякий раз, когда данные извлекаются или обрабатываются, они должны храниться в быстрой оперативной памяти. Мы называем такую память «кешем», рассматриваемым как высокоскоростной уровень хранения данных, основная цель которого — уменьшить потребность в доступе к более медленным слоям хранения данных. Чтобы быть рентабельными и эффективными, кеши должны быть относительно небольшими, особенно по сравнению с традиционной памятью. Вот почему они обычно реализуются с использованием оборудования с быстрым доступом, такого как RAM (Random Access Memory, или оперативная память), плюс программный компонент.

Благодаря кешам можно реализовать механизм для эффективного повторного использования ранее извлеченных или вычисленных данных. При поступлении нового запроса запрашиваемые данные сначала ищутся в кэше. Попадание в кеш происходит, когда запрашиваемые данные могут быть найдены в кеше. Напротив, промах в кеш-памяти происходит тогда, когда запрашиваемые данные отсутствуют в кеше. Очевидно, предполагается, что считывание нужных данных из кешей происходит быстрее, чем повторное вычисление результата или его чтение из исходного хранилища данных. Таким образом, чем больше запросов обработается из кеша, тем быстрее будет работать система.

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

В чем значимость кеширования

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

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

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

Еще один значимый аспект кеширования — оно позволяет нам каждый раз избегать создания новых запросов или повторной обработки данных. Так что можно избежать накладных расходов, таких как накладные расходы на сеть, и уменьшить использование центрального процессора, особенно если запросы связаны со сложной обработкой. Это может продлить срок службы машин или серверов. Кроме того, отказ от создания новых запросов снижает общее количество необходимых запросов, что может снизить стоимость вашей инфраструктуры. Фактически, при работе с облачными платформами или поставщиками общедоступных API, например, принято выставлять счет за любую сетевую связь между их службами. Отличные побочные эффекты, не правда ли?

Проблемы

Кеширование — отнюдь не простая практика, и этому предмету присущи неизбежные проблемы. Давайте разберемся с самыми коварными.

Проблема согласованности

Поскольку всякий раз, когда данные кешируются, создается их копия, существует теперь две копии одних и тех же данных. Это значит, что со временем они могут расходиться. В двух словах, это вопрос согласованности — наиболее важная и сложная проблема, связанная с кешированием. Не существует конкретного решения, которое было бы предпочтительнее другого, и лучший подход зависит от требований. Определение наилучшего механизма обновления или аннулирования кеша — одна из самых больших проблем, связанных с кешированием, и, возможно, одна из самых сложных задач в научных изысканиях.

Выбор данных для кэширования

Кешировать можно практически любые данные. Значит, выбор того, что должно находиться в нашем кеше, а что следует исключить, открывает бесконечные возможности и, соответственно, может стать очень сложным. При решении этой проблемы необходимо учитывать некоторые аспекты. Во-первых, если мы ожидаем, что данные будут часто меняться, не следует кешировать их слишком долго. В противном случае мы можем предложить пользователям неточные данные. С другой стороны, это также зависит от того, сколько времени мы готовы хранить устаревшие данные. Во-вторых, кеш должен хранить часто запрашиваемые данные, для генерации или извлечения которых требуется много времени. Идентификация этих данных — непростая задача, и вы рискуете заполнить кеш бесполезными данными. В-третьих, кешируя большие данные, можно очень быстро заполнить кеш или, что еще хуже, использовать всю доступную память. Если оперативная память используется совместно приложением и системой кеширования, это легко может стать проблемой, поэтому следует ограничить объем оперативной памяти, зарезервированной для кеширования.

Работа с кеш-промахами

Промахи кеша увеличивают время, расходуемое на использование кеша. Фактически, недочеты в кеше приводят к задержкам, которых не было бы в системе, не использующей кеширование. Таким образом, для получения выгоды от увеличения скорости, обусловленной наличием кэша, количество промахов в кэше должно быть относительно низким. В частности, они должны быть минимальными по сравнению с попаданиями в кеш. Достичь этого результата непросто, а если его не достичь, система кэширования может превратиться в не более чем накладные расходы.

Типы кеширования

Хотя кеширование — это общая концепция, есть несколько типов, которые выделяются среди остальных. Они представляют собой ключевые концепции для любых разработчиков, заинтересованных в понимании наиболее распространенных подходов к кешированию, и их нельзя пропустить. Рассмотрим их все.

Кеширование в памяти

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

По сути, это значит, что каждая часть данных идентифицируется уникальным значением. Указав это значение, база данных «ключ-значение» вернет связанные данные. Такое решение быстрое, эффективное и простое для понимания. Вот почему разработчики, пытаясь создать слой кеширования, обычно предпочитают такой подход.

Кеширование базы данных

Каждая база данных обычно имеет определенный уровень кеширования. В частности, внутренний кеш обычно используется, чтобы избежать чрезмерных запросов к базе данных. Кешируя результат последних выполненных запросов, база данных может немедленно предоставить ранее кешированные данные. Таким образом, в течение периода времени, когда желаемые кешированные данные действительны, база данных может избегать выполнения запросов. Хотя каждая база данных реализует это по-разному, наиболее популярный подход основан на использовании хеш-таблицы, в которой хранятся пары ключ-значение. Как и раньше, ключ используется для поиска значения. Обратите внимание, что такой тип кеша обычно предоставляется по умолчанию технологиями ORM (Object Relational Mapping).

Веб-кеширование

Его можно разделить на две дополнительные подкатегории:

Кеширование веб-клиента

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

Кеширование веб-сервера

Это механизм, предназначенный для хранения ресурсов на стороне сервера для повторного использования. В частности, такой подход полезен при работе с динамически генерируемым контентом, для создания которого требуется время. И наоборот, он бесполезен в случае статического содержимого. Кеширование веб-сервера позволяет избежать перегрузки серверов, сокращая объем работы, которую необходимо выполнить, и улучшает скорость доставки страниц.

Кеширование CDN

CDN расшифровывается как Content Delivery Network, и он предназначен для кеширования контента, такого как веб-страницы, таблицы стилей, сценарии и мультимедийные файлы, на прокси-серверах. Его можно рассматривать как систему шлюзов между пользователем и исходным сервером, хранящую его ресурсы. Когда пользователю требуется ресурс, прокси-сервер перехватывает его и проверяет, есть ли у него копия. Если есть, ресурс немедленно доставляется пользователю; в противном случае запрос пересылается на исходный сервер. Прокси-серверы размещены в огромном количестве мест по всему миру, а запросы пользователей динамически направляются к ближайшему из них. Таким образом, ожидается, что они будут ближе к конечным пользователям, чем исходные серверы, что подразумевает сокращение задержки в сети. Кроме того, это также снижает количество запросов к исходным серверам.

Заключение

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

Переведено со статьи, полный текст доступен по ссылке.

Кэш | Основы Redis

Зарегистрируйтесь для доступа к 15+ бесплатным курсам по программированию с тренажером

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

Представим, что разрабатывается торговая платформа и есть личный кабинет с аналитикой сделок пользователя. Нужно выводить количество сделок, прибыль, средний оборот и тд. Большинство метрик являются агрегационными, то есть их нужно высчитывать. Если использовать только РСУБД, то среднее время ответа будет сотни миллисекунд, а при большой нагрузке — секунды. Можно подключить подходящие аналитические базы данных, но чаще всего это слишком дорого в средних проектах.

Самая распространенная практика решения сегодня — это кэш. Сложные вычисления кэшируются, то есть записываются в оперативную память. Обращение к оперативной памяти займет сотни наносекунд, примерно в миллион раз быстрее, чем вычислить данные из РСУБД. Новая схема взаимодействия будет включать кэширующий сервер. Алгоритм следующий:

клиент делает запрос
бекенд проверяет кэш. Если значение есть в кэше, то оно просто возвращается клиенту
если значения в кэше нет, то сервер вычисляет все из базы, записывает числа в кэш и отдает клиенту. Теперь все последующие запросы будут возвращать результаты вычислений из кэша

Подводные камни

Как у любого решения в разработке, кэширование — не серебряная пуля и имеет свои недостатки. Несколько моментов, которые стоит держать в уме при использовании кэша:

приложение должно уметь работать без кэша. Кэширующий сервер упал или недоступен? Пользователь все равно должен получать все данные просто с небольшой задержкой. Завязывать какую-то логику продукта на кэш (например, хранить данные аналитики только в кэше) — нельзя, потому что это ненадежное хранилище.
с введением нового звена в архитектуру всегда следует усложнение разработки и поддержки продукта. Проверка и запись значений в кэше — это дополнительная логика в коде, которая требует дополнительного времени на тестирование и исправление потенциальных ошибок.
сколько времени должно храниться значение в кэше? Что делать, если значение невалидно, так как пользователь открыл новую сделку или получил прибыль? Эти вопросы будут возникать постоянно, и в каждом проекте ответы будут уникальными.

Redis как кэш

Redis чаще всего используют именно как кэширующий сервер. Он имеет богатый встроенный функционал для этих целей. Рассмотрим основные команды, с помощью которых кэшируют значения в Redis.

Кэширование

Представим, что нужно записать количество сделок пользователя в кэш. Запишем, что у пользователя с ID 33 имеется 5 сделок. Используем обычную команду set:

127.0.0.1:6379> set user:33:deals_count 5
OK

Данные записаны. Однако они будут храниться вечно до следующей перезагрузки сервера или пока не будут удалены вручную. Одно из основных свойств кэша — это то, что он хранится короткий промежуток времени. Данных может быть много, а ресурсы серверов не бесконечны. К счастью в Redis можно указать время жизни ключа (время экспирации), по истечении которого ключ будет удален. Для этого достаточно добавить префикс ex количество_секунд к команде set:

127.0.0.1:6379> set user:33:deals_count 5 ex 120
OK

Проверить, через сколько ключ удалится можно командой ttl:

127.0.0.1:6379> ttl user:33:deals_count
(integer) 115

В данном случае ключ user:33:deals_count исчезнет через 115 секунд.

Если попытаться получить значение спустя это время, то вернется пустой ответ:

127.0.0.1:6379> get user:33:deals_count
(nil)

Время жизни можно задавать не только в секундах, но и в миллисекундах с помощью префикса px количество_миллисекунд:

set user:33:deals_count 5 px 10000

Проверка времени жизни осуществляется командой pttl:

127. 0.0.1:6379> pttl user:33:deals_count
(integer) 7484

Вывод выше показывает, что ключ user:33:deals_count исчезнет через 7484 миллисекунд (~7.4 секунд).

Инвалидация кэша

Любой кэш может стать неактуальным раньше времени жизни. В нашем примере со сделками это может произойти при возникновении новой сделки у пользователя. В этом случае нужно удалить ключ в кэше, чтобы при следующем запросе произошел пересчет значения. Может возникнуть вопрос: а почему бы просто не добавить значение в имеющийся ключ? В данном примере это было бы наилучшим решением, но действовать необходимо не «в лоб». При увеличении значения двумя командами get + set может получиться неконсистентное состояние (подробнее эта проблема будет рассмотрена в следующем уроке). Также обновление значения не всегда возможно, например, в случае если значение — это среднее арифметическое.

Удаление ключа происходит командой del:

127.0.0.1:6379> del user:33:deals_count
(integer) 1

Вернувшееся значение 1 означает, что ключ существовал и был успешно удален. Если ключа не было, то вернулся бы 0.

Иногда требуется удалить тысячи ключей за раз. Например, у поставщика цен на акции произошел сбой и все сделки за период сбоя оказались недействительными. В этом случае нельзя использовать N вызовов команды del, потому что это будет выполняться очень долго и заберет все ресурсы Redis. Для множественного удаления существует команда unlink, которую можно безопасно использовать в продакшен-среде:

127.0.0.1:6379> unlink user:1:deals_count user:2:deals_count user:3:deals_count
(integer) 1

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

Резюме

ASP.NET Углубленый. Кэширование данных в ASP.NET

Главная >
org/ListItem»> Каталог >
ASP.NET Углубленный >
Кэширование данных в ASP.NET

Для прохождения теста нужно авторизироваться

Войти Регистрация

Вы открыли доступ к тесту! Пройти тест

Войдите или зарегестрируйтесь для того чтоб продолжить просмотр бесплатного видео

Войти Регистрация

№1

Архитектура IIS. Жизненный цикл HttpApplication

1:04:40

Материалы урокаДомашние заданияТестирование

Первый видео урок посвящен архитектуре IIS. Также, автор подробно разъясняет жизненный цикл и способы конфигурации ASP.NET приложений.

В этом видео уроке будут рассмотрены следующие темы:

архитектура IIS сервера;
жизненный цикл ASP. NET-приложения;
класс Global.asax;
жизненный цикл веб-страницы;
настройка приложения, иерархия config-файлов.

Http модули и обработчики

0:50:13

Материалы урокаДомашние заданияТестирование

В этом видео уроке будут рассмотрены следующие темы:

Создание пользовательского HTTP обработчика
Интерфейс IHttpHandler.
Использование ASHX файлов.
Создание пользовательских HTTP модулей. Интерфейс IHttpModule.
Варианты использования HTTP модулей.

Асинхронные страницы в ASP.NET

1:14:35

Материалы урокаДомашние заданияТестирование

В этом видео уроке будут рассмотрены следующие темы:

Обработка запросов на стороне сервера. Принцип использования потоков из пула потоков ASP.NET
Создание асинхронных страниц с использованием AddOnPreRenderCompleteAsync
Создание асинхронных страниц с использованием PageTaskAsync
Введение в TPL. Использование async await
Асинхронные страницы в 4 Framework
Асинхронные обработчики и интерфейс IHttpHandler
Замер производительности с помощью Visual Studio

№4

Пользовательские элементы управления

0:51:29

Материалы урокаДомашние заданияТестирование

В этом видео уроке будут рассмотрены следующие темы:

Создание и регистрация контроллера
Определение свойств
Определение событий
Пример создание пользовательского элемента управления TabControl
Динамическое создание элементов управления

Пользовательские серверные элементы управления

0:58:36

Материалы урокаДомашние заданияТестирование

В этом видео уроке будут рассмотрены следующие темы:

Создание простейшего элемента управления.
Базовый класс WebControl
Создание контролов на основе готовых элементов управления.
Использование класса CompositeControl
Использование элементов управления, отправляющих обратные запросы

Элементы управления, связанные с данными

1:00:59

Материалы урокаДомашние заданияТестирование

В этом видео уроке будут рассмотрены следующие темы:

Создание элемента управления, который поддерживает работу с данными, используя класс DataBoundControl.
Привязка данных с использованием свойства DataSource и DataSourceId.
Создание списочного элемента управления.
Создание элемента управления, который поддерживает работу с шаблонами.
Использование атрибутов.

Кэширование данных в ASP.NET

0:53:54

Материалы урокаДомашние заданияТестирование

В этом видео уроке будут рассмотрены следующие темы:

Кэширование данных
Настройки кэширования
Повышение производительности приложений

Читать дальше. ..

Кэширование вывода в ASP.NET

0:50:08

Материалы урокаДомашние заданияТестирование

В этом видео уроке будут рассмотрены следующие темы:

Атрибуты директивы OutputCache
Использование кэширования вывода для UserControl
Использовать элемент управления Substitution
Создавать кэш вывода, который будет зависеть от SQL базы данных.

Membership API

1:03:28

Материалы урокаДомашние заданияТестирование

В этом видео уроке будут рассмотрены следующие темы:

Настройка аутентификации через формы. Работа с классом FormsAuthentication
Создание приложения с регистрацией и авторизацией с использованием MembershipAPI
Создание приложения с регистрацией и авторизацией с использованием стандартных элементов управления
Настройка доступа к приложению по ролям

Читать дальше. ..

Следующий курс:

Основы ASP.NET MVC

ПОКАЗАТЬ ВСЕ

основные темы, рассматриваемые на уроке