Назад | Перейти на главную страницу

Akamai против меньшего CDN для малого / среднего трафика электронной коммерции? (кеширование, задержка, NetStorage)

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

Ежемесячный трафик составляет около 3 миллионов просмотров страниц и 400 тысяч уникальных посетителей. У нас есть более 100 тысяч различных статических изображений, которые появляются на наших различных веб-страницах (несколько разных изображений для каждого из нескольких тысяч товаров и т. Д.).

Проблема в том, что серверы Akamai запрашивают файлы с исходного сервера (который мы размещаем сами) примерно для 40% всех запросов браузера. Это означает (на мой взгляд) много ненужного ожидания для наших клиентов: 40% всех запросов должны совершать обратный рейс между Akamai и нашим источником, прежде чем возвращаться к клиенту.

TTL сервера не проблема; все они установлены на 365 дней. Так что похоже, что либо

  1. Пограничные серверы Akamai не хранят наши данные в кеше достаточно долго, прежде чем поменять их на контент, который получает более высокий трафик, чем наш, и / или
  2. существует так много пограничных серверов Akamai (они заявляют, что по всему миру более 70 тысяч), что каждый сервер не получает достаточно трафика от наших 450 тысяч посетителей в месяц, чтобы создать большую часть кеша наших файлов.

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

Мы рассматриваем два варианта на основе Akamai, но еще не нажали на спусковой крючок (пока):

Итак, мои вопросы:

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

  2. Если мы перейдем к NetStorage, есть ли у кого-нибудь представление о том, сколько времени обычно занимает круговое обращение к «источнику» NetStorage?

  3. Я что-нибудь упускаю? О чем еще я должен думать здесь?

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

  1. Настройте учетную запись в нескольких сетях CDN, которые выполняют выборку из источника, но имеют модель «super-POP». На ум приходят Amazon CloudFront, MaxCDN и Voxel. CacheFly, возможно, тоже, хотя, я думаю, вы не можете выполнить исходную выборку без привлечения сервисов. LimeLight был пионером в модели «super-POP», но для проведения теста требуется пройти через продажи песен и танцев.
  2. Перенаправьте статистически значимую часть вашего трафика CDN на эти тестовые CDN. Это может быть так же просто, как правило перезаписи, выполняемое n% времени, но «микс контента» должен быть одинаковым для всех CDN. Вы не можете ограничить его подмножеством своих статических активов, поскольку число статических активов также может иметь эффект. Возможно, оставьте 80% трафика на Akamai для теста, а затем сделайте 5% для других CDN.
  3. Используйте журналы своего веб-сервера, чтобы измерить, сколько исходных обращений вы видите из каждого CDN по сравнению с объемом трафика, отправленного на каждый CDN.
  4. Используйте что-то вроде pingdom, чтобы измерить время отклика по всему миру для различных статических ресурсов на каждой CDN. Выгрузка обращений из вашего источника - один из индикаторов того, что CDN выполняет свою работу, но задержка конечного пользователя тоже имеет значение.

Обладая этими фактами, ваше решение будет простым. Как бы то ни было, я думаю, что вы правы: Акамай мог просто иметь слишком много узлов для "небольших" сайтов.

Обратите внимание, что некоторые из более мелких CDN автоматически используют многоуровневую модель для всего; они просто так спроектированы с самого начала. В такой модели запрос к конкретному граничному узлу направляется «внутреннему» узлу при промахе в кэше. "Внутренний" узел затем направляется к источнику, если он также имеет промах в кэше. Мое собственное тестирование показало, что MaxCDN работал таким образом (например, первый запрос файла на узле Amsterdam не всегда приводил к соответствующей выборке источника. Таким образом, он должен был получить файл откуда-то еще внутри сети MaxCDN).

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

Akamai не делает «одно попадание на каждый граничный узел»; они делают несколько ударов, чтобы попасть в свое «облако» и затем распространять оттуда до краев.

Я не работаю в Akamai, но мы перепродаем многие их услуги.

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

Есть ли другие элементы, которые кэшируются, а именно изображения? Любой CSS, Javascript?

У Akamai есть множество доступных опций, помогающих оптимизировать доставку.

Недавно я познакомился с Strangeloop, они предлагают службу сжатия, которая уменьшает количество объектов на странице и сохраняет их в виде шаблонов. Это не замена, а что-то интересное.

Задержка и кеширование приносят пользу друг другу одновременно. NetStorage повысит производительность.

Дайте мне знать, если я смогу помочь, удачи!