Сайт о телевидении

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

На рисунке ниже показана схема относительно несложного автомата, который может включать последовательно до 10-ти нагрузок (или групп нагрузок, например, до 10 учебных классов, оборудованных персональными компьютерами или телевизорами, другими приборами со значительными пусковыми токами). Схема использует принцип работы десятичного счетчика, управляющего триггерными схемами, способными сохранять свое состояние. В качестве триггерных схем и выходных узлов используются электромагнитные реле с двумя замыкающими группами контактов. При этом одна группа служит для самоблокировки реле, а вторая для включения нагрузки. Включение и выключение производится одним выключателем, подключающим схему к сети. Включение происходит последовательно, а выключение всех нагрузок одновременно.

Для включения нужно включить выключатель S1. Напряжение от электросети, при этом, поступает на трансформатор Т1 и почти одновременно, на первую нагрузку. Происходит это, потому что при подаче питания счетчик D2 устанавливается в нулевое положение цепочкой С2-R2, которая подает импульс на вход R счетчика. При этом на нулевом выходе счетчика устанавливается логическая единица (вывод 3), которая поступает на базу VT2 и открывает его. Через транзистор поступает ток на обмотку реле К1. Реле замыкает свои контакты и одновременно одной парой подключает нагрузку Н1 к сети, а второй парой замыкает участок коллектор-эмиттер транзистора VT2. Теперь даже если опустить напряжение на базе VT2 до нуля реле не выключится, потому что его обмотка будет питаться через его же собственные замкнутые контакты. После зарядки конденсатора С2 счетчик D2 начинает считать импульсы, которые вырабатывает мультивибратор на элементах D1.1 и D1.2. Частота импульсов установлена цепью R1-C1 и при указанных на схеме параметрах составляет около 0,05 Гц, что соответствует 20 секундам. Поэтому состояние счетчика будет меняться через каждые 20 секунд. В реальной конструкции это время может существенно отличаться и быть нестабильным, так как параметры RC-цепи имеют разброс и могут изменяться под действием температуры. Далее, единица последовательно будет через каждые 20 секунд появляться на выходах счетчика и через 3 минуты процесс последовательного включения нагрузок завершится.

Каких-то мер, останавливающих счетчик после включения всех нагрузок нет. Так как в нем нет смысла. Пусть счетчик продолжает работать по-кольцу. Выключаются все нагрузки одновременно, - когда выключается питание схемы выключателем S1. Источник питания на силовом трансформаторе Т1 с переменным напряжением на вторичной обмотке 8,5V. На С5 после выпрямления получается около 11V. Здесь используются реле типа HJQ-13F с обмоткой на 12V и двумя группами контактов. Эти реле, да как и практически все рассчитанные на 12V, уверенно срабатывают уже при напряжении 8V на обмотке. Поэтому при 11V и даже при 9,5V, до которых «проседает» напряжение на выходе выпрямителя, когда все реле включены, схема работает надежно. Однако желательно использовать трансформатор со вторичной обмоткой на напряжение немного выше, так чтобы на выходе выпрямителя под полной нагрузкой было не ниже 11V. В то же время, и выше 15V на холостом ходу не надо, - все же обмотки реле на 12V рассчитаны.

Микросхемы питаются стабилизированным напряжением 6,5V от параметрического стабилизатора на транзисторе VT1 и стабилитроне VD2. В этом месте схемы можно бы использовать интегральный стабилизатор типа 78L06 или 78L08, но у автора данной микросхемы не оказалось, поэтому стабилизатор сделан на транзисторе. Вообще, такую схему стабилизатора можно применять и при ремонте аппаратуры, когда нет интегрального стабилизатора на нужное напряжение для замены. Трансформатор питания - готовый от универсального сетевого адаптера с выходными напряжениями 3V, 4,5V, 9V, 12V (на самом деле 11V). Используется вся вторичная обмотка (отводы не используются, потому и на схеме не показаны). Реле можно заменить любыми другими с обмотками на 12V и контактами на необходимую мощность нагрузки. С этими реле мощность каждой нагрузки может быть до 3000W. Если нагрузки не мощнее 200W можно использовать реле типа КУЦ от старых телевизоров (у них как раз две замыкающие контактные группы). Микросхему D1 можно заменить любой КМОП микросхемой, у которой есть не менее двух инверторов. Скорость включения можно изменить как в сторону увеличения, так и уменьшения подобрав параметры С1 и R1.

В этой статье я хочу рассказать о способах оптимизации блога WordPress для снижения его нагрузки на сервер . Рано или поздно всем приходится задумываться над этой проблемой. Так как движок WordPress основан на PHP и MySQL, то каждый раз при каждом обращении к страницам сайта он создает определенную нагрузку на сервер. И чем больше этих обращений, тем больше нагрузка. Так как большинство из нас использует обычный хостинг, то всем приходится подчиняться определенным правилам, одним из которых есть ограничение нагрузки на сервер. Исходя из этого, есть смысл оптимизации своего блога WordPress.

Итак, для начала давайте разберем принцип работы движка на основе PHP+MySQL.
Когда пользователь обращается к какой-то странице сайта, на сервере (при помощи специального серверного языка или просто PHP) идет обращение к так называемой базе данных, которая содержит в себе всю информацию. Затем нужная информация вытаскивается и формируется статическая HTML страница.

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

Оптимизация блога WordPress при помощи кэширования страниц. Плагин Hyper Cache и его настройка.

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

Итак, первым делом нам нужно скачать и установить плагин Hyper Cache. Для этого переходим на официальный сайт WordPress и скачиваем последнюю версию плагина. Далее копируем файлы в папку \wp-content\plugins\ и активируем плагин через административную панель. Для этого переходим в административную панель — плагины и активируем Hyper Cache.

После установки и активации плагина, переходим к его настройке. Точнее для начала нам нужно активировать кэширование в самом WordPress. Для этого нам придется редактировать файл wp-config.php и вставить в него строку

Define("WP_CACHE", true);

Лучше это делать ближе к концу файла, но не дальше строк

If (!defined("ABSPATH")) define("ABSPATH", dirname(__FILE__) . "/");

Затем нам необходимо соединиться с сервером и выставить права доступа 777 для папки wp-content. В принципе можете поставить эти права на саму папку с КЭШем. После этого переходим в административную панель\параметры\Hyper Cache и активируем его. Затем переходим к самим настройкам кэширования.

• Время жизни кэшированных страниц – устанавливаете время, которое будет существовать страница в КЭШе. То есть после обращения к статье WordPress кэширует эту страницу и сохраняет ее. От значения, которое вы здесь установите, будет зависеть время существования этой страницы, до ее удаления или обновления. Можете ставить по своему усмотрению. Обычно чем дольше, тем лучше.
• Автоочистка – данная функция проводит проверку КЭШа на наличие записей с истекшим сроком. Если такие находятся, то они удаляются. Благодаря этому вы можете быть спокойны, что у вас не будет накапливаться мусор, который может весить довольно много, что в свою очередь приведет к уменьшению свободного пространства на диске. Значение можете подбирать индивидуально. Вполне подойдет 1440 минут.
• Как очищать кэш – ставим значение «Single pages». На мой взгляд, это оптимальный вариант. В этом случае при внесении изменений кэш будет обновляться только для тех страниц, которые были редактированы. Остальные же останутся нетронутыми. При большой посещаемости это имеет смысл, так как если бы каждый раз, когда вы редактировали статью, очищался бы весь кэш, то это бы создало огромную нагрузку на сервер.
• Не кэшировать домашнюю страницу – можете поставить галочку, если не хотите, чтобы сохранялась главная страница. Данная опция имеет смысл, если у вас очень часто обновляется главная страница вашего блога. В принципе ставим по желанию. Лично у меня эта опция включена.
• Исключить URI – сюда можно вписать адреса страниц, которые вы хотите исключить с КЭШа.

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

Если она есть, то плагин работает нормально.

Снижение нагрузки на сервер за счет кэширования запросов к базе данных.

Для этого можно использовать специальный плагин DB Cache Reloaded . Он кэширует запросы и направляет их не в базу данных, а в кэш, доступ к которому более быстрый. За счет этого уменьшается нагрузка на сервер и увеличивается скорость генерации страниц, что, в свою очередь, увеличивает скорость загрузки самого блога.

Настройки этого плагина очень просты и приводиться не будут. Там все интуитивно понятно. Единственное, что могу предложить, это добавить в footer.php код, который будет выводить информацию о количестве запросов к базе и время загрузки страницы.

Для этого открываем на редактирование файл footer.php и где-то в конце добавляем код

queries in seconds.

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

Естественно можно поиграть со стилями, перевести «queries in» и «seconds», но это по желанию. Лично меня и так все устраивает.

Оптимизация шаблона WordPress

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

Оптимизация header.php

1. Находим код

и меняем его на название своего блога. У меня это

Сайт - создание и продвижение сайтов, блогов, заработок на сайте.

2. Код, отвечающий за вывод описания, заменяем на статический.

3. Строка, отвечающая за вывод кодировки.

; charset=" />

Поскольку мы знаем, что кодировка WordPress UTF8, то можем видоизменить данный код и сделать его таким:

4. Удаляем строку, которая отвечает за вывод информации о вашей версии WordPress.

" />

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

5. Заменяем путь к таблице стилей вашего шаблона на статичный.

" type="text/css" media="screen" />

После модификации будет иметь примерно такой вид:

6. Меняем путь к RSS ленте на статический.

RSS Feed" href="" />

После изменения будет выглядеть вот так:

7. Также можно изменить путь до Pingback (рассылка, которая отправляет сведенья по всем адресам, упомянутым в этой заметке).

" />

Заменяем на

Оптимизация файла footer.php

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

заменяем на свой текст. У меня это

• «Оптимизация WordPress за счет уменьшения количества обращений к данным »

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

На этом все. Удачи вам и успехов в оптимизации сайтов.

Сейчас я расскажу как мне наконец-то удалось снизить CPU нагрузку от моих сайтов wordpress на хостинге. Длилась эта история 3 месяца. Показатель CPU в моём аккаунте был итак на пределе и вдруг начал совсем зашкаливать.

Сколько я прочитала статей в интернете, и сколько облазила форумов — сама точно не знаю. Что я сделала за это время на своих сайтах.

• Минимизировала количество плагинов. Особенно надо обратить внимание на тяжёлые плагины со сложными скриптами. Обнаружить таких обжор вы можете при помощи плагина P3 (Plugin Performance Profiler)
• Уменьшила вес картинок. Количество тоже желательно уменьшить, но как без скриншотов, ведь будет сложно понять о чём идёт речь
• Поставила плагин кеширования — Hyper Cache
• Уменьшила нагрузку, которую создают поисковые боты

Но только моим сайтам это не помогало, как слону дробина. Проклятое CPU уже показывало более 40-50 единиц, хотя на моём тарифе допускалось – 30. Мой хостер — webhost1 , меня не беспокоил. Но зато психовала я, тем более, что в один прекрасный день мои сайты автоматически отключились – правда длилось это несколько минут. И пришлось перейти на более дорогой тариф.

А CPU на хостинге стало зашкаливать в некоторые дни даже за 50. Переходить на другой хостинг? Возня неимоверная, тем более что на Вебхосте я уже более 3-х лет. И где гарантия, что там история не повторится или не будет ещё хуже. Оставалось только закрывать сайты или платить нереальную (неокупаемую) цену. Но делать этого не хотелось и пошла я бродить по своей хостинг панели.

И о чудо, метод научного тыка как всегда помог! Зашла я в домены и сравнила PHP сайтов старых и новых. Оказалось, что старые сайты работали на устаревшей версии PHP5.3, а новые на PHP5.6!!! Переключила я своих «старичков» на PHP5.6 и уже третий месяц сплю спокойно. CPU нагрузка на хостинг — стабилизировалась.

Если у вас CPU зашкаливает, а ответа вы так и не нашли, то проверяйте на какой версии PHP работает ваш сайт. На моём хостинге для этого нужно зайти в хостинг-панели в раздел Домены. Далее нажать Настройки

В Настройках найти PHP, выбрать версию 5.6 нажатием на треугольник. И сохранить. После этого нагрузка на CPU должна снизиться. Только не выбирайте версию 7.0 , иначе у вас могут исчезнуть картинки и тема сайта.

• Не забывайте чистить базу данных каждую неделю. Плагинами: и .
• Загружать новые обновлённые версии плагинов и движка Вордпресс. Особенно если у вас не отключены обновления – этого, кстати, делать и не рекомендуется, хотя в сети встречаются статьи с советами отключать обновления. Якобы этот способ сильно снижает нагрузки – снижает, но не более чем на 3-5 единиц! А вот сайты свои вы подвергаете опасности быть взломанными, так как в каждой новой версии движка или плагинов закрываются уязвимости. Поэтому заходите хотя бы раз в неделю на свои сайты и принимайте обновления.

Рада, если смогла вам помочь и перед вами больше не стоит вопрос Как снизить нагрузку на CPU хостинга.

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

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

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

Для начала вам нужно будет получить доступ по FTP к файлам вашей темы оформления. Они находятся в папке:

/wp-content/themes/название_вашей_темы_оформления

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

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

; charset=" />

Нет, удалять его, конечно же, не надо, но вот немного видоизменить, убрав не нужные обращения к БД, можно:

Ну вот, два запроса в минус — пустячок, а приятно. Дальше — больше. Что еще можно заменить или удалить в HEADER? Давайте перечислим:

1. Удалить строку с информацией о номере установленной версии WordPress . Она не несет никакой полезной нагрузки и, более того, является опасной, т.к. некоторые варианты взлома применимы только к определенным версиям, а из этой строки как раз очень удобно узнавать текущую версию вашего движка. Выглядит эта строка обычно так: " />
2. Заменить URL до вашего файла таблицы стилей CSS в вашей текущей теме оформления на статический. В коде это строка: " type="text/css" media="screen" />

WP Tuner устанавливается на WordPress стандартным способом, а именно:

1. распакуйте архив, используя ftp-менеджер подключитесь к вашему блогу и загрузите папку wptuner в папку с плагинами wp-content/plugins/ на сервере хостинга
2. войдите в админку и выберете вкладку «Плагины»- «Inactive»
3. найдите строку с плагином WP Tuner и активируйте его

Если при установке плагина WP Tuner у вас возникли какие-либо затруднения, то можете обратиться к материалам статьи, про решение возможных проблем с установкой плагинов. Теперь можно зайти в админку и ознакомиться с настройками этого расширения (из левого меню выбрать Параметры -> WP Tuner.

Собственно, настроек у WP Tuner не так уж и много, к тому же для того, чтобы данный плагин начал показывать количество запросов к БД при загрузке страницы, вообще ничего менять не надо. Нужно просто зайти на блог, но при этом нужно, чтобы вы были под логином администратора, и открыть какую-либо страницу.

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



Обычные посетители блога, естественно, этого безобразия, внесенного WP Tuner, видеть не будут, только администратор, т.е. вы.

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

/wp-content/themes/название_вашей_темы_оформления/footer.php

и где-нибудь в его содержимое нужно вставить следующую конструкцию (место вставки будет определять область вывода числа запросов к БД в футере):

queries in seconds.

В результате после загрузки страницы, в самом низу (в области подвала), вы увидите, сколько при этом было сделано обращений к БД:

Удачи вам! До скорых встреч на страницах блога сайт

посмотреть еще ролики можно перейдя на

");">


Вам может быть интересно

Пропало левое меню в админке WordPress после обновления
Создаем для блога на WordPress кнопки добавления в социальные сети и закладки (без плагинов и скриптов)
Снижение потребляемой в WordPress памяти при создании страниц - плагин WPLANG Lite для подмены файла локализации Смайлики в WordPress - какие коды смайлов вставлять, а так же плагин Qip Smiles (красивые смайлики для комментариев) Как автоматически добавить атрибут Alt в теги Img вашего блога на WordPress (там, где их нет)
Hyper Cache - включаем плагин кэширования в Вордпресс для оптимизации WP блога и снижения его нагрузки на сервер хостинга

Если вы получили уведомление о превышении лимита на использование CPU, это означает, что потребление ресурсов процессора вашим аккаунтом превысило суточную норму , установленную тарифным планом.

В письме от провайдера, как правило, сообщаются:

• пункт Договора/Правил, который был нарушен;
• суть нарушения;
• текущее состояние аккаунта;
• предлагаемые меры, которые клиенту необходимо выполнить для возобновления предоставления услуги.

Выявляем причину повышения нагрузки на хостинг

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

1. Нагрузка на CPU из-за неоптимальной работы скриптов или неоптимизированной базы данных

Оптимизация CMS: Отключите неиспользуемые и тяжелые плагины CMS, настройте кэширование посредством CMS (для WordPress например можно использовать WP Super Cache или WP-cache.com).

Оптимизация базы данных: Запросы к MySQL, которые выполняются более 0,5 секунд, часто создают избыточную нагрузку на дисковую систему сервера и на его процессор. Проверьте логи медленных запросов к БД (можно запросить у хостера) и выполните оптимизацию структуры БД, а также почистите её от неактуальной информации.

2. Избыточное число запросов к сайту

Повышение нагрузки на CPU может быть свидетельством большого количества запросов от поисковых и иных роботов, или, особенно при скачкообразном резком росте - свидетельством DDOS-атаки или Brute-Force атаки.

Проверка источников запросов: откройте лог-файл со статистикой запросов по User-Agent - из него вы сможете понять, какие роботы с какой периодичностью обращаются к вашему сайту (например YandexBot, bingbot). В логах со статистикой по IP-адресам проверьте, не идёт ли с каких-либо IP огромный поток обращений (если да, то возможно это атака на сайт). Узнать больше информации про IP (кому он принадлежит) можно при помощи сервисов Whois.

Настройка ограничения для роботов : Настройте файл robots.txt: установите таймаут обращения роботов к вашему сайту при помощи директивы Crawl-delay:

Для отдельного бота:

User-agent: bingbot Crawl-delay: 10 # задает таймаут в 10 секунд только для бота bingbot

Или сразу для всех ботов:

User-agent: * Crawl-delay: 10 # задает таймаут в 10 секунд для всех поисковых роботов

Настройка ограничений по IP-адресам: Для блокировки доступа по IP добавьте в файл.htaccess, находящийся в корневой папке сайта, следующие строки (в примере ниже блокируем доступ к сайту для IP-адресов 121.123.123.123 и 121.122.122.122):

Order Allow,Deny Allow from all Deny from 121.123.123.123 Deny from 121.122.122.122

3. Реальное увеличение посещаемости ресурса

С развитием сайта посещаемость его растёт, и чем выше посещаемость, тем больше нагрузка на CPU. В случае перехода порога посещаемости в 10000 уникальных посетителей в сутки на обычном виртуальном хостинге сайту будет однозначно тесно и необходимо переносить его на выделенный сервер.

4. Слабый хостинг

Довольно часто уже при количестве посетителей более 1000 у пользователя возникают проблемы с превышением нагрузки на хостинг. При этом оптимизация сайта и ограничения для роботов не дают особого эффекта и с хостинга продолжают приходить уведомления о превышении нагрузки. Скорее всего, ваш сайт превзошёл возможности оборудования провайдера - в этом случае лучше сразу сменить хостинг на более качественный. Мы уже сталкивались с подобной проблемой на хостинге reg.ru и других, и после перехода на новый качественный хостинг , и проблема исчезла.

После проведенного анализа рынка услуг виртуального хостинга был найден наиболее оптимальный вариант по соотношению Цена/Качество. Рекомендуем бесплатно попробовать этот хостинг , и перейти на него (при заказе введите промо-код сайт и получите скидку 10% на услуги хостинга ).