кэширование что это такое простыми словами
Что такое кэш и зачем его чистить
Это старые данные, которые уже могут быть неактуальны
Когда не работает какой-то сайт или сервис, от техподдержки часто можно услышать «Почистите кэш и перезагрузите страницу». Иногда это помогает. Рассказываем, почему так происходит, что такое кэш, зачем он нужен и как его почистить.
⚠️ Минутка грамотности. По словарю РАН слово cache в русском пишется «кеш». Но по рекомендациям Гиляревского нужно писать «кэш». И нам нравится, как это произносится. Произнесите вместе с нами:
Что такое кэш
Кэш — это данные, которые компьютер уже получил и использовал один раз, а потом сохранил на будущее. Смысл кэша в том, чтобы в следующий раз взять данные не с далёкого и медленного сервера, а из собственного быстрого кэша. То же самое, что закупиться продуктами на неделю и потом ходить не в магазин, а в холодильник.
В случае с браузером это работает так:
Дальше происходит так:
4. Если вкладкой или браузером долго не пользовались, операционная система выгружает из оперативной памяти все страницы, чтобы освободить место для других программ.
5. Если переключиться назад на браузер, он моментально сходит в кэш, возьмёт оттуда загруженную страницу и покажет её на экране.
Получается, что если браузер будет брать из кэша только постоянные данные и скачивать с сервера только что-то новое, то страница будет загружаться гораздо быстрее. Выходит, главная задача браузера — понять, какой «срок годности» у данных в кэше и через какое время их надо запрашивать заново.
👉 Например, браузер может догадаться, что большая картинка на странице вряд ли будем меняться каждые несколько секунд, поэтому имеет смысл подержать её в кэше и не загружать с сервера при каждом посещении. Поэтому в кэше часто хранятся картинки, видеоролики, звуки и другие декоративные элементы страницы.
👉 Для сравнения: браузер понимает, что ответ сервера на конкретный запрос пользователя кэшировать не надо — ведь ответы могут очень быстро меняться. Поэтому ответы от сервера браузер не кэширует.
Какая проблема с кэшем
На первый взгляд кажется, что кэш — это прекрасно: данные уже загружены, к ним можно быстро обратиться и достать оттуда всё, что нужно, без запроса к серверу на другом конце планеты.
Но представьте такую ситуацию: вы заходите в интернет-магазин обуви, в котором покупали уже много раз, но товары почему-то не добавляются в корзину. Или добавляются, но кнопка «Оплатить» не работает. Чаще всего причина в том, что браузер делает так:
Решение — почистить кэш
Когда мы чистим кэш, оттуда удаляются все данные, которые браузер сохранил «на всякий случай». Это значит, что при обновлении страницы браузер заглянет в кэш, увидит, что там пусто и запросит все данные с сервера заново. Они, конечно, тоже сразу отправятся в кэш, но в следующий раз вы уже будете знать, что делать.
Чтобы очистить кэш в Сафари, достаточно нажать ⌥+⌘+E, а в Хроме — нажать Ctrl+Shift+Backspace (⇧+⌘+Backspace) и выбрать время, в пределах которого нужно очистить кэш:
Зачем нужен кэш, если из-за него всё ломается?
На самом деле всё ломается не из-за кэша, а из-за неправильных настроек сервера, которые отдают страницу. Потому что именно сервер должен сказать браузеру: «Вот это можно кэшировать, а вон то лучше не кэшируй, мало ли что».
Часто разработчики недокручивают эти настройки, и браузер не получает нужных инструкций, поэтому кэширует всё подряд. И тогда приходится вмешиваться, чистить кэш и восстанавливать работоспособность.
Теория кэша (часть вторая, практическая, дополненная)
Это вторая, дополнительная (upd: дополненная), часть моей статьи посвященной кэшированию информации при веб-разработке. Первая имеет название Теория кэша.
UPD: После многочисленных коментариев я сильно переработал статью, внес в неё больше конкретики и примеров, а так же убрал спорные моменты (например, касательно memcached). Спасибо всем, за конструктивную критику.
В данной статье я попытаюсь описать практические стороны кэширования, ориентированные, прежде всего, на сайты и системы управления контентом. Сразу предупреждаю, это мое личное мнение, которое не претендует на истину в последней инстанции. Большинство терминологии — моё, вы можете использовать его, если считаете нужным на своё усмотрение. Конструктивная критика приветствуется.
Итак.
Что нужно кэшировать
Как ни покажется странным, кэшировать целесообразно далеко не всё. Кэширующие механизмы сами по себе потребляют ресурсы, и если скажем, информация изменяется так же часто, как и выводится, то смысла кэшировать эту информацию никакого нет (например, системы статистики). Так же не стоит кэшировать процессы, которые и без того протекают быстро.
Например: Данные изменяются раз в 1 секунду. Происходит запрос на получение этих данных раз в 2 секунды. Данные кешируются 0,1 секунды, а отдаются из кеша 0,2 сек. Тогда при обращении к данным всегда будет получатся ситуация, когда нам потребуется перестроение данных — которая будет занимать 1 + 0,1 сек. А отдаваться данные из кеша практически не будут. Мы проигрываем эти 0,1 сек из-за кеша.
Первое, что должно быть кэшировано – информация, которая вычисляется крайне долго и ресурсоемко, и используется очень часто. Применимо к сайтам – это результаты выполнения модулей (или приложений), которые используют сложные запросы к базе данных. Кроме этого к ресурсоемким процессам относятся обращения к внешним ресурсам, использующим установку соединения (сокеты, curl и др.), а так же работу с большим объемом сложных данных (парсинг шаблонов, работа с изображениями и др.).
Куда нужно кэшировать
Далее в порядке убывания по скорости доступа к кэшу:
Память. Это memcached, APC, XCache и другие подобные технологии в том же духе. Они (как правило) предоставляют максимальную скорость доступа, но объем сильно ограничен. Память не подходит для больших данных, но хорошо подходит для сравнительно небольших объемов наиболее часто используемых данных, таких как скажем распарсеные шаблоны и др.
Например, у нас используется SAX-парсер. Он медленно парсит шаблоны. Сделаем следущее:
При запросе к шаблону сначала проверяется, находится ли он в памяти. Если да, то вытаскивается, делается unserialize и отдается. Если нет, мы создаем объект (парсим шаблон), сериализуем (serialize) его и помещаем в память (имя обозначим как хэш-код от пути файла). Осталось только решить, на каком основании будем обновлять данные кэша. Это можно сделать 2-мя способами:
1. Мы вообще не будем проверять изменения, а кэш будет существовать некоторый прмежуток времени, скажем, обновляться раз в час. Соответственно, при физическом изменении шаблона они вступят в силу максимум через час.
2. Мы будем контролировать изменения шаблона по времени его последнего сохранения. Для этого нам понадобиться еще одна переменная в памяти — время заненсения данных к кэш (можно назвать как имя переменной шаблона в памяти с префиксом time). Соответственно, мы должны будем её устанавливать равным текущему времени при сохранении объекта шаблона в памяти. Далее, при обращении к шаблону мы сначала сравниваем время изменения файла шаблона (filemtime) со временем закешированного в памяти. И если время изменения шаблона больше времени кэша, то выполняем его обновление. При таком подходе кэш может существовать вечно, если сам шаблон никогда не будет изменятся. Но как только он изменится, перестроится сам кэш.
Файловая система. Наиболее частоиспользуемый способ. Но и тут есть свои подводные камни. Доступ к файлам существенно замедляется, в директории их становится очень много (чем больше файлов, тем меньше скорость), а на некоторых файловых системах вообще существуют ограничения на количество (ext2 – 32768 файлов в директории). За этим надо строго следить. Например, нельзя для кэширования каких-то табличных данных сваливать их в одну директорию и делать названия равными первичным ключам. У вас такая схема просто когда-нибудь переполнится.
Вот так можно это сделать на php:
База данных. Тоже может быть использована для кэша. У базы данных есть сильное преимущество – выборка посредством SELECT. Если данных немного, но они зависят от огромного количество условий, то использование БД вполне оправдано, особенно если грамотно создать индексы в таблице. Напрмер, таблицу в БД можно использовать как хранилище результата выборки сложного запроса с объединением многих больших таблиц с применением большого количества условий. Саму выбоку можно поместить во временную таблицу, и выбирать данные уже из неё. Условия выборки будут тоже сложные, но многочилсенных JOIN уже не будет, что повысит скорость (особенно если используется ENGINE MEMORY применимо к MySQL).
Еще одно достоинство кэширование в БД – это упреждающая подготовка кеша. Скажем, можно первым и единственным запросом вытащить все данные для кэширования на конкретной странице и потом использовать уже их, если это нужно. Кэширование в БД конечно медленное, но грамотная организация может серьезно повысить эффективность использования кэша. И еще – существует SQLite, которая тоже хорошо подходит для этого. Особым эксклюзивом считается создание самой базы SQLite в memcached.
Использование БД для кэша мне представляется редким вариантом. Это больше возможность, нежели практическое применение. Просто, не стоит её упускать из вида.
Как нужно кэшировать
Для кэширования обычно используются хеширование строки, содержащей все параметры от которых зависит кэш. Если хотя бы какой-нибудь параметр изменился, то и сам хэш-код изменится. Для хранения в файловой системе от хеша «отрубаются» первые несколько символов и создаются соответствующие директории, чтоб не было переполнения файловой системе. Время изменения для файловой системы – это время модификации файла, для БД нужно отдельное поле, для памяти – отдельный параметр (см. пример выше).
Без хеш-кода у вас строка зависимостей может сильно распухнуть, тем более, если их много.
Скажем, в базе 50000 статей. Запрос к базе на получение одной статьи работает долго, что не удивительно с таким объемом. Простой счучай — у нас нет JOIN других талиц.
Делаем следущее — прописываем некоторую зависимость в таблицу зависимостей. Таблица у нас может быть простым массивом, который сериализован и положен в файл. Это нужно для проверки актуальности кэша, что бы решить перестроить закешированные данные в связи с их изменением или можно использовать имеющиеся в кэше. При любом изменении нашей таблице в БД обновляем эту зависимость в таблице, т.е. устанавливаем время равное текущему. Объемы у нас большие, значит лучше использовать кеширование в файловую систему.
Кладем результат выполнения в кэш. При повторном запросе, сравниваем время изменения файла кэша с временем из таблицы зависимостей. Если время файла кэша меньше, перестраиваем — иначе отдаем то что в кэше.
Теперь. Если у нас в одной из 50000 статей мы изменили одну букву, то кэш дропнется для всех, что не является эффективным. Попробуем этого избежать:
Предположим, у нас для каждой статьи есть место где она отображается полностью. Еще есть лента статей, где отображаются краткая информация у всех, которая так же кэшируется вышеописанным способом. Если изменится одна статья, то изменится место, где она отображается полностью, а так же лента (потому что она в ней присутствует). Тогда мы создадим отдельный кэш для каждой из статьи и отдельный кэш для ленты:
Кэш ленты явно зависит от заблицы зависимостей (и неявно зависит от каждой отдельной статьи), т.е. времени последнего изменения таблицы со статьями в БД. Но отдельно взятая статья условно зависит от этого времени, т.е. она зависит от него при условии, что изменилась именно эта статья. Поэтому при показе отдельной статьи мы не будем использовать это время: если есть кэш статьи, то его покажем. Если нет — то построим статью и положим в кэш. Но, важное условие при этом — при редактировании отдельно взятой статьи мы должны удалить её кэш.
В итоге: При редактировании статьи мы обновляем время в таблице зависимостей и уничтожаем кэш этой статьи. При показе ленты решение об её обновлении принимается на основе таблицы зависимостей. При показе отдельной статьи если есть кэш, то он показывается. тем самым, при изменении статьи происходит перестройка кэша списка и этой статьи, но кэш других статей не затрагивается.
На что еще нужно обратить внимание
При кэшировании в файловую систему нельзя весь кэш пихать в одно место. То есть для каждых отдельных объектов лучше использовать свой директорий, например для страниц /cache/pages, для пользователей /cache/users и так далее. Это нужно, чтоб случайно данные не совпали. Допустим, у вас 2 разных сущности, с одинаковыми id. Так получилось, что надо сохнранить кэш обоих только по этому id. Хэш в обоих случаях будет одинаков, тем самым возникнет конфликт. Но если для каждой сущности будет выделен своё место, этого не будет.
При удалении элемента нужно не забывать удалять и сам кэш. Иначе со временем он распухнет из-за большого количества неактуальных данных. Как вариант – периодическое физическое удаление всего кэша.
Еще существует такая штука как «быстрый» кэш (FastCache, терминология моя). Идея FastCache заключается в том, что бы закэшировать наиболее часто используемые объекты наиболее быстрым образом, отметая все остальное. Например, можно положить полностью созданную главную страницу в память и отдавать её, если ничего не изменилось, незалогиненым пользователям. Основная нагрузка идет именно на главную страницу, поэтому это может сильно разгрузить ресурсы.
Заключение
Как правильно заметили в одном из комментариев прошлой статьи – кэширование — это часть оптимизации сайта, которое особенно эффективно при высоконагруженных системах. Эффективность работы сайта не состоит из эффективности одного только кэша. Более того, иногда он может быть вообще лишним, поэтому стоит хорошо подумать, прежде чем «прикручивать кэш». Если, например, посещаемость сайта менее 1000 человек в день о кэшировании можно не думать. Хотя конечно, смотря какой сайт.
Как кэширование ускорит ваш сайт
Похоже, что слово «кэширование» существует еще с самого начала эпохи компьютеров. Но что же это такое и как оно используется в работе сайтов?
Определения и быстродействие
Если исходить из самого простого определения, то кэш — это временное пространство для хранения или временная память, позволяющее обеспечить быстрый доступ к данным. Кэширование зачастую классифицируется по вариантам использования. На сегодняшний день разработчики веб-сайтов используют как минимум пять основных видов кэша.
Первый — кэширование объектов, при котором объекты приложения сохраняются локально для их дальнейшего использования при будущих запросах без необходимости обращения к исходному серверу. Следующий — кэширование баз данных, позволяющее сохранить в буфер памяти данные запроса для увеличения скорости работы баз данных. Кэширование байт-кодов, например с помощью OPcache, повышает эффективность PHP, сохраняя прекомпилированные скрипты в общую память. Таким образом, отпадает необходимость загрузки и синтаксического анализа PHP при каждом запросе. При кэшировании страницы сохраняются результаты работы скрипта в виде HTML-файла, который веб-сервер с легкостью сможет сразу же отдать, не обращаясь вновь к динамическому получению данных. Наконец, при кэшировании распространяемого контента используются географически распределенные серверы для увеличения скорости загрузки.
Хотя разница может показаться незначительной, на самом деле разные способы кэширования по-разному оптимизируют работу конкретного сайта. Чуть позже мы рассмотрим, как используются некоторые из них.
Мощность для производительности
Механизм кэширования зависит от аппаратной составляющей, на которой он применяется. Чем быстрее работает оборудование, тем быстрее запрошенная информация извлекается из кэша.
Самый медленный вариант — обыкновенный жесткий диск, который обрабатывает 200 мегабайт в секунду (Мб/с) и осуществляет 100 операций ввода-вывода в секунду (IOPS). Твердотельный накопитель (SSD) передает 600 Мб/с и осуществляет 300000 IOPS — намного лучше, чем обыкновенный жесткий диск. Но SSD проигрывают по сравнению со скоростью RAM: целых 20 Гб/с и четыре миллиона IOPS.
Скорость кэша, независимо от места кэширования, напрямую зависит от используемого вида носителя данных. То есть, чтобы ваш сайт работал максимально быстро, нужно новое, быстрое оборудование.
Кэширование и выбор хостинга
При выборе хостинга для вашего сайта необходимо, чтобы он удовлетворял вашим потребностям в оперативной памяти. Нет ничего плохого в том, чтобы хостинг превосходил ваши запросы, но если, с другой стороны, по каким-либо показателям он не дотягивает, то это может обернуться серьезными последствиями для работоспособности вашего сайта. Посмотрим, как виртуальный хостинг, выделенный сервер и виртуальное частное облако (VPC) отличаются по ресурсам оперативной памяти, и как эти отличия влияют на возможности кэширования, и соответственно, на быстродействие сайта.
Виртуальный хостинг
Это самый популярный (и самый экономный) вид веб-хостинга. При таком варианте большое количество сайтов размещаются на одном сервере, подключенному к сети. Часто встречается подвид виртуального хостинга — распределенный хостинг, который разделяет потребности сайтов по всем серверам в кластере, аналогично электросети (например, Grid от Media Temple).
На виртуальном хостинге скорость зависит от выделяемого объема RAM и вида носителя. Потрясающих показателей или полного доступа к системе у вас не будет, но в самом худшем случае вы можете рассчитывать на 200 Мб RAM и хранение на SSD.
Выделенный сервер и виртуальное честное облако
Хотя выделенный и виртуальный частный сервер (VPS) называются по-разному, в отношении кэширования они похожи, поскольку при обоих вариантах предлагается приоритетный доступ к выделенным ресурсам.
Выделенный хостинг предоставляет целый сервер с полноценным доступом к нему средствами Linux или Windows. Как и раньше, ваш выбор следует делать в пользу большего объема RAM (или по крайней мере, в соответствии с вашими потребностями) и хранилища данных на базе SSD накопителей. SSD обеспечит быстрый доступ к хранимым базам данных или страницам сайтов, основываясь на различных настройках кэширования для использования оперативной памяти и доставки веб-страниц. Одним из ключевых моментов является то, что на выделенном сервере можно разместить собственный виртуальные машины (VM) — аналоги компьютера, которые будут работать в рамках ограничений вашего веб-хостинга.
На VPS-хостинге пользователи получают отдельную виртуальную машину. Поставщик услуги резервирует необходимые ресурсы из собственной сети и разделяет их таким образом, который не затрагивает базовое оборудование. Как и у выделенного хостинга, у VPS есть целый ряд применений. Вы получаете полный контроль над ресурсами и можете запускать несколько процессов для максимальной эффективности их использования. Как и в других случаях, RAM и вид носителя данных обуславливают скорость сайта, а также используемый вид кэширования.
Сила CDN
Ускорить работу сайта также можно с помощью дополнительного к хостингу сервиса Content Delivery Network (Сеть доставки содержимого, CDN). CDN — это сеть серверов, которая позволяет доставлять веб-страницы и другой контент пользователям в зависимости от их географического расположения, источника веб-страницы и ближайшего к пользователю сервера доставки содержимого.
CDN — толковое решение для повышения скорости загрузки сайта. Поскольку веб-ресурсы передаются на сервер, расположенный близко к пользователю, CDN позволяет сэкономить бесценные миллисекунды за счет кэширования изображений, видео, загруженных файлов, JS, CSS, и даже HTML.
Выбрать подходящую CDN непросто. Советую обратить внимание на такие компании, как cedexis, бесплатно публикующие полезные статистические данные, которые помогут в выборе подходящей вашим требованиям CDN.
Наглядный пример: Enterprise WordPress от Media Temple
В этом году мы запустили Enterprise WordPress, новый сервис корпоративного уровня для WordPress. В нем сочетается управление хостингом WordPress, Amazon Web Services (AWS), круглосуточная техническая поддержка и управление выделенной учетной записью. В Enterprise WordPress используется множество разнообразных способов кэширования, что гарантирует пользователям наивысшую скорость облачного хостинга. В целом мы следуем общей схеме:
Практически каждый упомянутый нами тип кэширования используется для оптимизации сайтов на Enterprise WordPress. Во-первых, MySQL сервер, настроен на улучшение кэширования баз данных. Кэширование объектов осуществляется на отдельных серверах, полностью в оперативной памяти. Во-вторых, кэширование PHP-скриптов производится в общей памяти через OpCache, а это означает, что нет необходимости в перезагрузке скрипта для каждого запроса. Кроме того, кэширование страницы осуществляется на прокси-сервере и на отдельных серверах полностью в RAM, чтобы по запросу можно было доставлять целые HTML-файлы. Наконец, чтобы гарантировать, что пользователи сайта получают данные с ближайшего сервера, для доставки и хранения всего статического контента используется CDN.
Основные плагины для кэширования
К счастью уже существует очень много плагинов, которые помогут оптимизировать скорость ваших сайтов. Ниже некоторые их самых популярных:
Что такое кэширование сайта и почему это важно
Кэширование сайтов — это одна из наиболее полезных технологий. Ее применение делает сайты чрезвычайно быстрыми, что приводит к улучшению SEO и повышению удовлетворенности пользователей. Не говоря уже о более высокой конверсии, которую дает интернет кэш.
Что такое кэширование?
Сама идея реализации кеширования проста. Позвольте мне привести пример.
Если я спрошу вас, сколько будет 5 умножить 3, вы поймете, что правильный ответ 15. При этом не нужно его вычислять — вы просто помните результат, и не осуществляете никакой умственной обработки. Примерно так и работает кеширование.
Сайты тысячи, а иногда и миллионы раз в месяц. Каждый раз, когда браузер запрашивает веб-страницу, сервер должен выполнять кучу сложных вычислений. Он извлекает последние записи, генерирует шапку и подвал сайта, находит виджеты боковой панели и так далее. Но во многих случаях результат вычислений будет неизменным. Здорово, если бы мы могли заставить сервер запомнить окончательный результат, а не обрабатывать каждый запрос отдельно. Это именно то, что делает кеширование!
Как обслуживаются страницы с кэшем
Интернет кэш — что это такое? Сейчас поясню. Допустим, у вас есть блог с включенным кэшированием. Когда кто-то посещает главную страницу вашего блога в первый раз, он получает ее обычным способом: запрос обрабатывается на сервере, и полученная веб-страница, которая должна быть отображена, преобразуется в HTML-файл и отправляется в браузер посетителя.
Но что, если мой контент изменяется?
Это звучит здорово, но что, если вы включили кэширование, а затем опубликуете новую запись? Не будет ли она находиться вне кэша и не окажется ли невидимой для посетителей? Правильно настроенные системы кэширования прекрасно справляются с такими сценариями.
Система кэширования состоит не только из механизма хранения подготовленных HTML-файлов, но и механизма очистки кэша, когда выполняются определенные условия. Например, происходит публикация нового контента.
Является ли кэширование эффективным?
Сайт, разработанный и реализованный надлежащим образом, может загружаться всего за две секунды. Разве это недостаточно быстро? Необходимо ли использовать кэширование? Ответ — однозначно, да.
Используя кэширование в браузере и на сервере, вы все равно сможете сократить время загрузки. А когда речь идет о скорости загрузки, всегда стоит сделать так много, как только возможно!
Типы кэширования
Существует два типа кэширования — серверный и браузерный. Давайте рассмотрим различия между ними.
Кэширование в браузере
Перед тем, как почистить кэш в интернет эксплорер, нужно понимать, что кэширование позволяет браузеру хранить эти файлы какое-то время, поэтому не нужно извлекать их каждый раз, когда вы посещаете сайт. Например, при первом посещении сайта вы получите кучу ресурсов, которые браузер будет кэшировать. Это займет несколько секунд, но в следующий раз, когда зайдете на сайт, вы заметите значительное снижение времени загрузки.
Кэширование на сервере
Вместо обработки каждого запроса сервер принимает результаты этих запросов и сохраняет их. Затем он обслуживает сохраненные результаты, делая все намного быстрее.
Возможно, вы столкнетесь с терминами « кэш объектов » и « полный кэш страниц ». Оба обозначают методы кэширования на сервере. Кэш полной страницы — это то, о чем мы говорили до сих пор.
Кэш объектов хранит только фрагменты данных, а не полную страницу. Это может быть полезно при сохранении результата сложных операций, таких как создание меню навигации.
Кэширование в WordPress
Есть три вещи, которые нужно знать о кешировании в WordPress: написание эффективного кода, использование плагинов кэширования и использование встроенного кэша хостинга.
Использование плагинов кэширования WordPress
Самое важное правило – никогда не используйте одновременно больше одного плагина кэша страниц интернета. Это не сделает ваш сайт быстрее, а намного медленнее и в результате просто сломает.
Использование кэширования, осуществляемого хостингом
Написание эффективного кода
Например, если вы получаете метаданные для записи, и вызываете get_post_meta($post_id, ‘co-author’, true );,WordPress извлекает все метаданные для этого поста. Поэтому наличие 50 отдельных запросов get_post_meta() для извлечения одной записи не является расточительством.
Заключение
Кэш сайтов в интернете — это технология, которая увеличивает скорость работы сайта, не жертвуя при этом чем-либо значительно. При правильном использовании она не только приведет к значительному ускорению процесса загрузки страниц, но и уменьшит нагрузку на сервер.
Если вы еще не кэшируете свой сайт, сделайте это! Чтобы начать работу с кэшированием, ознакомьтесь с упомянутыми выше плагинами.
Пожалуйста, опубликуйте ваши мнения по текущей теме материала. За комментарии, отклики, подписки, дизлайки, лайки низкий вам поклон!
Дайте знать, что вы думаете по данной теме материала в комментариях. За комментарии, подписки, лайки, дизлайки, отклики огромное вам спасибо!