Мы пытаемся еще больше повысить скорость некоторых сайтов со старым HTML, чтобы получить лучшие результаты SEO. Теперь мы применили некоторые меры минимизации, комбинированные html, css и т. Д. Мы используем небольшую виртуализированную инфраструктуру, и мы всегда хотели использовать легкую + стандартную конфигурацию http-сервера, чтобы первый мог обслуживать изображения и статическое содержимое, а другой - php , перезаписывает и т. д. Теперь мы можем легко сделать это с виртуальной машиной, использующей те же файлы и конфигурацию vhosts (привязка монтирования) на apache, но почти без загруженных модулей. Это означает, что световой httpd будет иметь меньший отпечаток пальца, что позволит нам обслуживать больше и быстрее, работать больше minSpareServer и т. Д.
Итак, поскольку браузеры также выигрывают от загрузки статического контента с разных имен хостов, мы подумали о создании правила перезаписи на нашем основном сервере (main.com) для «перенаправления» всех изображений и css * .jpg, * .gif, * .css и т. д. на то же самое на, скажем, cdn.main.com, таким образом, браузер может иметь больше соединений.
Вопрос в том, если у нас уже есть очень сложный набор правил перезаписи (мы вручную манипулируем многими старыми URL-адресами для SEO), стоит ли оно того?
Я имею в виду, будет ли дополнительная нагрузка основного apache перенаправлять main.com/image.jpg (я понимаю, что нам нужно сделать 301) на cdn.main.com/image.jpg +, затем cdn.main.com, имея чтобы обслужить его, быть больше, чем выгода, которую мы архивируем в браузере?
Может ли Google наказывать за превышение 301-й секунды всех изображений на странице?
Как крупные компании справляются с этим, включает ли исходный код уже изображения, связанные с cdn с абсолютными путями?
РЕДАКТИРОВАТЬ Чтобы уточнить, мы не заботимся о производительности сервера или пропускной способности. Очевидно, мы могли бы использовать внешний CDN-сервер, но у нас достаточно ЦП и пропускной способности.
Мы заботимся о том, чтобы «старые» сайты с большим количеством полустатического HTML-контента получали выгоду от разделения соединений для изображений и статического контента через apache без необходимости изменять html на абсолютные пути (например, image.jpg на cdn.main.com /image.jpg происходит на сервере, а не код)
для перенаправления main.com/image.jpg (я так понимаю, нам придется сделать 301) на cdn.main.com/image.jpg
Это плохая идея, не делайте этого.
Трудно понять ваш длинный вопрос. Насколько я понимаю, вы беспокоитесь о загрузке сервера, а не о том, как быстро сайт загружается для ваших конечных пользователей.
Если вас беспокоит емкость сервера:
таким образом, браузер может иметь больше соединений.
Ограничение параллельной загрузки в браузере - это отвлекающий маневр - современные браузеры загружают 6-8 файлов параллельно с одного и того же имени хоста. Только старые браузеры (IE6, IE7) действительно страдают от этого ограничения.
Если вас беспокоит скорость загрузки страницы конечного пользователя, используйте CDN, это хороший совет во всех ситуациях, когда ваши пользователи разбросаны по большой географической области (то есть у вас глобальная аудитория).
301 сек всех изображений на странице оштрафованы Google?
Возможно. Но, скорее всего, ваши пользователи его возненавидят. Для каждого запроса изображения вы сначала обслуживаете 301, а затем правильное изображение с другого URL. Это означает, что для каждого изображения нужно дважды обращаться к серверам и, следовательно, значительно увеличивать время загрузки страницы для ваших пользователей.
Обычно получение другого сервера с, скажем, 20 ТБ доступной пропускной способности в месяц стоит намного меньше, чем CDN будет взимать с вас такой же объем трафика (хорошо, это, вероятно, быстрее из-за распространения CDN, но это не дешевле в любом случае )
В любом случае, я экспериментирую со следующей установкой (прокомментируйте, если вы думаете, что у меня здесь что-то не так)
Есть www.server.com запускать все файлы php / mysql и обслуживать все статические файлы (изображения, css и т. д.) из static.server.com. (я установил все базовые URL-адреса для переменных, чтобы их можно было изменить по желанию) static.server.com будет правило перезаписи, чтобы проверить, существует ли изображение локально, и, если нет, перенести его из www.server.com с помощью команды оболочки script / 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 на вашу кэш-машину.,
Я занимаюсь подобным вопросом в своей компании последние несколько недель. Следует иметь в виду пару вещей: