С июля 2018 Google начали учитывать скорость страниц в выдаче. В ноябре 2019 года они добавили отчет о скорости страниц в личный кабинет Web Search Console. В июне 2021 они ужесточили критерии PageSpeed, подняв влияние Total Blocking Time (TBT) с 25% до 30% и Cumulative Layout Shift (CLS) с 5% до 15%.
Если вы работаете с сайтом, который постепенно растет, - увеличивается количество товаров, трафик с рекламы - то рано или поздно придется перейти в режим работы highload, высоких нагрузок на сервер. Но что делать, если ваш сайт не растет, а сервер все чаще не выдерживает, и происходит блокировка данных? Именно с этой проблемой мы столкнулись, дорабатывая сайт для интернет-магазина светового оборудования с ассортиментом более чем 100 000 товаров.
Охлаждение оборудования — задача, как известно, важная и нужная. Прогресс не стоит на месте и ищет лазейки для новых эффективных решений, если не сказать открытий!
Решили порадовать вас подборкой неординарных подходов для охлаждения дата-центров:
• майнинговая ферма в Сибири,
• подводный дата-центр компании Microsoft возле Шотландии,
• и даже охлаждение серверов в масляной ванне!
Сегодня я расскажу вам про довольно простую, но интересную реализацию многопоточности в HTTP-сервере без создания потока для каждого клиента. На мое удивление информацию про такую реализацию я нашёл с трудом, поэтому решил поделиться с вами.
Low-precision inference в TensorRT сегодня - мастхэв, бест практис и прочие иностранные. Сконвертить из TensorFlow легко, запустить легко, использовать fp16 легко. Да и КПД выше, чем у pruning или distillation. На первый взгляд всё работает идеально. Но на самом деле всё ли так гладко? Рассказываем, как мы в TrafficData споткнулись об fp16, встали и написали статью.
Сети доставки контента (CDN) в наши дни получили широкое распространение. Это вполне понятно: растёт число интернет-сервисов с глобальной аудиторией, и почти все такие сервисы так или иначе связаны с доставкой тяжелого (фото-, аудио-, видео- и не только) контента.
Число пользователей Интернета, в особенности — мобильного, растёт с каждым днём, и создатели сайтов и приложений вполне закономерно задумываются об обеспечении быстрой работы в любой точке мира. Спрос рождает предложение — и количество компаний, предлагающих услуги CDN, тоже постоянно растёт. Достаточно набрать в Гугле соответствующий запрос — и в поисковой выдаче будет представлено огромное количество рекламных объявлений.
Как выбрать действительно качественного провайдера CDN? На что обратить внимание в первую очередь?
Где поместить свой сервер, чтобы обеспечить максимальную скорость? Помимо времени, необходимого серверам для ответа на запросы, требуется время просто для доставки пакета из пункта А в пункт Б.
Чтобы теоретически определить лучшее физическое место для размещения своего сервера, я объединил общедоступные данные о задержках с собственными журналами доступа к веб-серверу. Я стремлюсь получить грубый, количественный, ответ, основанный на реальном наборе данных.
Определение TTL для некоторых кэшированных данных («time to live» — время существования или длительность хранения) может стать своего рода шарлатанской нумерологией для программистов. Кеширование по TTL даёт корректность в пользу увеличения скорости. Но до какой степени можно отказаться от корректности? Как долго можно показывать где-то неправильное значение, прежде чем пользователь будет сбит с толку? Как скоро такие пользователи заподозрят наличие у себя проблемы и лягут бременем на службы поддержки клиентов? Давайте разбираться.
Хотелось бы поделиться опытом оптимизации данных с целью уменьшения расходов на ресурсы.
В системе рано или поздно встает вопрос об оптимизации хранимых данных, особенно если данные хранятся в оперативной памяти, как это БД Redis.
Как временное решение, можно увеличить RAM тем самым можно выиграть время.
Redis это no-sql база данных, профилировать ее можно с помощью встроенной команды redis-cli --bigkeys, которая покажет кол-во ключей и сколько в среднем занимает каждый ключ.
Объемными данными оказались исторические данные типо sorted sets. У них была ротация 10 дней из приложения.
Проект в продакшене, поэтому оптимизация никак не должна была сказаться на пользователях.
Данные из себя представляли события измененияцены / даты доставки у оффера. Офферов было очень много – порядка 15000 в каждом фиде (прайслисте).
Рассмотрим следующий пример данных события по офферу:
Использование journald как замена syslog'у для приложений с большим числом логов.Давным-давно, когда были дебаты о том, стоит ли принимать в качестве init-системы systemd (с одной стороны удобно, с другой стороны, довольно токсичный автор...), вместе с systemd приехал и journald. В целом, он ощущался как аппендикс к systemd, и вместе с ForwardToSyslog, он мирно жил на серверах. Дефолтная конфигурация в целом устраивала, а всё нужное можно было по-старинке накрутить в syslog'е.
В одном из проектов у нас образовалась потребность в обработке большого числа логов, и мы решили попробовать journald вместо (r)syslog(d|-ng). Оказалось, что:
journald решает все наши проблемы
документации по нему подозрительно мало (особенно, в сравнении с systemd)
при том, что его поведение более-менее разумно, интуиция о том, как он работает, практически отсутствует и её надо набирать.
