23 января 2021 в 8:34
Трафик сайта стал стабильно превышать 50 ГБ в месяц, что у ра-дона сто́ит 1300 рублей. Сумма не то чтобы напрягает, но заставляет задуматься об оптимизации.
90% трафика составляют jpg-файлы, то есть по факту проходит мимо друпала. Суммарный объем jpg-файлов на сервере порядка 20-25 ГБ.
Возникла мысль проработать хранение всей этой мультимедии не на ра-доне, а на некоем отдельном хостинге, на мультимедию заточенном.
Вопрос: кто-нибудь имеет реальный опыт такого распределенного хостинга? Имеет ли смысл при моих объемах, или только геморроя нового наживу при сомнительной экономии?
Комментарии
У радона есть тарифы без учета трафика, а по месту на диске.
Хотя с такими условиями пора бы уже про VPS задуматься, я думаю
А там то же самое по деньгам получится, так как в 25 ГБ диска я уже не влезу, а 50 (хоть такого тарифа и нет на сайте), думаю, будет стоить примерно столько же.
VPS не хочу, ибо лавры сам-себе-сисадмина меня нисколько не прельщают. Не люблю и не умею админить линукс с нуля, меня полностью устраивает поддержка и инфраструктура ра-дона.
Ну тут или платить радону или переезжать на VPS, других вариантов я не вижу. Платить кому-то всё равно придется, никто ваши данные у себя бесплатно хранить не будет
Что мешает файлы перенести на амазоновский S3? Цены там довольно демократичны для хранилищ.
Само собой, просто возможно платить придётся меньше.
Отсутствие опыта. Поэтому и спрашиваю совета у тех, кто это реально делал. Например, почему именно Amazon, а не, скажем, Google или Яндекс?
У меня крутится EC2 t2.nano на AWS, а с S3 не сталкивался пока.
Интересно какие подводные камни могут быть при хранении картинок на отличном от Друпала сервере. Насколько хорошо сам Друпал поддерживает такую конфигурацию (картинки загружают юзеры через Друпал, и для них ничего не должно измениться). Насколько легко мигрировать существующие картинки в облако, при этом не потеряв позиции в гугле.
Еще раз, интересует мнение тех, кто это реально делал, а не тех, кто что-то читал про это в интернете.
Эту проблему может решить CloudFlare (или какой-нибудь другой CDN). Это будет прозрачно для Drupal.
Единственный минус - лаг кеша. Но статика редко меняется, и обычно, это не проблема.
Если сайт довольно статичный, можно даже не только статику кешировать, но и страницы, получится что-то вроде boost, но на стороне cdn, для CF есть https://www.drupal.org/project/cfpurge позволяющий селективно этот кеш чистить. Если ещё работает, конечно - API СF менялся. При этом что-то меняющееся часто, можно из кеша исключить в настройках CF.
В принципе, это всё будет работать даже на бесплатном аккаунте СF, если не пытаться делать что-то сложное(ограничение кол-ва правил в конфигурации).
Ну и плюсом защита, WAF с преднастройками для Drupal, защита от DDоS намного более работоспособная чем у 99% хостеров.
А минусом иногда ложно-позитивные срабатывания защиты, и показ пользователю промежуточной страницы.
Связываться ради такого с амазоном идея плохая. Вообще амазон с его крайне не очевидным биллингом стоит использовать только там, где это реально необходимо, и когда знаешь точно, что делаешь и как это там надо правильно организовать, и сколько это может в итоге стоить.
Он не панацея совсем, а то и большой болью может стать...
S3 можно использовать как хранилище внешнее, но использовать его для уменьшения трафика, ну так себе идея.
Отличная идея, посмотрю в эту сторону.
Картинки довольно интенсивно загружаются, но весьма редко удаляются или заменяются, так что это совсем не проблема.
Да не вижу смысла, по крайней мере на данный момент. Со страницами нет проблем, кроме того они обновляются достаточно часто и непредсказуемо.
По идее если я закэшу всего две директории, это должно снизить трафик в разы.
WAF вроде только в платном плане, а он стоит в месяц чуть больше чем я плачу Радону, так что смысл экономический теряется.
Спасибо!
Да, верно, он начиная с Pro. Давно уже не пользовался Free.
S3 бывает не только амазоновский. Модуль s3fs позволяет работать с любыми s3-совместимыми хранилищами. Такие хранилища есть у любого уважающего себя провайдера. Даже если законодательно надо хранить всё в какой-то определённой стране, то и там найдётся свой провайдер s3.
Почему рекомендую s3? Всё просто: де-факто это один из самых распространенных стандартов. Не проблема найти мануал. Отличная интеграция как с 7, так и с 8 версией друпала. Можно легко развернуть своё s3-хранилище на локалке, чтобы не гонять тестовый контент в облако.
У нас у одного из клиентов общий объем картинок уже пошёл на сотни гигов, мы всё это дело перетащили в s3, в итоге экономия для заказчика оказалась около 3000$ в год.
S3 - это зарегистрированный трейдмарк Амазона
Вот это другое дело
Посмотрел. Если правильно понял, файлы картинок хранятся в облачной фс, но всё равно доступны по адресам /sites/default/files, то есть запрос все равно прилетает на друпаловский сервер, тот достает файл из облака и отдает клиенту. Я вижу удвоение трафика моего сервера вместо экономии, или что-то не так понимаю?
Нет, все урлы картинок ведут на облако. Только стили в первый раз открываются специальным роутом, а потом берутся из облака. Хотя у меня никогда не было задачи уменьшить трафик. Но думаю, очевидно, что он уменьшится. У нас же в основном экономия была в том, что сервак на 10 гигов дешевле, чем на 20, а цена хранилища значительно меньше разницы в цене серверов.
Тогда потенциально интересно. Но я всё же хочу сначала попробовать с CloudFlare ибо там вообще практически ничего ставить и делать не надо, да ещё и бесплатно, прям не верится
Там и по трудоёмкости меньше, надо пробовать.
Подключил CloudFlare (далее CF), делюсь первыми впечатлениями.
Сразу после переключения DNS серверов на CF сайт стал недоступен - too many redirects. Выяснилось, что по умолчанию CF сам отзывается по HTTPS, а далее связывается с вашим сервером по HTTP (это у них называется SSL/TLS encryption mode: Flexible). Если на вашем сервере стоит принудительный редирект с HTTP на HTTPS (как было у меня и, я подозреваю, у многих) получается бесконечный цикл редиректов. CF советует либо убрать редирект на сервере (мне не слишком нравится это решение, так как CF приходит и уходит, и каждый раз править под него .htaccess некомильфо), либо переключить на самом CF SSL/TLS encryption mode на Full (тогда коммуникации между CF и вашим сервером тоже делаются по HTTPS). Так и сделал, заработало.
Второе и самое для меня важное: как можно было сразу догадаться, CF заменяет исходные IP-адреса посетителей на свои собственные. В результате любая аналитика, основанная на логах веб-сервера (типа awstats) накрывается медным тазом. Что с этим делать я пока не придумал. В принципе есть приблуда для Apache, но на шаред ее не поставить, нужен VPS, которого я не хочу по ряду причин.
Добавлю: если у вас в настройках веб-сервера (.htaccess etc) были специфичные отлупы/редиректы по IP посетителя, то они тоже перестанут работать.
Скорее всего оригинальный IP-адрес приходит каким-то специальным заголовком, вроде того, как это происходит при использовании реверс-прокси.
Именно так, но чтобы вытащить этот заголовок в лог, нужно модифицировать глобальный Apache, на что хостер конечно же не идёт.
Задача ограничения доступа по IP через .htaccess решается просто:
RewriteCond %{HTTP:X-FORWARDED-FOR} !^(xxx\.xxx\.x\.xx|yyy\.yy\.y\.yy)Нужно иметь в виду, что значение X-FORWARDED-FOR может содержать список IP-адресов, из которых первый - оригинальный адрес клиента, а дальше адреса последовательных прокси, которых теоретически может быть сколько угодно. Но так как нам обычно интересен первый, это упрощает дело.
Еще одно наблюдение: если у вас стоит какой-нибудь автобан при попытке доступа к стрёмным путям типа payload.php, то его лучше выключить, пока он не забанил весь пул адресов CloudFlare
Он тоже должен работать не по ip CF, а по первому ip в X-Frowarded-For. И будет ок.
Это если он умеет. У меня используется (использовался) Http:BL, и я не вижу чтобы он так умел.
Если он так не умеет, то он просто откровенно плохо сделан.
Правильный алгоритм - посмотреть на наличие x-forwarded-for, если не пуст достать адрес оттуда, если нет, взять REMOTE_ADDR. Большая часть сайтов за какими-нибудь reverse-proxy... Очень странно, если в такого рода модулях это не учитывается.
PS Оказывается есть целый модуль CloudFlare, он в числе прочего должен и IP подменять. Посмотрим.
За двое суток процент отдачи из кэша CF поднялся до 9%. Негусто, но пока наверное рано еще - кэш ведь должен заполниться. Настроил срок хранения картинок в кэше CF 1 месяц, дольше не получается, а жаль.
Удручает отсутствие простой документации для начинающих: есть миллион настроечных параметров, в описании которых я половину слов-то не понимаю, а простого и внятного описания что конкретно я должен сделать чтобы все мои картинки закэшировались навсегда - нет.
Процент трафика или разнообразных запросов?
Трафика:
Bandwidth Saved
Last 24 hours
9%
194.27 MB saved
2.24 GB total bandwidth
Поставил модуль CloudFlare, IP-адреса в логе Друпала стали подменяться на настоящие, но там от них толку особого и нет. Отсутствие реальных адресов в логах веб-сервера удручает очень.
За четверо суток клаудфлейринга процент трафика, отдаваемого из кэша... снизился до 7%, что совершенно непонятно. Из пятидесяти картинок-тамбнейлов на главной странице, которые по идее видят все, заходящие на главную страницу, закэшено менее 30 процентов. Из этих же картинок в полном размере, открываемых по клику, не закэшена ни одна.
На данный момент результат (7% экономии трафика) никак не оправдывает затраченных усилий (которые оказались не совсем нулевыми).
Продолжаю наблюдение.
А что там по размеру кэша на бесплатном тарифе? Может он вытесняется?
А это нигде не написано, по крайней мере я не нашел. Но по всему похоже, что размер кэша ограничен примерно 200 мегабайтами, что в моем случае просто смешно.
Это не так. Проблема возможно в заголовках и времени кеширования.
Стоит почитать вот это: https://support.cloudflare.com/hc/en-us/articles/200172516-Understanding...
Также, посмотреть заголовки своих картинок. Будет понятно, почему и что не попадает в кеш, или что происходит вообще.
Читал конечно же. По умолчанию max-age в заголовках стоял на две недели, поставил месяц, но и с двумя неделями должно было быть получше чем 7% за четыре дня наблюдений.
Пытаюсь решить проблему с логами сервера. В веб-интерфейсе самого CloudFlare никакого намека на просмотр логов (для бесплатных пользователей) нет, в поиске по сайту намеки на logs появляются только в документации для Enterprise-пользователей. Однако в разделе Apps промелькнула реклама некоего приложения LogFlare (без рекламы я бы его в жизни не нашел), которое забесплатно (до 5 млн записей в месяц) вытягивает логи из CloudFlare (получается, что по API они вполне доступны даже для бесплатных юзеров), хранит их 7 дней (за деньги можно дольше, также можно складывать в собственное хранилище Google BigQuery) и весьма удобно показывает - с поиском, фильтрацией и т.п. Только начинаю разбираться, но похоже проблему с логами сервера это решает.
Вот что нашёл:
Вот отсюда
Это не суммарный размер кеша, а максимальный размер отдельного файла. С такими лимитами сложно столкнуться, если не размещать видео какое-нибудь.
Точно. Затупил. Но ещё там же есть про заголовки Cache-Control. И что без них по умолчанию кэшируется на 2 часа.
Ага-ага. Как раз про это писал.
Всё чудесатее и чудесатее
После запуска LogFlare процент отдачи из кэша твёрдо установился на 100%!
Очевидно, что это неправда - в самом LogFlare отчетливо видно, что большинство ответов идут с кэш-статусом MISS или DYNAMIC, HIT попадаются редко. Что я опять сделал не так?
У них там квантовый компьютер по ходу, поэтому результат эксперимента зависит от наличия наблюдателя
Списался с автором LogFlare - говорит, известный глюк CloudFlare, они в курсе уже более года и ничего не делают. Весь этот дашборд можно реализовать внутри LogFlare с использованием Google Data Studio, но оно уже платное, и как-то слишком заморочисто это всё...
А почему бы не использовать для аналитики бесплатные решения, не основанные на логах сервера?
Потому что любые решения, не основанные на логах, основаны на джаваскрипте и, следовательно, в упор не видят очень многого, что нужно мне: доступа к файлам/картинкам, всяких ботов, скрейперов и прочую нечисть и т.д.
А зачем это всё?
Зачем знать полную и точную статистику обращений к серверу? Из любопытства, естественно.
Прошло две недели экспериментов с CloudFlare. Результат пока скорее отрицательный: средний процент закэшированного трафика около 10%, и явной тенденции к росту нет. Кроме того, вскрываются все новые и новые неприятные моменты: у меня на сайте через htaccess организована нехитрая защита от хотлинкинга: если мою картинку кто-то вставляет в свою страницу (домен реферера не мой и не Гугл с Яндексом), вместо искомой картинки отдается картинка с надписью, что так делать нехорошо. Сегодня заметил эту картинку на своем собственном сайте: кто-то зашёл на страницу с хотлинком, получил от моего сервера картинку с предупреждением, cf ее закэшил и теперь отдает всем
У cf есть своя защита от хотлинкинга, но она крайне тупая и вообще никак не настраивается: с ней на Гугле с Яндексом мои картинки тоже не будут показываться.
Прошло больше трёх недель. Процент закэшированного трафика около 12%. Наверное можно считать эксперимент неудавшимся и начать всё же исследовать xранение картинок в S3-совместимом хранилище. Посмотрел бегло на предложения в этом сегменте, пока импонирует Digital Ocean.
Что-то очень не так с настройками кеширования, если такая ситуация. Если основу трафика составляют картинки, то ситуация должна быть кардинально другой.
Возможно запросы равномерно распределены по большому хранилищу и за время жизни кеша, просто не успевает в него пройти повторных запросов. Тогда надо поднимать время жизни кеша.
Сначала создал 2 page rules таких:
Cache Level: Cache Everything, Edge Cache TTL: a month
Cache Level: Cache Everything, Edge Cache TTL: a month
Месяц - это максимальное Edge Cache TTL, которое можно выставить.
После того, как в течение дней десяти это не привело ни к какому результату, решил что настройки по умолчанию (respect origin headers) ничем не хуже. Заголовки, отдаваемые сервером для картинок, сейчас такие:
cf-cache-status: MISS
date: Mon, 22 Feb 2021 12:53:52 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expires: Sun, 23 May 2021 12:53:52 GMT
После включения CF процент трафика сервера, который составляют файлы jpg, ПОДНЯЛСЯ с 89% до 92%
PS Обратил внимание, что в заголовке max-age не прописано в явном виде public. Откуда этот заголовок берётся вообще не очень понятно, так как в htaccess в явном виде прописывается только Expires.
Наверное для полной чистоты эксперимента следовало бы попробовать с Cache-control: public, max-age=xxx, но я что-то с ходу не соображу как это сделать в htaccess для картинок, при этом не поломав заголовки ресурсов, генерируемых друпалом.
Добавил в cache-control public, сначала показалось, что коэффициент кэширования пошел вверх, оказалась случайная флуктуация, сейчас даже ниже, чем неделю назад. Ну что ж, нет так нет.
Вот довольно похожий кейс, только с куда большим трафиком (60ТB в месяц), и немногим большим суммарным объёмом(до 40GB). Тоже бесплатный аккаунт на CF.
Так что продолжаю настаивать, что что-то было совсем не так у вас настроено.
В данном случае, статика в одной папке, и использовано одно Page rule, для включения принудительного кеширования и установки максимального TTL на edge серверах, для соответствующего /url/*.
Вот это принципиально. С таким трафиком уже даже неважно, насколько он географически распределен. А мой трафик практически равномерно размазан по глобусу. Вот тут обсудили и вроде как нашли причину:
https://community.cloudflare.com/t/why-is-my-percent-cached-so-low/251019
Настаивать, что "что-то не так" несложно. Сложнее указать что именно, и как сделать "так"
CF у меня пока не отключен, и я открыт для экспериментов.
То, что обсуждалось в том топике я выше писал уже, но чтобы это было так, должно бы быть уж очень равномерное распределение запросов по всем картинкам, и это уж очень мало вероятный сценарий для веб сайта. И 10% конечно очень плохой, и мало вероятный результат.
Впрочем, это же можно проверить если вести статистику запросов.
Чтобы указать на то, что именно не так, надо заняться анализом. Посмотреть на страницы, посмотреть на заголовки ответов. Точно-ли вообще всё то, что надо, пытается хотя бы закешироваться? И.т.п. Это время, которое я всё же не готов вот так просто потратить. А вот поделиться опытом - пожалуйста.
P.S. То, что там писали о оптимизации изображений, очень правильная мысль, кстати. Это конечно надо сделать вне зависимости от CDN. Это и трафик уменьшить может, и размер хранилища, и пользователям лучше.
Оно близко к тому - большинство посетителей приходят с Гугла по очень разным запросам и попадают в очень разные места сайта. Единственная страница-исключение - это фронт-пейдж, но там не так уж много всего.
Логи сервера имеются, что именно нужно проверить? Тут достаточно нетривиальный анализ нужен, в логе за январь (до включения CF) около миллиона записей.
Да я не спорю, я этим занялся уже, сделал интересные открытия. У меня styled-картинки занимают примерно треть места на диске от всех картинок, две трети - full-screen оригиналы. Исходя из этого я раньше оптимизировал только full-screen картинки в соответствии с pagespeed insights. При этом я давно и специально переключился на ImageMagick toolkit чтобы сохранялся EXIF, из которого я извлекаю дату съёмки при загрузке фото. Так вот, при анализе логов выяснились две интересные вещи:
1. Доля styled-картинок в трафике заметно больше, чем на диске (хотя все равно меньше чем трафик оригиналов).
2. EXIF занимает несуразно большое место в маленьких styled-картинках, причем там-то он точно не нужен. Вычистил EXIF из всех styled картинок, освободил 2ГБ из 6.5.
Из оригиналов EXIF пока не решился вычищать, но и так очевидно, что в процентном отношении огромной экономии не будет.
Это не много совсем, на самом деле.
Для анализа есть разные анализаторы логов. Надо смотреть запросы в разрезе по url.
Для экселя многовато, awstats от провайдера статистику по картинкам не даёт, больше ничего нет под рукой
Посоветуете годный анализатор под винду, чтоб не тратить полдня на гуглоисследования, пробы и ошибки?
Не пробовал ни один запускать под виндой, честно говоря...
В общем, проанализировал - какая-то вот такая загогулина получается (в каждой строке суммарный трафик картинок, скачанных указанное количество раз за месяц):
1 4 458 853 8,1%
2 5 770 485 10,5%
3 5 574 335 10,1%
4 4 860 062 8,8%
5 4 045 931 7,3%
6 3 149 902 5,7%
7 2 696 089 4,9%
8 2 143 839 3,9%
9 1 860 047 3,4%
10 1 783 835 3,2%
11 1 495 179 2,7%
12 1 250 637 2,3%
13 1 185 654 2,2%
14 1 005 493 1,8%
15 790 324 1,4%
16 773 808 1,4%
17 668 413 1,2%
18 501 254 0,9%
19 422 164 0,8%
20-49 5 401 784 9,8%
50-99 1 831 102 3,3%
>=100 3 437 661 6,2%
Total 55 106 851 100,0%
Конечно, для более точного анализа нужно принимать в расчет географию каждого хита вплоть до конкретного Edge сервера CF, но у меня нет возможности это сделать. Навскидку, исходя из общей географии запросов, готов поверить, что файлы с количеством хитов до 10 запросто могут размазаться по разным Edge серверам.
