Обычно, я не рассказываю читателю о технической стороне работы моего сайта, но некоторыми вещами захотелось поделиться.
До недавнего времени мой ресурс целиком и полностью отдавался по домашнему ADSL Annex B каналу, исходящая скорость на котором не превышает 600 Кбит/с. В принципе, канала хватало, но ровно до тех пор, пока я не начал развешивать в каждом посте по десятку фотографий.
Главная страница моего блога весит от 5 до 8 мегабайт. Для того, чтобы отдать весь контент посетителю за 10 секунд, нужно иметь скорость соединения не менее 10 мегабит. А если кидаешь ссылку на форум о наличии вновь опубликованного поста, то в раз к тебе приходят до 20 человек. Здесь нужно уже иметь гигабитный интерфейс, чтобы для каждого посетителя процесс загрузки фотографий остался незаметным.
На моей машине помимо блога размещены такие вещи, которые нельзя перенести на VPS, поэтому целиком и полностью отказываться от домашнего сервера я не спешу. К тому же интерес пропадает, и платить по $10 за урезанные возможности не хочется.
Задача была решена следующим образом.
Начиная с версии 2.6 в WordPress появилась замечательная возможность указания пути размещения и загрузки для контента и плагинов (см. wp-config.php). Т.е. владелец блога может указать следующие вещи:
1. Локальный путь к папке wp-content, в которой находится контент:
define( 'WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/wp-content' );
2. Полный URI путь–префикс к папке wp-content:
define( 'WP_CONTENT_URL', 'http://wp-content.ksn.name');
3. Локальный путь к папке plugins:
define( 'WP_PLUGIN_DIR', $_SERVER['DOCUMENT_ROOT'] . '/wp-content/plugins' );
4. Полный URI путь–префикс к папке plugins:
define( 'WP_PLUGIN_URL', 'http://ksn.name/wp-content/plugins');
Конечный слэш («/») не указывается!
Как вы уже догадались, я воспользовался возможностью определения полного URI путь–префикса к папке wp-content и перенёс (на самом деле продублировал) весь контент на другой субдомен. Теперь стало возможным отдавать тяжёлый статический груз WordPress блога с совершенно другого сервера/хостинга (или нескольких серверов, если правильно настроить DNS).
В качестве сервера для контента послужила виртуальная win–площадка Мастерхост за 150 рублей в месяц. Почему windows, скажете вы… Всё дело в том, что в отдаче статического контента IIS равных нет. К тому же, я давно задумывал родить несколько сервисов на ASP.NET (windows–хостинг был выбран без колебаний).
Итак, я скопировал всё содержимое директории wp-content на хостинг и определил константы в файле wp-config.php.
После проделанного сайт работоспособен, но… URI пути к фотографиям в постах остались прежними и начинаются с http://ksn.name, т.е. основная нагрузка трафика остаётся на прежний канал. Открывать каждый пост и переписывать пути занятие нецелесообразное, поэтому дополнительно был применён швейцарский нож URL преобразований — mod_rewrite, и в корневой файл .htaccess были внесены две строчки (для папки загрузок и фотографий):
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^wp-content/gallery/(.*)$ http://ksn.name/wp-content/gallery/$1 [R=303,L]
RewriteRule ^wp-content/uploads/(.*)$ http://ksn.name/wp-content/uploads/$1 [R=303,L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
RewriteCond %{HTTP_HOST} !=ksn.name
RewriteRule ^(.*) http://ksn.name/ [R=301]
</IfModule>
Таким образом, при запросе картинки с адресом http://ksn.name/wp-content/uploads/2009/12/S-MPH-0895_11.jpg Apache сообщит браузеру посетителя «смотри по адресу http://wp-content.ksn.name/uploads/2009/12/S-MPH-0895_11.jpg», и картинка будет загружена с веб–сервера wp-content.ksn.name.
Отныне, ежедневный груз в размере нескольких гигабайт сброшен на плечи Мастерхоста.
На что следует обратить внимание?
- При добавлении нового контента, через библиотеку медиафайлов, его необходимо продублировать на сервер контент–хостинга дополнительно ручным способом.
- Практически все хостинг–провайдеры не требуют дополнительной оплаты за размещение данных на субдоменах. К тому же, хостинг статического контента в 2 раза дешевле хостинга с возможностью запуска скриптов, а его цена, как я уже говорил, не должна превышать 150 рублей.
- Приведённые выше инструкции полезны как блогерам со стажем, так и начинающим. Чем раньше разнесён контент,тем проще им будет управлять в будущем.
P.S. Переопределением путей для папки плагинов работает полноценно, но с ним, на мой взгляд, лучше не экспериментировать.
Да, нормусь :))
Мы решали проблему так же, только вместо использования .htaccess переписывали адреса «на лету». Этим мы снижали количество запросов к основному серверу (отправление запроса и получение редиректа — это тоже трафик, а если еще и cookies передаются…). Мы использовали VoxCDN, так что с проблемой синхронизации не сталкивались. Вообще я бы использовал для этого rsync.
А вообще если говорить об оптимизации: я бегло насчитал 22 запроса, на которые сервер отвечает 303 See Other. Каждый ответ в среднем 300 байт. Итого 6 килобайт фактически мусора на пользователя (это не считая размера запроса).
Также сервер не выставляет заголовок Expires, не жмёт JavaScript gzip'ом, YSlow! говорит, что много статики отдаётся без ETag. Всё-таки дешевле отправить код 304, чем отсылать контент заново.
Если натравить на JPEG-файлы jpegtran, можно сэкономить чуть более 400 КБ, если оптимизировать GIF/PNG-файлы — еще почти 70 КБ. Итого почти полмегабайта на пользователя. По-моему, не плохо :-)
Видимо помогло) Ждал загрузки главной страницы меньше трети секунды, учитывая то, что у меня дохлый канал
А вам не кажется, что 5-8 мегабайт немного многовато для одной страницы?
@Vladimir
Буду ещё работать над оптимизацией.
@Alex
Неа, абсолютно не кажется.
5Mb на «лицо» блога это однозначно плохо, каналов плохих сейчас мало, а вот людей который могут с работы выходить и там идет просчет трафика... да и вообще — почему бы не поместить FLV на 100 метров? какая разница... прогрузится 105 мегов :)
По поводу оптимизации — а если nginx сюда вставить? он и будет как прокси картинки и прочее тащить...
@Александр
На работе нужно либо работать, либо иметь безлимитный интернет.
105 Мб будет весить тогда, когда у всех будет гигабит.
Я помню свою первую книжку по HTML-конструированию, где автор предлагал значения атрибутов тегов не заключать в кавычки (т.е. вместо <div class="text">text</div> писать <div class=text>text</div>), аргументируя это скоростью загрузки страницы. Позже это вообще стало нарушать правила HTML-разметки, помимо того, что экономия нескольких байт ни на что не влияет. Также и вы сегодня аналогичное предлагаете.
По поводу nginx — вопрос стоял в разгрузке канала, а не в системных ресурсах.
[...]заинтересованным лицам к прочтению его статью Распределённый трафик (для блога WordPress) (вопросы и предложения можно задать там же) AKPC_IDS += "5372,"; [...]
На Windows-хостинге у Мастерхоста за 150 руб. дают 600 Мб места. Откуда «груз в размере нескольких гигабайт»? Или Вы о трафике?
Я говорю про трафик.
Понятно. Спасибо. Можно в связи с этим одну просьбу высказать?
Известно, что у большинства хостеров трафик не безлимитный. У Мстерхоста он также бесплатен при определенных условиях. Поэтому было бы любопытно знать: появится у подобной распределенной схемы хостинга недостаток в виде дополнительной оплаты за трафик. Если «да», то в какой момент.
Спасибо.
То, что Вы смотрите относится к VPS & Colo.
Для виртуального хостинга отсутствуют подобные ограничения.
Никто с Вас ещё 300 рублей за генерацию 20 Gb трафика брать не будет.
У меня один сайт генерирует 50-70 Gb в месяц на виртуал-хосте. Из-за этого пришлось уйти с Мастерхоста. Я им письмо писал с просьбой сделать скидку на трафик. Отказали.
Я им верю.
И еще уточню. Меня не «попросили уйти», а я собирался перенести к своему существующему там аккаунту сайт с высоким трафиком, спросил «есть ли скидки? ». Мне ответили так, как я написал выше, а на другом хостинге предложили тариф за 500 руб. И я разместил сайт там.
Кажется я сейчас только понял почему они отказали в скидке. Я, непонятно почему, отправил письмо с запросом не на bill@masterhost.ru, а на colo@masterhost.ru (не могу понять где я взял этот ящик). Тогда получается, что я им про virtualhost, а они мне про colocation.
К сожалению, когда они у меня спросили
я уже загружал файлы другому хостеру, который предложил бесплатное тестирование и оплату через неделю...Спасибо Даниилу Паскалю и Вам, Сергей, что заставили меня еще раз перечитать нашу переписку :)
@Александр
Я не понимаю про какую скидку вы говорите, если на виртуальной площадке отсутствуют какие-либо ограничения по трафику.
Не стоит путать виртуальную площадку (виртуальный хостинг), VPS и Colocation. Это три абсолютно разные услуги.
@Александр
500 рублей это дороговато. Мастерхост делает вкусные предложения.
А как быть с WordPress mu?
Допустим, у меня на хостинге 2 аккаунта, на 1 аккаунт выдаётся 10 мбит.
Допустим, хочу я чтобы файлы всех пользователей блогов хранились на другом сервере (аккаунте).
Как это сделать не подскажете?
@Алексей Щербаков
Попробуйте проделать аналогичным способом. В любом случае моё решение не предполагает масштабируемости.
а еще можно использовать nginx или apache с mod-ами... но это когда VDS конечно же...
да и где нужны такие оптимизации? когда нагрузка по обращениям (ведь тема у нас оптимизирована уже?) — а тогда уже и VDS брать надо...
@Алексей Щербаков
способ аналогичный :)
@Vladimir
:) :) :)
YSlow! очень странное создание... у меня на блоге и портале — все жмется, а YSlow! категорически говорит, что нет :)
По поводу трафика — тут вопрос в скорость отдачи и возможно в среднем — она увеличивается (увеличиваем сильно скорость обработки, но повышаем объем трафа... и если скорость быстрее трафа растет — то гуд ;))
@ksn
Сейчас большинство хостеров осуществляют движение в сторону nginx... как фронта...
Отличное решение. Я на VPS-ке живу и со скоростью проблем не имею, но на будущее буду иметь ввиду.
Таким образом, при запросе картинки с адресом ksn.name/wp-content/uploa... — MPH-0895_11.jpg Apache сообщит браузеру посетителя «смотри по адресу ksn.name/wp-content/uploa...PH-0895_11.jpg»,
--------------------
Вы уверены, что здесь правильно прописан второй URL?
@Alex
исправил, спасибо!
Интересное решение. В последнее время на хостинге нагрузка на проц стала достигать до 30%. Конечно этот метод не решит мою проблему, но есть над чем поразмыслить