Вредоносное ПО (malware) - это назойливые или опасные программы,...
Из этой статьи вы узнаете как значительно ускорить сайт на WordPress с использованием Memcached.
Пошаговая инструкция
Memcached - система распределенного кэширования памяти
Memcached кэширует данные и объекты прямо в память RAM и сокращает время доступа к внешнему ресурсу (например, вызовы БД или API-вызовы). Это особенно помогает динамическим системам, таким как WordPress или Joomla!, заметно ускоряя время обработки запроса.
Важно: перед началом хотим заметить, что Memcached не имеет встроенных мер безопасности для работы на shared-хостинге! Данная инструкция подходит только для выделенного сервера (VPS).
Установка Memcached На нашем сервере используется Plesk с CentOS 7.x. Тем не менее, это руководство применимо и к другим системам, однако при выполнении следующих операций нужно использовать утилиты, специфичные для определённых систем (например, apt-get вместо yum). Для того чтобы установить Memcached, в первую очередь следует подключиться к серверу по SSH и использовать командную строку:# yum install memcached
После завершения установки вводим следующую команду:
# service memcached start
Далее следует установить PECL-версию Memcached для нужной версии PHP. WordPress полностью совместим с PHP 7, поэтому давайте активируем Memcached для последней версии PHP - 7.1. Начнём с установки всех необходимых пакетов для добавления их к нашему кастомному PHP-модую в Plesk:
# yum install make plesk-php71-devel gcc glibc-devel libmemcached-devel zlib-devel
Соберите модуль, следуя этим инструкциям. Вы можете не указывать директорию Memcached вручную, просто нажмите Ввод при запросе:
/opt/plesk/php/7.1/bin/pecl install memcached
Следующим шагом станет добавление строчки к соответствующему конфигурационному файлу, чтобы зарегистрировать модуль в PHP. Вы можете использовать командную строку, не открывая самого файла в редакторе:
# echo "extension=memcached.so" > /opt/plesk/php/7.1/etc/php.d/memcached.ini
И наконец, перечитайте обработчики PHP, чтобы модуль отобразился в информации о PHP в графическом меню Plesk.
# plesk bin php_handler -reread
Теперь Вы можете вызвать страницу phpinfo(), чтобы проверить корректную загрузку модуля Memcached:
Либо используйте командную строку:
# /opt/plesk/php/7.1/bin/php -i | grep "memcached support"
Защитите и контролируйте ваш Memcached Memcached по умолчанию использует порт 12211.Из соображений безопасности можно перенаправить данный порт на локальную машину.Добавьте следующую строку в конец файла /etc/sysconfig/memcached и перезагрузите службу Memcached:
OPTIONS="-l 127.0.0.1"
Для мониторинга и получения статистики от Memcached используйте следующие команды:
echo "stats settings" | nc localhost 11211
/usr/bin/memcached-tool localhost:11211
Скачайте скрипт с https://github.com/bonny/memcachy и переносите все файлы в директорию /wp-content/.
Если Вы не меняли порт Memcached по умолчанию (11211), Вы можете использовать его напрямую. Если вы изменили его, то в файл wp-config.php, лежащий в корневой директории вашей установки WordPress, следует добавить следующий код:
$memcached_servers = array(array("127.0.0.1", 11211));
Теперь, когда активирован бэкенд, мы установим кэширующий плагин для сохранения и предоставления обработанных страниц через Memcached. Установите плагин Batcache (https://WordPress.org/plugins/batcache/) используя инструкцию по установке:
define("WP_CACHE", true);
Важно: убедитесь, что Memcached для выбранной версии PHP включён корректно, иначе добавление этой строки вызовет ошибку!
Вот и всё! Теперь можете открыть advanced-cache.php и отрегулировать настройки по вашему усмотрению. Файл batcache.php - это небольшой плагин, который регенерирует кэш на статьях и страницах. Не забудьте активировать плагин в бэкенде на странице плагина!
Проверьте правильность работы Memcached в WordPress Теперь давайте убедимся, что все действия были выполнены как нужно. Самым простым способом подтвердить то, что генерируемая страница выдаётся из кэша, станет добавление дополнительного поля заголовка к ответу.Чтобы это сделать, нужно изменить файл advanced-cache.php. Откройте его и найдите строку
var $headers = array();
Замените её на:
var $headers = array("memcached" => "activated");
Откройте инструменты разработчика в своём браузере (F12 для Crhome), выберите вкладку «Network» и перезагрузите страницу несколько раз, чтобы быть уверенным, что страница грузится из кэша, и проверьте ответные заголовки. Если вы видите поле memcached - у уас всё получилось!
Обратите внимание, если вы вошли (залогинились) в административную панель сайта на WordPress, кэширование не будет задействовано и система всегда будет отдавать незакэшированную версию страницы. Каким образом проверить функциональность кэша в этом случае? Разлогиньтесь или откройте новую вкладку браузера в режиме «Инкогнито» и используйте инструменты разработчика в браузере.
Вместо изучения заголовков можно проверить исходный код загружаемой страницы. На то, что страница была загружена из кэша, указывают следующие строки:
Проведём стресс-тест вместе с Blitz.ioМы можем провести нагрузочное тестирование с помощью стресс-теста, симулирующего множество одновременных посещений ресурса на протяжении определённого времени. Если ваш сервер не защищён от повышенной нагрузки, он начнёт отвечать медленнее до тех пор, пока не сможет больше обрабатывать запросы. Если Memcached активирован, сервер продержится дольше и не будет выдавать ошибок.
Давайте запустим некоторые тесты на загрузку и производительность с помощью сервиса Blitz.io.
Отметим: для этого стресс-теста использован небольшой сервер с одним CPU и 500Мб памяти.
Стресс-тест без использования Memcached
Результат БЕЗ использования Memcached:
Результат такой же, как у стресс-теста Varnish. Как видите, пришлось прекратить стресс-тест, так как сервер не смог обрабатывать запросы быстрее 5 секунд при 50 одновременных подключённых пользователях. Всего лишь через 15 секунд сервер полностью перестал отвечать на запросы.
Стресс-тест WordPress и включённый Memcached
Как видите, Memcached позволяет сохранять стабильность работы сервера даже под высокой нагрузкой. Маленький тестовый сервер выдержал болше 400 одновременных запросов и дольше 50 секунд без каких-либо ошибок. После 50 секунд и почти 450 одновременных пользователей сервер всё-таки перестал принимать дальнейшие запросы. На более мощной конфигурации эти цифры были бы значительно выше.
Таким образом, использование Memcached - отличная идея для тех, кто хочет большей устойчивости к нагрузке. При помощи этой системы даже можно обезопасить сайт от небольших атак. Для защиты сервера от настоящей ДдоС-атаки (Distributed Denial of Service - атака на отказ в обслуживании) следует использовать сервис CloudFlare, Куратор или аналогичные системы фильтрации.
Заключение: WordPress отлично работает с Memcached Memcached может значительно улучшить производительность сайта на WordPress и снизить нагрузку на CPU вашего сервера. Он прост в установке и работает «из коробки».Перевод: Антон Ларгин (Русоникс)
Оригинал.
Приветствую всех читателей блога сайт. Рано или поздно перед каждым автором блога на WordPress возникает вопрос - Как снизить нагрузку на сервер? Кто-то задумывается об этом заблаговременно (обладая знаниями), а другие (новички) когда начинают приходить письма «счастья» от хостера. Становится ещё печальнее когда периодически начинает происходить отключение блога за превышение лимитов.
Со мной подобная история произошла в 2010 году. Посещаемость на моём первом блоге наконец-то появилась, медленно и уверенно подрастая. Радоваться долго не пришлось. Вскоре со мной произошло именно то, о чём я описал выше.
Все замечательно, все понравилось, кроме цены - 30 $. Тогда он стоил именно столько.
Миллионы с моего блога не капали, и я прошёл мимо, оставив использование варианта кеширования с MaxCache на потом. Решил же я свою проблему с повышенной нагрузкой на сервер по-другому. После очередного предложения поменять тарифный план, я поменял хостинг.
И вот настал день когда я впервые, вместо одного из вордпрессовских плагинов для кеширования, установил MaxCache. В 2013 году делая блог о спутниковом телевидении, я решил использовать для кеширования блога именно его.
Поюзал два дня бесплатную лайт-версию, укрепился во мнении, что иду правильным путём, и приобрёл платную Full-версию.
Теперь, когда я делаю кому-либо блог, или запуская что-то своё, не задумываясь, устанавливаю для кеширования блога MaxCache.
Как видите, и на этом блоге для снижения нагрузки на сервер стоит именно он. На сегодняшний день цена MaxCache составляет 10 $.
Алгоритм работы - как MaxCache снижает нагрузку на серверДля наглядности сделал скриншоты с футера главной страницы сайт создаваемой нагрузки на сервер до использования скрипта кеширования, и после подключения MaxCache.
Для тех, кто не знает как вывести информацию о нагрузке на сервер, количестве запросов, и время генерации страницы, подскажу. Делается все очень просто.
Открываете файл footer.php вашей темы, и вставляете следующий код перед закрывающимся тегом .
|
Нагрузка на сервер снизилась более чем в 14 раз!
Количество обращений к базе данных при использовании скрипта нулевое!
Скорость генерации страницы увеличилась в 2720 раз!
Цифры это хорошо, но даже и без них чисто визуально становится заметной более шустрая работа блога. Страницы открываются намного веселее.
По какому принципу работает скрипт кеширования? Пользователь, зашедший на ваш сайт, открыл интересующую его страницу, MaxCache тут же поместил её как статическую в папку Cache. Теперь она отдаётся пользователям именно из этой папки без запросов в базу данных, и без дополнительной нагрузки на сервер.
Кеш страниц сбрасывается каждые 4-е часа. При желании можно указать собственные настройки.
В комплекте со скриптом идёт плагин, который при активации позволяет нам когда мы залогинены, и работаем в админ панели блога просматривать не кешированные актуальные версии страниц. Для посетителей в это время, как и положено скрипт выдаёт их из кеша.
Имеется возможность включения gzip-сжатие трафика. Увеличивает скорость загрузки «тяжёлых» страниц. Включение gzip-сжатия даёт дополнительную нагрузку на сервер. Включать или нет эту функцию нужно принимать решение исходя из наличия лимитов по нагрузке CPU. Перед включением gzip-сжатия нужно уточнить у хостера поддерживается ли эта функция сервером.
Я на страницах при написании статей часто использую картинки и скриншоты. Хотя и сжимаю их по максимуму, вес выходит не всегда такой какой бы хотелось. У меня gzip-сжатие включено.
Результаты для главной страницы получились следующие.
До сжатия вес моей страницы был 23,7 KB, после компрессии 6,5 KB. Экономия составила 72,4%. Как говорится - Без комментариев. Сервис проверки работы gzip-сжатия находится по этому адресу - http://www.whatsmyip.org/http_compression/ .
Также в отдельном файле в настройках скрипта можно задать список страниц с запретом на кеширование. При выходе новой версии скрипта, обновление для всех клиентов бесплатное.
В завершение статьи, хотелось бы подчеркнуть, что мне нравится подход автора скрипта к его продажам. После оплаты MaxCache покупатель получает Lite -версию скрипта. Эта версия с ограниченным функционалом. Отличается она от Full-версии, тем, что кеш не сбрасывается на автомате. То есть урезанная версия работает, практически так же, как и полная. На тестирование автор выделяет две недели времени. Далее, вы или отказываетесь от приобретения, и автор возвращает вам деньги либо отправляете заявку на получение full-версии MaxCache.
Я при покупке этого девайса для снижения нагрузки на сервер попросил выслать мне сразу полную версию, так как давно уже знаком с работой скрипта и доволен его работой. Для блога на WordPress MaxCache идеальное решение.
Вконтакте
Здравствуйте, уважаемые читатели блога сайт. C Наступившими Вас праздниками!
В этот промежуток времени (где-то около получаса) админка выдает 502 ошибку, а для посетителей сайт хоть и доступен, но страницы открываются довольно медленно (от 5 до 15 секунд). Если бы кеширование на блоге не использовалось, то и они бы выдавали 502 ошибку. Помогает только либо двукратная перезагрузка сервера, либо тупое ожидание пока все само собой рассосется.
Кроме этого, в моменты высокой нагрузки не работает поиск по сайту и не отправляются комментарии, но это мелочи. В целом ситуация, как вы понимаете, неприятная, хотя и не сказать чтобы критичная. Вроде и терпимо, а раздражает — жуть.
В общем, за WordPress нужен глаз да глаз. Да, движок бесплатный, при этом профессиональный и попросту чумовой, но излишества всякие нехорошие нет-нет да и проскакивают. Вот. В этот раз взгляд тоже зацепился за «что-то новенькое». Это были три строчки кода (а точнее три служебных гиперссылки) опять же в шапке страницы формируемой WordPress:
Немного погуглив я понял, что «это» появилось в WordPress 4.4 и нужно для чего-то (пока смутно представляю для чего — если в курсе, то поясните). Т.к. «это» появилось недавно, то особо много рецептов удаления нагуглить не удалось, а то, что нашлось, работало как-то кривенько (первая ссылка удалялась, но две другие нет, и вести они стали на ту же страницу, код которой был открыт).
В общем, сие пока решил отложить до прояснения ситуации и появления рецептов «купирования ненужных отростков». Да, опять же, если в теме, то расскажите, ибо сильно эти ссылки меня раздражают. Хотя бы для чего они нужны и не несут ли какого диструктива в продвижение блога. Но тут я пока отступил.
Помимо этого в исходном коде был еще и сильно бросающийся в глаза блок:
Помню, что он был и раньше. Помню, что я якобы знал раньше, откуда он взялся, но сейчас сколько ни пытался, никак не мог вспомнить или даже зацепиться за то, откуда это «красота» появилась в шапке блога (на других блогах он тоже присутствовал). Немного мысленно побуксовал я уперся взглядом в слово emoji в коде. Недавно писал . Чуток погуглил и убедился, что таки да — этот код помогает отображать на страницах WordPress эти самые эмодзи смайлики .
Так как emoji смайлы у меня выводятся от силы в двух-трех статьях, то решил это безобразие убрать, для чего и был произведен поиск рецепта в сети. Решение, как всегда в таких случаях, состояло в добавлении фильтров из папки с используемой вами темой оформления WordPress. В общем, находим в нем место окончания какой-нибудь функции (точку с запятой) и туда добавляем несколько строк непонятного (мне), но вполне себе работающего кода:
Remove_action("wp_head", "print_emoji_detection_script", 7); remove_action("admin_print_scripts", "print_emoji_detection_script"); remove_action("wp_print_styles", "print_emoji_styles"); remove_action("admin_print_styles", "print_emoji_styles"); remove_filter("the_content_feed", "wp_staticize_emoji"); remove_filter("comment_text_rss", "wp_staticize_emoji"); remove_filter("wp_mail", "wp_staticize_emoji_for_email");
Это вариант самого полного отключения поддержки эмодзи в WordPress . Хотите в админке оставьте . Все, после этого наступило приятное чувство чистоты кода от всяко разного.
На тех страницах, где я эмодзи все же использовал, пришлось чуток подправить текст. Я просто открыл эти статьи на редактирование в админке и прямо в самом начале (в Html редакторе, а не в визуальном) добавил этот самый код, который удалил из шапки всех страниц:
window._wpemojiSettings = {"baseUrl":"http:\/\/s.w.org\/images\/core\/emoji\/72x72\/","ext":"..min.js?ver=4.4"}}; !function(a,b,c){function d(a){var c=b.createElement("canvas"),d=c.getContext&&c.getContext("2d");return d&&d.fillText?(d.textBaseline="top",d.font="600 32px Arial","flag"===a?(d.fillText(String.fromCharCode(55356,56806,55356,56826),0,0),c.toDataURL().length>3e3):("simple"===a?d.fillText(String.fromCharCode(55357,56835),0,0):d.fillText(String.fromCharCode(55356,57135),0,0),0!==d.getImageData(16,16,1,1).data)):!1}function e(a){var c=b.createElement("script");c.src=a,c.type="text/javascript",b.getElementsByTagName("head").appendChild(c)}var f,g;c.supports={simple:d("simple"),flag:d("flag"),unicode8:d("unicode8")},c.DOMReady=!1,c.readyCallback=function(){c.DOMReady=!0},c.supports.simple&&c.supports.flag&&c.supports.unicode8||(g=function(){c.readyCallback()},b.addEventListener?(b.addEventListener("DOMContentLoaded",g,!1),a.addEventListener("load",g,!1)):(a.attachEvent("onload",g),b.attachEvent("onreadystatechange",function(){"complete"===b.readyState&&c.readyCallback()})),f=c.source||{},f.concatemoji?e(f.concatemoji):f.wpemoji&&f.twemoji&&(e(f.twemoji),e(f.wpemoji)))}(window,document,window._wpemojiSettings); img.wp-smiley, img.emoji { display: inline !important; border: none !important; box-shadow: none !important; height: 1em !important; width: 1em !important; margin: 0 .07em !important; vertical-align: -0.1em !important; background: none !important; padding: 0 !important; }
Все, получил удовлетворение хотя бы от частичного решения проблемы с чистотой исходного кода и продолжил заниматься рутиной (написанием статей и прочей ерундой).
Как пришло осознаниеОднако, на следующий день закралось сомнение — что-то давно багов не было. Вроде уже долго с сайтом работаю, а 502 в админке не возникает. Верить в чудо было не с руки, ибо уже раз десять начинал праздновать победу, а очередной зависон возвращал меня на землю.
Однако, подождав еще немного по ходу вспомнил, что при поиске решения по удалению поддержки эмодзи запомнилось, что этот код появился в WordPress начиная с версии 4.2, а ведь она вышла как раз весной, когда у меня и начались траблы. Вполне вероятно, что именно это обновление WordPress до очередной версии и стало причиной появления бага с эпизодически высокой нагрузкой.
Во всяком случае по срокам и по тому, что проблема не проявляется после удаления кода поддержки эмодзи, можно было сделать определенные выводы. Я их сделал и написал этот пост. Если проблема вылезет опять, то чуть ниже появится P.S. с сожалениями по поводу напрасно потраченного времени (вами на чтение, а мною на написание).
Решение получилось действительно несуразным, по крайней мере глядя с моей, крайне невысокой в умственном плане, колокольни. Где логика? Не знаю, но все равно приятно, что пусть и случайно, но мучивший меня довольно долго технический казус более-менее удачно разрешился. За сим разрешите откланяться. Спасибо за внимание и еще раз с Наступившими праздниками.
Удачи вам! До скорых встреч на страницах блога сайт
посмотреть еще ролики можно перейдя на ");">
Вам может быть интересно
Пропало левое меню в админке WordPress после обновления
Где скачать WordPress - только с официального сайта wordpress.org
Установка WordPress в деталях и картинках, вход в админку WP и смена пароля
Пустая страница при просмотре больших постов (статей) в WordPress
Снижение потребляемой в WordPress памяти при создании страниц - плагин WPLANG Lite для подмены файла локализации
Как войти в админку WordPress, а так же поменять логин и пароль администратора выданные вам при установке движка
В этом месяце неожиданно нарисовалась очередная проблема с сайтом. Совсем недавно , а сейчас увеличилась нагрузка на сервер хостинга TimeWeb. Норма нагрузки была превышена в 10 раз.
Такой поворот событий для меня не был неожиданностью и возможную причину знал заранее. После запроса логов у хостера догадки подтвердились. Ко всем сайтам на аккаунте подбирались пароли к админке WordPress.
Вход в админку у меня был стандартный и дополнительно не был защищен. Подход банальный, если ничего не случилось, зачем что-то делать? Подход резко изменился, когда хостинг ТаймВеб за нестабильную работу сервера вынужден (он бы не прочь, но я его вынуждаю;)) приостановить обслуживание моего аккаунта.
Брутфорс – это и есть подбор пароля и логина путем перебора множества вариантов. В результате таких манипуляций растет количество запросов и увеличивается нагрузка.
Программ для взлома акканутов сейчас в сети полно и любой школьник по приложенной инструкции без особых проблем может почувствовать себя хакером. Для защиты админки в этом случае достаточно провести несложные действия.
Как уменьшить нагрузку на сервер с WordPress?Самые вкусные файлы для взломщиков wp-login.php и wp-config.php. Для уменьшения нагрузки на сервер им необходимо уделить особое внимание, а для защиты админки следует присмотреться к следующим способам.
Первый способ. Закрыть полный доступ к wp-login.php для всех IP адресов, кроме вашего. Для защиты достаточно внести изменения в файл.htaccess. То есть доступ к админке будет разрешен только вам, у остальных будет выкидываться ошибка.
Этот очень простой способ для меня не самый удобный. Дело в том, что при подключении к интернету мне дается новый IP и для входа в админку сайта требуется сначала зайти в админку хостинга, внести мой новый IP в.htaccess и только потом перейти на блог.
Второй способ. Спрятать файл wp-login.php. Этот способ оказался для меня идеальным.
1. Переименовываем название файла wp-login.php в, например, 45jkdsf234.php . Искать файл нужно в корне сайта, корректировать либо через админку хостинга либо через .
2. Заменяем все встречающиеся слова wp-login.php на переименованные, в моем примере на 45jkdsf234.php . Изменения нужно внести в старый файл wp-login.php , который сейчас называется 45jkdsf234.php и в wp-includes/general-template.php .
Теперь вход в админку будет осуществляться не по адресу ваш-сайт/wp-login.php , а по адресу ваш-сайт/45jkdsf234.php .
3. Добавить в.htaccess перед # END WordPress такой код:
В результате у меня получился такой.htaccess:
Третий способ . Использовать плагин Login LockDown, который предотвращает попытки подбора пароля. Установка плагина банальная, поставил и забыл. По умолчанию имеется 3 попытки войти в админку в течение 5 минут, при неудачных попытках происходит блокировка по IP на 1 час.
Мне очень не хотелось ставить Login LockDown, обычно я подбираю пароль к админке раза с 5-го. Но что сделаешь, придется тренировать память, лучше так, чем постоянные взломы.
Вот так выглядит график нагрузки до и после подбора пароля:
Период взлома отчетливо виден по резким скачкам графика.
Что не помешает сделать вебмастеру для снижения нагрузки WordPress на серверПо максимуму обезопасить админку позволит следование базовым правилам по соблюдению безопасности:
- На админку стоит поставить сложный пароль;
- Поменять логин admin на другое название;
- В FTP-клиентах не хранить пароли и логины;
- Регулярно делать back up файлов вордпресс и базы данных mysql. Про создание автоматической резервной копии базы .
Если после проведения всех работ нагрузка на сервер остается по-прежнему повышенной и не связана со взломом, значит нужно оптимизировать код веб-проекта или искать вредоносный скрипт.
В следующий раз расскажу о сказочном способе максимального ускорения загрузки блога, так что подписывайтесь на обновления в форме ниже под статьей и получите всё сладкое самыми первыми.
На самое сладкое видео с заманчивым названием.
Давайте наверное уже начнем оптимизировать Поехали!
Пример излишней нагрузки на сервер.Допустим пользователь зашел на сайт, но что происходит при открытии страницы? Как информация выводится на экран? Давайте проследим сей процесс на примере заголовка сайта.
Заголовок и URL главной страницы сайта, если Вы помните, задается в настройках WordPress: адимнка -> Параметры -> Общие. Все настройки, имеющиеся во вкладке «Параметры», заносятся в базу данных, а точнее, в таблицу wp-options , откуда в последствии они запрашиваются различными функциями и выводятся на экран.
Разработчиками WordPres написано не мало функций, но сами по себе они выполняться не могут. Для полноценной их работы необходимо некое связующее звено, в роли которого выступает шаблон сайта.
Шаблон, как известно, состоит из ряда файлов, каждый из которых отвечает за отображение определенного участка сайта. Нас же сейчас интересует шапка, где выводиться заголовок, поэтому откроем файл header.php и поглядим, что там прописано.
В большинстве шаблонов, главный заголовок сайта заключен в тег h1 , поэтому ищем участок кода с данным тегом. В моем шаблоне код вывода заголовка выглядел так:
А теперь, самое интересно. Если заглянуть в исходный код, то код заголовка там примет совершенно другой вид:
Вот такой код заголовка и должен быть прописан в файле header.php. Тогда сервер избавиться от двух совершенно лишних обращений, умноженных на количество открытых страниц.
Но тогда зачем в файлах шаблона прописываются вышеупомянутые функции?
Дело в том, что разработчики не могут знать, на каком домене в последствии будет использоваться сверстанные ими шаблоны и какие названия будет у сайтов они тоже знать не могут. Поэтому и были разработаны универсальные функции для всех шаблонов, которые получают данные из БД.
Но мы то с вами знаем, как называется наш сайт и домен нам тоже известен. Выходит так, что использовать данные функции нет никакой необходимости.
Поэтому, начиная с файл header.php ищем участки кода, с вышеупомянутыми функциями, затем смотрим, как они выглядят в исходном коде и заменяем.
Для закрепления материала я приведу несколько примеров. Вот код, который выводит информацию о кодировке.
