Обслуживание изображений от другого имени хоста по сравнению с перегрузкой Apache для переписывания

Я играл с подобным вопросом в своей компании в течение прошлых недель. Пара вещей иметь в виду:

1. Несколько доменов для браузеров: Это - тонкая грань для настройки. С одной стороны, Вы наложили браузером пределы того, сколько ресурсов может быть загружено одновременно из того же домена (в этом отношении, больше доменов для загрузки от лучше). С другой стороны, каждый домен, к которому Вы обращаетесь, требует поиска DNS, который может препятствовать скоростям под нагрузкой. Я использовал эмпирическое правило 5 различных доменов, сам.
2. Затем, если я читаю Ваше право описания (и я все еще пью кофе, таким образом, я не мог бы быть), Вы все еще собираетесь быть выполняющим начального запроса на 'main.com' и наличие 'тяжелого' апачского перенаправления 'легким' апачам. Это не собирается помогать Вам вообще. Если бы Вы пошли этим путем, то было бы лучше настроить 'main.com' как легких апачей и иметь его Обратный Прокси любое нестатическое содержание 'тяжелым' апачам.
3. Номер 2 не в полной мере пользуется 'несколько доменное' улучшение, хотя, так как все запросы продвинуты через домен main.com. Таким образом, то, что мы сделали, было настроено домен (после Ваших имен в качестве примера) cdn.main.com как 'легкие' апачи, и имейте их, внутренне перенаправляют к соответствующим ресурсам. Вы могли бы проверить mod_cache также.

перенаправить main.com/image.jpg (я понимаю, что мы должны будем сделать 301) на cdn.main.com/image.jpg

Это - плохая идея, не делайте этого.

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

Если Вы волнуетесь по поводу мощности сервера, также:

• Получите более крупный сервер или
• Используйте прокси-сервер в RAM перед своим сервером HTTP (Сквид, Лак, Транспортный Сервер Apache) или
• Используйте недорогую Сеть доставки контента для кэширования статического содержания ближе конечным пользователям, уменьшая и время загрузки страницы и нагрузку на серверы.

таким образом способность браузера иметь больше соединений.

Предел загрузки параллели браузера является чем-то вроде отвлекающего маневра - современные браузеры загружают 6-8 файлов параллельно с того же имени хоста. Это - только старые браузеры (IE6, IE7), которые действительно страдают от этого ограничения.

Если Вы волнуетесь по поводу скорости под нагрузкой страницы конечного пользователя, то используйте CDN, это - хороший совет во всех ситуациях, были Ваши пользователи, распространены по большому географическому району (т.е. у Вас есть мировая аудитория).

301 с всех изображений на странице быть оштрафованным Google?

Возможно. Но более вероятно, это будут ненавидеть Ваши пользователи. Поскольку каждое изображение запрашивает сначала служить 301 и затем правильному образу от другого URL. Это значит 2 распространения в прямом и обратном направлениях для серверов для каждого изображения, и следовательно значительно более длительное время загрузки страницы для Ваших пользователей.

Обычно, получение другого сервера с говорит, что 20 ТБ доступной пропускной способности в месяц стоят намного меньше, чем CDN обвинит Вас за тот же объем трафика (хорошо, это происходит, вероятно, быстрее из-за распространения CDN, но это не более дешево в любом случае),

Так или иначе я экспериментирую со следующей установкой (прокомментируйте это, если Вы думаете, что у меня может быть что-то не так здесь),

Имейте www.server.com, выполняет весь материал php/mysql и служат всем статическим файлам (изображения, CSS и т.д.) из static.server.com. (я установил все адреса базового URL на переменных, таким образом, я могу изменить их на желании) На static.server.com будет переписать правило проверить, существует ли изображение локально и, в противном случае принесите его от www.server.com до сценария оболочки/scp/rsync команда. Затем в следующий раз, когда это будет требоваться, это уже будет там. Так, никакая секунда переписывают правило, будет необходим для того определенного изображения/файла. У Вас всегда будет опция просто заменить ту одну переменную, которая содержит путь к Вашему статическому содержанию, и служите всему со своего основного сервера снова. Изображения будут там также.

Таким образом, вызовы изображения переходят непосредственно к моему статическому серверу и всем другим, материал переходит к php/mysql один. Если Вы не выполните php на статическом сервере, то процессы не станут очень большими, таким образом, у Вас сможет быть намного больше серверов, работающих параллельно для обслуживания изображений, и он не съест пропускную способность основного компьютера.

Если Вы видите, что так много ЦП пропадает зря на Вашем статическом сервере, можно всегда перемещать mysql туда также, таким образом, можно сбалансировать загрузки между двумя.

Для примера на вышеупомянутом можно проверить это (это - почти то же:)

http://mrphp.com.au/code/image-cache-using-phpthumb-and-modrewrite

Править: Я говорю об использовании двух отдельных серверов здесь (и физически расположенный достаточно близко в случае, mysql идет на другой сервер),

Другая вещь я должен прибавить вышеупомянутое, состоит в том, что у Вас может быть запись DNS на точке static.server.com в том, какой бы ни сервер Вы хотите. (даже то же как остальная часть приложения). Таким образом, можно трудно кодировать адрес статического содержания к, например, static.server.com/image1.jpg. Применение вышеупомянутого решения просто требует для установки записи DNS для указания на домен static.server.com на машину кэша.,