Tag Archives: оптимизация веб

Защита файла wp-config.php в nginx

Автор: Рудюк С . А.
https://corp2.net

E-Mail: rs@corp2.net

В файле wp-config.php CMS WordPress хранит пароли и логины для доступа к базе данных. Это очень безопасная информация. Есть вероятность, что в момент отладки приложения или веб-сервера данный файл может быть доступен злоумышленникам, поэтому, рекомендуется защищать данный файл от доступа в веб-серверах.

Защита в веб-сервере Apache указывается в файле .htaccess:

Защита в веб-сервере Nginx:

Автор: Рудюк С . А. https://corp2.net

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

3D визуализация и дизайн

Безопасность WordPress. 3 самых эффективных способа защиты от брутфорса

По статистике, около 19% от общего количества всех сайтов Интернета, работают на WordPress — это почти каждый пятый сайт. Успех платформы вполне логичен и закономерен, не зря еще 5 лет назад я сделал ставку именно на нее. Но сегодня речь пойдет не о преимуществах WordPress, а о его безопасности. Высокая популярность платформы активизировала злые силы, и вот уже на протяжении нескольких месяцев в Рунете идут массовые атаки на сайты, работающие на WordPress. Атаки настолько серьезные и настолько массовые, что не выдерживают даже самые мощные серверы. Хостинг-провайдеры, конечно, принимают меры, порой даже самые радикальные, вплоть до полной блокировки администраторских консолей WordPress. Поэтому, если вас еще не заблокировали, лучше самостоятельно провести ряд несложный действий по укреплению обороны вашего WordPress.

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

1. Первое с чего нужно начать — это избавиться от пользователя admin. Если у вас нет пользователя admin, можете сразу переходить к пункту 2. В WordPress начиная с 3 версии это делается очень просто. Достаточно создать нового пользователя, наделить его администраторскими правами, а старого пользователя «admin» — удалить. При его удалении, WordPress предложит вам выбрать нового пользователя, который станет автором публикаций старого администратора.

В старых версиях WordPress эта процедура проделывается с помощью пары SQL-запросов:

2. Очень важно обратить внимание на пароль администратора. Лучше если это будет хаотичная комбинация заглавных и строчных букв, знаков и цифр не менее чем из 10-12 символов.

3. При бутфорсе WordPress, производится огромное количество запросов к файлу авторизации «wp-login.php», и будет правильно обеспечить ему двойную защиту.

Если вы работаете с сайтом один, и ваш интернет-провайдер предоставляет вам статичный IP-адрес, вы можете разрешить доступ к директории «wp-admin» только с вашего IP-адреса, заблокировав тем самым для всех остальных даже возможность авторизации. Делается это следующим образом. В директории «wp-admin» создаем файл «.htaccess» следующего содержания:

Где IP — это ваш IP-адрес. Узнать его вы можете, например, здесь.

Если же, кроме вас с сайтом работают еще люди со статическими IP-адресами, вы можете просто добавить их в список ниже. Например, так:

Где, IP1, IP2, IP3 — разрешенные IP-адреса.

Благодаря этому, все пользователи (боты) с IP-адресами, не указанными в списке разрешенных, просто не получат доступа к директории «wp-admin» и, соответственно, не смогут брутфорсить файл «wp-login.php». Всем им будет возвращаться ошибка 403.

Если провайдер вам выдает динамический IP-адрес, меняющийся с каждым новым подключением к Интернету, тогда этот способ не пройдет, т.к «.htaccess» придется редактировать при каждом вашем подключении к Сети. С помощью все того же «.htaccess» мы можем установить дополнительную серверную HTTP-авторизацию. Делается это следующим образом.

Все в той же директории «wp-admin» создаются два файла: «.htaccess» и «.htpasswd». В первом будут храниться инструкции, во втором разрешенные данные для доступа к директории.

В «.htaccess» пишем следующее:

Где fullpath — полный путь к файлу «.htpasswd». Обратите на это должное внимание, т.к это самая частая ошибка. Полный путь вы можете узнать у своего хостинг-провайдера или с помощью небольшого php-скрипта:

Или другим способом:

Если вы по каким-то причинам не хотите паролить всю директорию «wp-admin», вы можете запаролить непосредственно файл «wp-login.php». Делается это аналогично, но в «.htaccess» нужно написать следующее:

Файл «.htpasswd» в обоих случаях должен выглядеть следующим образом:

Где username — это имя разрешенного пользователя, а password — это пароль. Обратите внимание, что пароль хранится в зашифрованном виде. Поэтому, предварительно ваш пароль нужно зашифровать. Сделать это можно, например, с помощью этого сервиса. На пароль действуют те же правила, что указаны в пункте 2 данной публикации.

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

Если вы сделаете все правильно, перед авторизацией в WordPress вам будет предложено ввести логин и пароль доступа к директории (файлу). И только после успешного входа вы сможете авторизоваться и войти в администраторскую консоль.

В Safari 6.0.5 на Mac OS это выглядит примерно так:

htpasswd

В других браузерах возможно немного иначе.

Выполнив хотя бы эти 3 пункта, вы в разы снизите вероятность взлома вашего WordPress.

Дополнительные меры по защите WordPress

Дополнительно вы можете защитить таким же образом файл настроек WordPress «wp-config.php». Я бы рекомендовал его защитить, потому что в нем содержатся данные для подключения к БД MySQL. Делается это аналогично:

Также, я бы рекомендовал вам проверить директории вашего сайта. Дело в том, что очень многие хостеры и безалаберные сисадмины не закрывают по-дефолту просмотр директорий сайтов своих клиентов. Если, к примеру, ввести в адресную строку браузера: http://вашсайт/wp-includes/ и вы увидете содержимое этой директории — нужно бить тревогу и срочно закрывать просмотр. Для этого можно создать в директориях, которые вы хотите закрыть от просмотра, пустые файлы «index.html» или дописать в ваш «.htaccess» всего одну строку:

Которая запретит серверу показывать содержимое директорий.

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

Их обзор в рамках данной публикации я проводить не буду.

Если в процессе настройки защиты WordPress от брутфорса у вас возникнут сложности — вы всегда можете обратиться ко мне за помощью. Контакты здесь.

Защита сайта от брутфорса без правки кода

Если Ваш сайт, написанный на базе популярного движка (WordPress, Joomla, Magento и др.), стал сильно тормозить, а в логах доступа сервера Вы видите множество обращений к странице логина или к странице администрирования, знайте — ваш сайт «нашли» боты-брутфорсеры и пытаются подобрать пароль администратора.Если с Вашим паролем всё нормально (он длинный и набран цифрами и буквами в разных регистрах), то Вы можете быть уверены, что брутфорсер его не подберёт. Но сам факт того, что происходит подбор, а тем паче то, что при этом страшно грузится сервер и расходуется трафик (особенно если на вашем хостинге он платный) откровенно говоря, напрягает.

Ниже я расскажу как избавиться от этой проблемки очень простым и бескровным способом.

Сперва предыстория. Проблемой я озаботился спустя некоторое время после того, как перешёл с «самодельного» движка на WordPress (впрочем, это мог бы быть любой другой более-менее распространённый движок). Запилил первый сайт и уже через неделю увидел в логах огромное количество запросов к странице логина. Поиски в интернете выводили на множество «рецептов», подавляющее большинство которых заключается в переименовании файла wp-login.php и его правке (поскольку адрес самой страницы неоднократно встречается в самом файле wp-login.php и других файлах движка.

Но этот способ означает правку ядра WordPress. А это влечёт за собой невозможность получать регулярные автоматические обновления ядра, а также несовместимость с некоторыми плагинами. К тому же способ абсолютно не спасает против тех роботов, которые ищут «дыры» в админке и плагинах, обращаясь с хитроумными параметрами по адресам вида /wp-admin/* В общем, этот способ сразу был отвергнут.

А идея моя заключается вот в чём.

Нужно завести специальную куку, такую, чтобы при её отсутствии сам сервер (Apache или Nginx) перехватывал обращения к странице логина или админке и выдавал вместо кода страниц код состояния 404, означающий полное отсутствие по этим адресам каких-либо страниц). А при наличии куки сервер должен просто обходить эту проверку и сайт должен работать как ни в чём не бывало. Брутфорсеры не тупые, они не будут бесконечно «долбать» отсутствующий URL и отступят.

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

Теперь дело за реализацией.

Я привожу кусок конфига для Nginx, поскольку я пользуюсь только этим сервером, но, зная идею, Вы самостоятельно можете написать конфигурацию для Apache или другого сервера.

Теперь файл PHP с секретным именем, который будет данную куку устанавливать:

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

Вот и всё. Просто, правда? Разумеется, этот рецепт может быть повторен абсолютно для любого движка, Вам нужно будет только поменять пути и названия файлов.

Что-то непонятно? Спросите в комментариях!


Источник: http://epsiloncool.ru/programmirovanie/php/zashhita-sajta-ot-brutforsa-bez-pravki-koda

Используем rel=nofollow и noindex для Yandex

no-follow-prev

В апреле, поисковик Yandex, обрадовал рунетовских веб-мастеров, включением поддержки атрибута rel=»nofollow» в ссылках. Какую пользу это нам — блоггерам принесет? Как правильно прописать атрибут rel=»nofollow» в ссылках и что теперь будет с <noindex>?

Давайте попробуем разобраться в этих новинках Яндекса .

Небольшая предыстория атрибута rel=nofollow

Что такое rel=nofollow?

Rel=» « — атрибут в ссылке <a>, указывающий отношение ссылки к целевой странице. Также, есть еще атрибут Rev=» «, указывающий отношение целевой страницы к ссылке, например (ссылка с rev=»sponsor» указывает, что это спонсорская ссылка). Но об этом в следующей статье.

Nofollow — статус, говорящий о том,что вы не одобряете данную ссылку.

Исходя из вышесказанного:

Rel=nofollow — определяет отношение вашей ссылки к целевой странице как не одобряемое. Применительно к поисковикам, данный атрибут указывает индексирующим роботам, что по данной ссылке не следует переходить на целевую страницу.

Rel=nofollow был введен и стандартизирован в 2005 году, в ответ на многочисленный ссылочный спам, присутствующий в блогах. Инициатором введения была поисковая система Google.

Google, встречая ссылку с данным атрибутом, не следует по данной ссылке и не передает вес PR целевым страницам. Также, данные ссылки не учитывались в расчетах распределения ссылочного веса по ссылкам страницы. Но, так было до 2010 года. На данный момент, Google, также не передает ссылочный вес и не следует по ссылкам с rel=»nofollow», но вот ссылочный вес, внутри страницы, стал распределятся и на эти ссылки но впустую. То есть, если у вашей страницы PR-10 и 10 ссылок на странице, где 5 из них закрыты, то каждая открытая ссылка передавала по 2PR на целевую страницу. Теперь каждая открытая ссылка будет передавать 1PR по открытым ссылкам и по 1PR в пустоту по закрытым. Но эта статья не о Google, вернемся к Яндексу.

Yandex, до апреля месяца 2010г., не учитывал данный статус. В рекомендациях Яндекса находим нашумевший тег <noindex>, который позволял сделать тоже самое и больше. Теперь там и nofollow.

В чем разница rel=nofollow и <noindex>

Так в чем же проблема?
Зачем Яндексу понадобилось вводить поддержку rel=»nofollow»?

nofollow

се дело в том, что тег <noindex> это личная инициатива Yandex. Данный тег нигде в мире, кроме самого Яндекс, не поддерживается и не стандартизирован. При проверке ресурса на ошибки в коде и поддержке web-стандартов, веб-мастера всегда получали «не валидный» код. То есть, ваш ресурс содержит ошибки. Но, спешу вас успокоить, это не критическая ошибка и практически ни на что не влияет. Для тех кому важен валидный код, вот структура, рекомендованная самим Yandex для валидности вашего кода:

<!--noindex-->Блок вашего закрываемого текста<!--/noindex-->

Еще одна проблема тега <noindex> в том, что зарубежные веб-мастера, не ведая о данном теге, не используют его в разработках своих плагинов к WordPress. Приходится данные плагины адаптировать под Яндексовскую реальность.
Если в комментариях блога ссылки были закрыты атрибутом rel=»nofollow», то для Яндекса эти ссылки были открыты. Это означало, что роботу приходилось путешествовать по всем ссылкам указанным в комментариях.

Атрибут со статусом rel=»nofollow» стандартизирован и используется во всем мире для указания поисковикам, что ссылка не одобрена автором и  по ней не нужно следовать.
Например, если закрыть служебную страницу от индексации в robots.txt, а ссылку оставить открытой, робот проследует на данную страницу, но не проиндексирует ее. Зачем тогда тратить ресурсы робота на переходы по ненужным страницам? Еще есть один нюанс, если на вашу служебную страницу ведут открытые ссылки с других внешних источников, то ваша, как бы закрытая страница, попадет в поиск, даже если она закрыта в robots.txt. Об этом также расскажу в следующих статьях.

Исходя из всего этого, по многочисленным просьбам и жалобам веб-мастеров, Яндекс ввел поддержку стандартизированного W3C атрибута со статусом rel=»nofollow». Атрибут закрывает ссылки от переходов роботом и не передает вес. Теперь многое стало проще. Но есть один нюанс. Анкоры ссылок будут проиндексированы как текст.

Зачем нужен <noindex>?

Тег <noindex> очень важен, если вы хотите, чтобы часть текста, со всеми анкорами ссылок и т.д., не индексировалась и не попала в поисковую базу Yandex.
Например, у вас на странице может быть служебная информация, или блок текста с сайта, который используется как негативный пример. Вы не хотите, чтобы поисковик  связал ваш сайт с данным текстом или индексировал служебную информацию и сохранил у себя в базе. Для этого данный блок обрамляется тегом <noindex>.

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

Как правильно прописать rel=nofollow и <noindex>

  1. Для закрытия ссылок от индексации, с помощью rel=»nofollow»,  используется простая схема:
    <a rel=»nofollow» href=»http://www.site.com» title=»Подсказка»>Ссылка на сайт</a>
    перехода по ссылке не будет.
  2. Для закрытия блока текста тегом <noindex>, со всем содержимым, в том числе и с анкорами ссылок, используется схема:
    <!--noindex-->Блок вашего закрываемого текста<!--/noindex-->
    данный текстовый блок не будет проиндексирован в Яндекс, со всеми текстами ссылок.
  3. Для закрытия блока текста тегом и ссылок в блоке, используется схема:
    <!--noindex-->Блок вашего закрываемого текста <a rel="nofollow" href="http://www.site.com" title="Подсказка">Текст анкор ссылки</a> Блок вашего закрываемого текста<!--/noindex-->
    данный блок не будет проиндексирован в Яндекс, со всеми ссылками содержащимся в данном блоке.

Что изменилось с вводом поддержки rel=nofollow?

  1. Для тех, кто ведет ресурсы для людей и не использует спам-продвижения, почти ничего не изменится. Возможно некоторое уменьшение числа внешних ссылок, закрытых с rel=»nofollow».
  2. Для тех, кто использовал в продвижении ссылочный спам (спам в комментариях, спам в форумах, соц. сетях, Википедии и т.д), и у кого основная ссылочная масса, дающая ТИЦ, состояла из таких ссылок, будет существенное снижение ТИЦ и как правило, проседание в поисковой выдаче Yandex.

Кратко, о новинках апреля 2010 года в Яндекс:

  1. У страницы поисковой выдачи Яндекс теперь фиксированная ширина.
  2. Появились в выдаче навигационные цепочки, у некоторых сниппетов и даты публикации.
  3. Появился колдунщик видео.
  4. В панели веб-мастера появилась возможность просмотра статистики по собственным ключевым словам.

P.S. Теперь осталось дождаться включения поддержки Яндексом канонического атрибута rel=»canonical», о котором я писал в статье о дублированном контенте, и многие блогеры вздохнут с облегчением.
Хорошая новость, в конце мая 2011г. Яндекс стал учитывать атрибут rel=»canonical». Принесет это облегчение или нет, покажет время.

Настройка кеширования страниц в PHP: XCACHE

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

Настраиваем кеш: Файл настройки /etc/php5/apache2/conf.d/xcache.ini.

Также можно указать число ядер вашего процессора:

понятно, что это для 2-х процессоров.


Источник: http://help.ubuntu.ru/wiki/web-server

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

3D визуализация и интерьер

Разгоняем WordPress до скорости света

7337481781ba67dec1Скорость и отказоустойчивость – одни из тех факторов, что неизменно влияют на популярность вашего ресурса, ведь даже с лучшим в мире контентом медленно работающий сайт будет раздражать читателей и рано или поздно вы их потеряете. В этой статье мы будем оптимизировать самый популярный блоговый движок — WordPress, работающий на PHP. А заодно рассмотрим несколько общих моментов в оптимизации сайтов.

1 Тестируем текущую скорость

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

1.1 Pingdom

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

habr1Бенчмарк одного довольно известного ресурса.

1.2 YSlow

YSlow– плагин для Firefox, который встраивается в, пожалуй лучший плагин для веб разработчика, Firebug. Он анализирует более 20 факторов, которые влияют на скорость работы сайта и оценивает общую производительность по 100 бальной системе, а каждый отдельный элемент оценкой от A до F.

habr2

1.3 Количество запросов и время их выполнения

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

<?php echo get_num_queries(); ?> queries in <?php timer_stop(1); ?> seconds.

 

2 Web Hosting

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

  • Shared Hosting – на одном сервере может хоститься в среднем около 100 человек;
  • VPS – на одном сервере может хоститься около 20 человек;
  • Dedicated – сервер будет использоваться только вами.

Чтоб просмотреть примерную нагрузку на сервер, залогиньтесь через ssh и введите в консоли команду top.

Это, конечно, не означает, что вы не сможете ускорить блог, работающий на виртуальном хостинге(Shared Hosting), однако стоит помнить – производительность тем выше, чем большие ресурсы мы имеем в своем распоряжении.

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

3 Установка и настройка сервера

Удостоверьтесь, планируемая нагрузка соответствует мощности сервера и он сможет с ней справиться. В первую очередь это будет зависеть от объема оперативной памяти и процессора. Как правило, WordPress ставят на Apache, но много удачных решений существует и на базе других http серверов: nginx, lighttpd и т.д.

Не забудьте обновить до последней версии PHP и Apache.

3.1 Отключите неиспользуемые сервисы

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

  • Удалите ClamD;
  • Настроить SpamD на использование только 1 дочернего процесса;
  • Удалите Mailman, если, конечно, вы не собираетесь запускать почтовый сервис.

 

3.2 MYSQL Query Cache

Поскольку стабильность и скорость WordPress довольно сильно зависит от работы БД, стоит убедиться, что настройки в my.cnf соответствуют возможностям сервера. В первую очередь следует установить настройки кэширования запросов, добавив в my.cnf следующие строки:

query_cache_type = 1
query_cache_limit = 2M
query_cache_size = 20M

Чтоб настройки вступили в силу придется перезапустить сервис MySQL сервис.

3.3 Кэш компилятора: XCache или Eaccelerator?

Кэш компилятора увеличивает производительность откомпилированных скриптов на сервере, кэшируя их – это поможет сократить время выполнения PHP скриптов. Стоит попробовать и то и другое решение, однако по результатам опытов увеличение производительности при использовании Xcache на 5% выше, чем с Eaccelerator.

3.4 Увеличьте максимальное число соединений на Apache

Увеличение максимального количества соединений в httpd.conf повысит производительность, т.к. сервер сможет обрабатывать большее количество подключений за раз. Однако, следует изменять этот параметр осторожно, дабы не исчерпать весь объем оперативной памяти и не замедлить работу сервера, потому всегда тестируйте новые настройки прежде чем запускать их в работу. Установим к примеру 150 коннектов:

max_connections = 150

Не забудьте рестартить сервис Apache, чтоб применить настройки.

4 Оптимизация кода и графики

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

4.1 Отключите хотлинки

Каждый раз когда вы используете свой сервер для хранения изображений вы существенно больше используете его ресурсов. Довольно часто люди заимствуют ваши изображения, ставя хотлинки на своих серверах. Это не только занимает канал, но и создает определенную нагрузку на сервер.
Добавьте следующий код в .htaccess файл, заменив example.com на имя вашего домена, чтобы отключить использование хотлинков:

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^http://(www\.)?example\.com/.*$ [NC]
RewriteRule .*\.(gif|jpg|png|ico)$ - [F,L]
</ifModule>

 

4.2 Используйте внешний хостинг для хранения изображений

Хостинг изображений на внешних серверах поможет значительно снизить нагрузку на сервер. В примере ниже вы можете видеть снижение объема используемой оперативной памяти на одном из блогов после переноса изображений на сервис Amazon S3.

amazons3images

4.3 Сжимайте java-скрипт код

Сжатие javascript довольно простая задача. Поскольку он выполняется при каждом просмотре страницы, вы можете уменьшить размер Javascript, удалив все незаполненное пространство. Вот простой инструмент, который поможет сделать это за вас — JavaScript Compressor.

4.4 Javascript в начале страницы

Часто случается так, что сайт начинает загружаться медленно или вообще останавливается, т.к. другой ресурс, с которого вызывается javascript(на пример Digg badges, Tweetmeme и т.д.), не доступен или оффлайн. Чтобы избежать этого вынесите весь javascript код в конец страницы, а то что по каким-то причинам вынести не удалось – попробуйте заключить в iFrame.

4.5 Используйте кэш браузера

Сам по себе кэш браузера, конечно не сделает ваш блог быстрее, однако поможет снизить нагрузку на сервер, кэшируя часто загружаемые объекты(стили, элементы интерфейса и т.п.).
Попробуйте вставить следующий код в .htaccess файл:

FileETag MTime Size
<ifmodule mod_expires.c>
<filesmatch "\.(jpg|gif|png|css|js)$">
ExpiresActive on
ExpiresDefault "access plus 1 year"
</filesmatch>
</ifmodule>

 

4.6 Сжимайте статические данные

Вы можете уменьшить размер загружаемой страницы позволив браузеру принимать и передавать данные в сжатом виде. Это также снизит загрузку канала и количество загружаемых данных.
Следующий код в .htaccess может помочь вам в этом:

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/xml application/xhtml+xml text/javascript text/css application/x-javascript
BrowserMatch ^Mozilla/4 gzip-only-text/html
BrowserMatch ^Mozilla/4.0[678] no-gzip
BrowserMatch bMSIE !no-gzip !gzip-only-text/html

 

4.7 Используйте CDN для статических файлов

Если хранить все изображения на одном и том же домене, то браузер будет ожидать их загрузки одного за другим. Допустим на странице их у вас есть 12 штук, если вы разделите их между тремя поддоменами, они будут загружаться одновременно из трех «разных» источников вместо того, чтоб загружаться браузером по очереди из одного.
Можете попробовать перенести все css & javascript файлы на files.yoursite.com, а изображения и временные файлы на static.yoursite.com. Или же просто использовать CDN(Content Delivery Network) – большая сеть серверов, расположенных по всему миру, которые позволят не только хранить ваши файлы на разных поддоменах, а значит загружать их параллельно, но и доставлять пользователю данные с самого близкого к нему сервера. Все это позволит загружать данные намного быстрее.

5 WordPress

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

5.1 Обновитесь до последней версии

Обновления до более новых версий позволяют не только устранять обнаруженные уязвимости, но и улучшают производительность. Для примера в wordpress 2.8 была существенно оптимизирована работа с БД.

5.2 Отключите Post Revisions

Во всех версиях wordpress, начиная с 2.6, редакции ваших статей каждый раз во время правки автоматически сохранялись. Это замедляет работу БД и увеличивает ее размер без особой надобности.
Чтоб отключить post revisions, добавьте следующую строку в wp-config.php:

define('WP_POST_REVISIONS', false);

Чтобы удалить сохраненные ранее ревизии текста, выполните следующий запрос в PHPmyadmin:

DELETE a,b,c
FROM wp_posts a
LEFT JOIN wp_term_relationships b ON (a.ID = b.object_id)
LEFT JOIN wp_postmeta c ON (a.ID = c.post_id)
WHERE a.post_type = 'revision'

 

5.3 Сократите количество запросов

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

<meta http-equiv="Content-Type" content="<?php bloginfo('html_type'); ?>; charset=<?php bloginfo('charset'); ?>" />

Мы запросто можем переписать в:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

Уже на два запроса меньше. Довольно просто, не правда ли?

6 WordPress Plugins

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

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

PHP Speedy WP
Этот плагин решает другую проблему, обозначенную в этой статье – удаление незаполненного пространства в CSS & javascript. Однако есть некоторые проблемы совместимости этого плагина с WP Super Cache, кроме того он долгое время уже не обновлялся, потому используйте на свой страх и риск.

Optimize DB
Плагин позволяет оптимизировать таблицы MySQL без помощи PHPmyadmin.


Источник: http://habrahabr.ru/post/69046/

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

.htaccess и php_value mbstring.func_overload

Автор: Рудюк С . А.
https://corp2.net

E-Mail: rs@corp2.net

В 1С-Битрикс требуют установку параметров php.ini:

Но, с некоторых пор данные параметры не изменяются в файле .htaccess. Изменение же в php.ini может отрицательно сказаться на работе других сайтов.

Решением может настройка конфига виртуального хоста:

Автор: Рудюк С . А. https://corp2.net

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

Оптимизация веб-сервера

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

1. Оптимизация CMS-системы.

Как было показано опытами, которые я проводил несколько лет назад, наибольшая скорость загрузки и пропускная система — у статических файлов. Скорость cms-систем и статических файлов отличается в 1000-10 000 раз. Причем, это еще сильней сказывается при применении системы веб-сервера NGinx.

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

2. Оптимизация работы веб-сервера. Связка Apache-Nginx.

Мы давно практикуем систему 2-х уровневого веб-сервера. Эта система дает устойчивость к большому количеству посещений, и как результат — скорость работы веб-сервера.
3. Оптимизация работы базы данных. Связка PostgreSQL-PGBouncer.

Связка о которой многие забывают, но которая просто необходима при большом количестве работающих пользователей в online. Эта связка прекрасно себя проявила и сейчас реально у нас реально выдерживается более 500 пользователей в online. Причем, есть возможность выдерживать еще гораздо большие нагрузки!
4. Оптимизация работы с файлами Nginx.

Если не правильно настроить Nginx, то он будет загружать не нужной работой Apache. Поэтому, мы настроили Nginx так, чтоб он как можно реже переводил управление на Apache. В идеале — работая вообще без Apache!

5. Системы кеширования PHP. Остановились на xCache.

Значительное время веб-сервера тратится на компиляцию PHP-кода. Поэтому, я решил установить систему кеширования PHP-кода. Рассматривая ряд вариантов остановился на xCache. Но, ниже дам выдержки из статей для настройки нескольких разных систем кеширования php-кода. Может, в некоторых случаях, они будут более эффективны…

По настройке админки xcache, советую прочитать документацию: http://xcache.lighttpd.net/wiki/InstallAdministration

Установка и настройка xCache

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

cd /usr/ports/www/xcache/
make install clean

При установке доступен диалог настройки сборки, с единственным пунктом Enable code coverage dumper, по умолчанию она включена и служит для определения.предотвращения переполнения памяти.
По окончании установки, нужно скопировать файл настройки xcache.ini в /usr/local/etc/php/:

cp /usr/local/share/examples/xcache/xcache.ini /usr/local/etc/php/

и немного исправить.
У меня получился такой файл настроек:

[xcache-common]
extension = xcache.so
#Включим админ интерфейс
[xcache.admin]
xcache.admin.enable_auth = On
xcache.admin.user = «admin»
#В качестве пароля укажем md5 хеш, создать его можно с
#помощью команды md5 -s «ваш пароль»
xcache.admin.pass = «XXXXXX»

[xcache]
xcache.shm_scheme = «mmap»
#Выделим для кеша 128 мегабайт
xcache.size = 128M
xcache.count = 1
xcache.slots = 8K
xcache.ttl = 0
xcache.gc_interval = 0
xcache.var_size = 0M
xcache.var_count = 1
xcache.var_slots = 8K
xcache.var_ttl = 0
xcache.var_maxttl = 0
xcache.var_gc_interval = 300
xcache.test = Off
xcache.readonly_protection = Off
xcache.mmap_path = «/dev/zero»
xcache.coredump_directory = «»
xcache.cacher = On
xcache.stat = On
xcache.optimizer = On

[xcache.coverager]
xcache.coverager = On
xcache.coveragedump_directory = «»

Настройка самого XCache закончена, остается сделать доступным админ интерфейс. Для этого я у себя скопировал /usr/local/share/examples/xcache/admin в документ рут своего вебсервера www.hilik.org.ua
После этого админ интерфейс станет доступным по URL http://www.hilik.org.ua/admin/
Конечно через этот интерфейс доступна только статистика, но все равно, это полезная функция.
Да и авторизация определена вами в xcache.ini.

Взято на сайте http://www.hilik.org.ua
Установка Eaccelerator

PHP — язык интерпретируемый. Это значит, что каждый раз, когда происходит вызов скрипта на этом языке, запускается PHP-интерпретатор, который проводит полный анализ исходного кода. Причем, если спустя секунду произойдет второй запуск того же скрипта, вся процедура будет повторена заново. Это нерациональное использование ресурсов, поэтому мы применим инструмент под названием eAccelerator, который скомпилирует исходные тексты PHP в двоичное представление, оптимизирует их и будет бережно хранить в оперативной памяти для более быстрого доступа. Благодаря только этому скорость обработки PHP-скриптов вырастет в десятки раз (подтверждено тестами).

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

$ sudo apt-get install php5-dev build-essential

Далее получаем исходные тексты eAccelerator:

$ cd /tmp/
$ wget http://bart.eaccelerator.net/source/0.9.6.1/
eaccelerator-0.9.6.1.tar.bz2
$ tar xvjf eaccelerator-0.9.6.1.tar.bz2
$ cd eaccelerator-0.9.6.1
$ phpize
$ ./configure —enable-eaccelerator=shared
$ make
$ sudo make install

Создаем каталог для хранения кэша:

$ sudo mkdir -p /var/cache/eaccelerator
$ sudo chmod 0777 /var/cache/eaccelerator
И, наконец, подключаем eAccelerator к PHP (добавить в начало файла):
# vi /etc/php5/apache2/php.ini
[PHP]
; Подключаем расширение
extension = «eaccelerator.so»
eaccelerator.enable = «1»
; Максимальный размер дискового кэша (Мб)
eaccelerator.shm_size = «64»
; Каталог для хранения кэша
eaccelerator.cache_dir = «/var/cache/eaccelerator»
; Включаем оптимизатор кода
eaccelerator.optimizer = «1»
; Перекомпилировать модифицированные скрипты
eaccelerator.check_mtime = «1»
; Отключаем режим отладки
eaccelerator.debug = «0»
; Кэшировать все файлы (пустой фильтр)
eaccelerator.filter = «»
; Неограниченный размер кэша в памяти
eaccelerator.shm_max = «0»
; В случае отсутствия места в кэше удалять объекты старше
1 часа (3600 секунд)
eaccelerator.shm_ttl = «3600»
eaccelerator.shm_prune_period = «0»
; Кэшировать данные и в памяти, и на диске
eaccelerator.shm_only = «0»
; Сжимать кэшированные данные с максимальным уровнем компрессии
eaccelerator.compress = «1»
eaccelerator.compress_level = «9»

Установка APC

Статья по адресу: http://phpcoder.ws/2009-02/apc-setup.html

APC (Alternative PHP Caching – это Альтернативный ПХП Кешер, руководство по использованию на английском языке). Входит в число трех наиболее популярных способов кеширования опкодов для выполненных php скриптов. Его ближайшими конкурентами являются XCache и eAccelerator. О последнем я уже писал недавно на этом блоге, а статья об XCache, который имеет несколько очень существенных преимуществ перед конкурентами, будет опубликована здесь в ближайшее время. Короче говоря, APC это еще один способ повысить быстродействие вашего сайта в том случае если он расположен на вашем сервере, вы являетесь админом своего хостинга и вас волнуют вопросы быстродействия размещенных на нем сайтов…

Установка APC

Одним из основных преимуществ APC является его простота установки. Если вы являетесь пользователем Debian/Ubuntu, то вполне вероятно что для установки вам будет достаточно набрать в консоли команду sudo aptitude install php-apc или установить этот пакет через synaptic. Если вы используете другой дистрибутив, или по какой-то причине не можете установить “родной” deb-пакет, то у вас есть другой путь – установка из PECL. Для этого нужно набрать команду: sudo pecl install apc, которая скачает нужные архивы из сети, распакует, откомпилирует и установит полученный файл apc.so в нужную директорию.
Проверка установки APC

Во-первых, проверьте что строчка загрузки расширения extension=apc.so действительно прописалась в php.ini (или создан файл apc.ini с этой строчкой в папке с конфигами расширений php – зависит от вашего дистрибутива. Для Debian, например, этой папкой будет /etc/php5/apache2/conf.d/

Если строчка успешно найдена/добавлена, то перезапускаем сервер apache и переходим к проверке самого расширения. Для этого находим папку в которую было установлено расширение. В этой папке будет лежать файл apc.php (файл так же можно взять в архиве установки), копируем его в public директорию любого из сайтов на этом веб-сервере и заходим браузером по адресу http://сайт/apc.php. Если расширение было установлено корректно, то вы увидите на загруженной странице статистику по APC (скриншоты приведены ниже).
Общая информация об APC

Общая информация об APC
Подробная информация об APC

Подробная информация об APC
Информация о хосте

Информация о хосте
Замеры изменения производительности

Для проверки была выбрана CMS Joomla1.5.9 с демонстрационным набором данных после установки и с шаблоном дизайна по умолчанию. При тестировании производительности при помощи утилиты ab2 (было выполнено 1000 обращений к главной странице сайта в 5 потоков) скорость генерации страниц увеличилась на 40%
Недостатки APC

Объективности ради отмечу и недостатки APC…

* отсутствует поддержка FastCGI
* кеширование работает только с модулем apache mod_php (в режиме cli ускорения не будет)
* работает с версиями PHP<=5.2 С версией 5.3 отмечаются проблемы, а что касается 6.0 — будущее совсем туманно. Возможно какой-то механизм кеширования будет интегрирован в само ядро…

Заключение

По-моему стоит установить APC на своем веб-сервере и попробовать – подойдет ли оно именно вам. Несмотря на ряд описанных выше ограничений APC считается наиболее надежным из тройки основных реализаций кеширования для языка PHP…

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)

Веб-сервер Nginx и PHP-FPM (настройка мобильного хостинга) — пополняется

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

Для виртуальной машины вырал virtualbox:
https://www.virtualbox.org/wiki/Downloads

Операционную систему использую Linux Ubuntu:
http://www.ubuntu.com/

После того, как установил Linux Ubuntu в вируальной машине VirtualBox, устанавливаю веб-сервер nginx и PHP-FPM:

Редактируем файл:

Редактируем файл:

Перезагружаем:

Для удобства, ставлю некоторые из утилит:

Устанавливаю DNS-сервер для настройки ns-сервера и доменных зон:

mc — это удобный файловый менеджер.

htop — удобное средство для просмотра загрузки процессоров.

whois — сервис для получения информации о доменах.

Еще некоторые команды, которые могут понадобиться при настройке доменов.

dig название домена — определение информации о настройках домена .
nslookup название домена — просмотр ns-серверов домена.

Устанавливаем Apache2

Для сайтов, которым нужен rewrite устанавливаем Apache2:

apt-get install apache2

apt-get install libapache2-mod-php5

apt-get install php5-curl

Ставим RPaf

Устанавливаем MySQL

Устанавливаем Memcahed

Настройка рабочего места веб-разрабочика

Для работы с веб-сервером, удобно поставить такое программное-обеспечение:
putty — клиент терминала.
filezilla — файловый менеджер, передающий файлы по ssh.

Данное программное обеспечение — с открытым исходным кодом, бесплатное и кросс-платформенное. Прекрасно зарекомендовало себя при работе с веб-сервером.

Настройка конфигов Nginx

Другие полезные утилиты на хостинге

Просмотр объема трафика в терминале:
apt-get install iptraf
Чтоб просмотреть трафик, просто наберите в терминале:  iptraf

Просмотр объема трафика в веб-виде:
apt-get install darkstat

После установки, изменяем конфиг /etc/darkstat/init.cfg
# Turn this to yes when you have configured the options below.
START_DARKSTAT=yes

# Don’t forget to read the man page.

# You must set this option, else darkstat may not listen to
# the interface you want
INTERFACE=»-i eth0″

#DIR=»/var/lib/darkstat»
PORT=»-p 666″
#BINDIP=»-b 127.0.0.1″
#LOCAL=»-l 192.168.0.0/255.255.255.0″

# File will be relative to $DIR:
#DAYLOG=»—daylog darkstat.log»

# Don’t reverse resolve IPs to host names
#DNS=»—no-dns»

#FILTER=»not (src net 192.168.0 and dst net 192.168.0)»

# Additional command line Arguments:
# OPTIONS=»—syslog —no-macs»

service darkstat start

Чтоб посмотреть трафик просто в браузере наберите:
http://ip-адрес_Вашего_сервера:666

Разработка и создание сайтов, интернет-магазинов, веб-приложений, порталов, лэндингов, мобильных приложений (Киев)