Серверная оптимизация *

Настоящий админ может спать спокойно лишь тогда, когда у него всё бэкапится, мониторится и дублируется. Или когда он работает в хорошей команде, где всегда можно свалить вину на другого.
Так получилось, что я в своей работе использую в основном продукты Microsoft и могу сказать, что компания серьезно подходит к резервированию своих сервисов: Active Directory, Exchange DAG, SQL Always On, DFSR и т.д. Как и везде, здесь есть как весьма изящные и удачные реализации, так и явно неудобные и тяжелые. Для сервиса печати тоже есть решение, но для него необходима кластеризация на базе Hyper-V. А хотелось простого решения “из коробки”, не требующего дополнительных финансов. За основу была взята Windows 2012 R2, но скорее всего та же схема без проблем будет работать на любых серверных версиях, начиная с Windows 2008, и даже клиентских ОС от Vista и выше (привет любителям экономить бюджет!). Кому интересно — прошу под кат.

Краткая предыстория: моя прошлая заметка описывала подход к хранению и выборке данных, на котором можно построить конструктор приложений — альтернативу современным платформам разработки, но без необходимости программирования. Изобретение это потенциально может перевернуть весь мир IT, каким мы его знаем.

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

Разумеется, статья вызвала большое количество вопросов, которые необходимо осветить отдельно: отличие от существующих решений и сравнительный анализ производительности и планов построения запросов к базе данных. А также ответить на вопрос: что это вообще такое и зачем?

Здравствуйте, меня зовут Дмитрий Карловский и я… не люблю читать книги, потому что пока перелистываешь страницу, ты вырываешься из увлекательного повествования. И стоит чуть замешкаться, как ты забываешь на чём оборвалось последнее предложение предыдущей страницы, и приходится листать обратно, чтобы перечитать его. И если с физическими книгами это не так страшно, то вот с выдачей rest-сервера всё куда печальней — ведь сейчас на странице одни данные, а через секунду — уже совершенно другие. Давайте подумаем как же так получилось, кто виноват и главное — что делать.

Когда-нибудь трассировали рантайм вашего приложения? Знаете сколько запросов делает вон тот серый ендпоинт, который? А как долго вычитываются те кросс-референсы на схожий тип ресурсов с каждой странички сущностей, которую нужно вернуть в запрос? Пытались ли вы замерить как долго приходится ждать пользователю из-за опциональных полей запроса, которые он время от времени добавляет? Задумывались ли вы что будет если запараллелизировать эти шесть запросов к тем двум базам данных?

Если что-нибудь выше звучит интересно, или как минимум знакомо — добро пожаловать под кат.

Наши клиенты в Fastly любят манипулировать заголовками HTTP. Подбор правильной комбинации заголовков — одна из лучших вещей, какую вы можете сделать для безопасности своего сайта и значительного вклада в его производительность.

Большинство разработчиков знают о важных и нужных HTTP-заголовках. Самые известные — Content-Type и Content-Length, это почти универсальные хедеры. Но в последнее время для повышения безопасности начали использоваться заголовки вроде Content-Security-Policy и Strict-Transport-Security, а для повышения производительности — Link rel=preload. Несмотря на широкую поддержку в браузерах, лишь немногие их используют.

В предыдущей статье мы рассмотрели ненужные заголовки. Сейчас разберёмся, какие заголовки действительно следует настроить для своего сайта.

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

Большинство разработчиков знают о важных и нужных HTTP-заголовках. Самые известные — Content-Type и Content-Length, это почти универсальные хедеры. Но в последнее время для повышения безопасности начали использоваться заголовки вроде Content-Security-Policy и Strict-Transport-Security, а для повышения производительности — Link rel=preload. Несмотря на широкую поддержку в браузерах, лишь немногие их используют.

В то же время есть много чрезвычайно популярных заголовков, которые вообще не новые и не очень полезные. Мы можем это доказать с помощью HTTP Archive, проекта под управлением Google и спонсируемого Fastly, который каждый месяц при помощи WebPageTest скачивает 500 000 сайтов и выкладывает результаты в BigQuery.

Этой весной мне удалось, наконец, реализовать давнюю мечту строителей конструкторов: встроить среди американских патентов четвертьвековой давности очень простое решение всех их проблем. По сути — это эмуляция базы данных приложения, при построении которого вся черновая, рутинная работа программиста вынесена «за скобки».

В снове решения — система хранения данных и способ их обработки, результат — альтернатива существующим ORM. Заявленные преимущества: повышение надёжности базы данных за счёт минимизации ошибок при добавлении новых данных и формировании запросов к ним, а также снижение риска лавинообразной деградации производительности при работе с большими объемами данных (с любыми объемами).

Оно не меняет принципиально структуру физического хранения данных, в нем всё происходит точно так же, как в обычном приложении с базой данных: информация хранится на носителе, она фрагментирована, со временем фрагментация увеличивается. При запросах данных так же происходит множество чтений разрозненных фрагментов информации с диска.
Больше того — это может работать в обычной реляционной БД.
Но есть нюансы.

В современных сервисах без кэша никуда: доступ к данным в персистентной базе – дело долгое и затратное, поэтому добавление промежуточного хранилища для наиболее часто используемых данных значительно его ускоряет. Держать в кэше информацию можно самую разную и в разной форме: и строки, и списки, и состояние сессии, и многое другое. В данной статье речь пойдёт об одном из способов хранении в кэше «плоских» объектов, не имеющих вложенных классов и циклических ссылок.

В прошлой статье «Меньше администраторов всем» я рассказывал о принципах работы без прав администратора ― в частности, о технологии Just Enough Administration (JEA). Этот механизм хоть и гибкий, но сложный в настройке, и в ряде ситуаций можно обойтись и без него.

Например, если в бухгалтерии используется регулярно обновляемое ПО, то совершенно не обязательно выдавать права администратора, использовать сторонние решения вроде AdminLink и тем более обновлять руками. Есть другие варианты.

Нам часто задают вопрос, как развернуть кластер на Splunk. У многих пользователей в процессе эксплуатации возникает потребность перехода от standalone к конфигурации кластера, которая обеспечивает устойчивую систему хранения и индексации данных, а также постоянную доступность данных, которая не будет зависеть от сбоев в работе оборудования. И поэтому, в рамках данной статьи мы расскажем, как развернуть Indexer кластер на Splunk, который позволит постоянно иметь доступ ко всем хранящимся данным, даже если упадет один из индексеров.

В это статье будет сделан обзор возможностей модуля Nchan веб-сервера nginx, который заменил deprecated модуль NGiNX_HTTP_Push_Module. Модуль Nchan поддерживает основные технологии отправки сообщений Websocket, EventSource (Server-Sent Events), Long-Polling. Для горизонтального масштабирования используется кластер серверов redis.

Joomla очень плохо переваривает базу данных даже с несколькими тысячами статей в таблице _content. При нескольких десятках тысяч запросы в базу стандартных модулей типа mod_articles_popular могут зависать на секунды.

Всё дело в ACL (Access Control List) — политике контроля доступа. Проверка законности доступа пользователя к материалам занимает свыше 98% времени выполнения запроса.

Netflix уменьшил время аварийного переключения с 45 до 7 минут без каких-либо затрат

Изображение: Florida Memory. Доработано Opensource.com. CC BY-SA 4.0

Зимой 2012 года Netflix пережил длительный сбой, уйдя в отключку на семь часов из-за проблем с сервисом AWS Elastic Load Balancer в регионе US-East (Netflix работает на AWS — у нас нет собственных дата-центров. Всё ваше взаимодействие с Netflix происходит через AWS, кроме самого потокового видео. Как только вы нажмете Play, начинает загружаться видеопоток из нашей собственной сети CDN). Во время сбоя ни один пакет из региона US-East не доходил до наших серверов.

Чтобы такого больше не повторилось, мы решили создать систему аварийного переключения, устойчивую к сбоям базовых поставщиков услуг. Аварийное переключение (failover) — это система обеспечения отказоустойчивости, когда в случае сбоя основной системы автоматически активируется резервное оборудование.

Наверняка вы часто замечали, сколько всякого мусора лежит внутри node modules. Это тесты, бенчмарки, ридми файлы, лицензии, тайпскрипт, и ещё безумное количество мусора, который можно более-менее безопасно удалить. Что мы собственно и сделаем в этом посте.
Картинку про вес node module я и так упоминал последние несколько публикаций, так что вот вам другая, которая в целом отражает текущую ситуацию. В качестве саундтрека к посту рекомендуется Little Big, “Life in da trash”.

Несколько дней назад компания Splunk выпустила новый релиз своей платформы Splunk 7.1 в котором, наверно, произошло самое ожидаемое изменение за последние несколько лет — да, полностью изменился графический интерфейс. В этой статье мы расскажем об основных нововведениях и улучшениях платформы. Что еще нового помимо GUI? Смотрите под кат.

Фото: Jesse Darland с Unsplash

В этой статье речь пойдёт о том, как перенести процесс предварительной обработки изображений с сервера приложений на абсолютно бессерверную архитектуру платформы AWS.

Проект Accelerated Mobile Pages (AMP) от Google вызвал определённый переполох по идеологическим причинам, но саму технологию так и не разобрали подробно. Несколько недель назад Ферди Кристант писал про несправедливое преимущество, которое получает контент AMP за счёт предзагрузки. Это заставило меня задуматься: насколько хорошо AMP работает на самом деле? Я видел тесты как у Ферди, когда сравнивались одна или две страницы, но ещё не встречал всесторонних объективных тестов.

Оценить производительность AMP на самом деле не так просто, чем кажется. Нужно рассмотреть по крайней мере четыре контекста:

1. Насколько хорошо работает AMP в контексте поиска Google?
2. Насколько хорошо работает библиотека AMP как автономный фреймворк?
3. Насколько хорошо работает AMP при загрузке из кэша?
4. Насколько хорошо работает AMP по сравнению с каноническим документом?

Иногда мы хотим поделиться с друзьями частью какого то видео на YouTube — время концентрации внимания в современной реальности снижено до предела, и если скидывать ссылку на ролик(даже с таймкодом начала) с комментарием «смотреть с 21:51 по 24:55» — велика вероятность, что видео просмотрено не будет.

Кроме того — куски видео могут потребоваться для монтажа своих роликов — и довольно неудобно скачивать ради нескольких секунд весь ролик и искать/вырезать нужную часть в программе для монтажа.

Как загружать часть видео YouTube при помощи ffmpeg — под катом

Не так давно мы публиковали статью Сравнение производительности процессоров Intel разных поколений, в которой представлены результаты тестирования 8-ядерных процессоров Intel Xeon E5. С тех пор, по акции, было продано несколько сотен серверов на базе процессоров V1/V2, которые стали достойным аналогом E5-2620V4/2630V3 в таких задачах как: сервер баз данных, терминальный сервер, видеонаблюдение и пр. Но, к сожалению, модельный ряд был ограничен только 2-процессорными платформами, что накладывало дополнительную финансовую нагрузку при использовании 1-процессорных конфигураций. Большое количество запросов побудило нас разработать бюджетную модель 1-процессорного сервера/рабочей станции, которая должна существенно выигрывать по производительности у платформ на базе Xeon E3/Core i7, и при этом конкурировать с ними по цене.

Поисковые системы намеренно, а пользователи — интуитивно оценивают сайты по времени загрузки, а не только по качеству и релевантности контента. С недавнего времени важен стал также показатель скорости мобильной версии сайта. Но, в отличии от контента, за этими параметрами следить сложнее, особенно если целевая аудитория выходит далеко за пределы родного (для хостинга) города. Эта публикация опишет, как это все же можно сделать, используя сервис мониторинга сайтов ХостТрекер, и рассмотрит одно из возможных решений проблемы.