Полезноe
бесплатная книга Продуманная оптимизация
Материалы HighLoad++
материалы За все восемь лет вебинар Пошаговый
алгоритм
вебинар Вопросы
и ответы
Презентации
2014 года
Видеозаписи
2014 года
Как это было
книга Услуги и скидки корпоративный Обучающий тренинг Тезисы и расписание Шаржи на докладчиков
2014 года

HighLoad++

31 октября
и 1 ноября
Место проведения: Москва,
Краснопресненская наб. 12.

Главная2014Архитектуры

SDCH, или новые подходы увеличения производительности за счет сжатия отправляемого трафика
Архитектуры

Доклад принят в Программу конференции
LinkedIn

Разработчик в LinkedIn, работает над проектами Apache Traffic Server внутри команды Service Infrastructure. До LinkedIn был разработчиком в Microsoft, работал над HTTP Stack API в команде Windows. Участник ряда конференций, включая Velocity, ApacheCon и др. Любит математику, алгоритмы и, конечно, программирование.

Тезисы

На сегодняшний день наиболее популярным алгоритмом сжатия отправляемых с веб-сервера данных является gzip. Но существует еще несколько новых направлений, на которые стоит обратить внимание при отправке большого количества данных в нагруженных системах.

Этот доклад будет посвящен новому протоколу сжатия данных SDCH (общий словарь сжатия для HTTP) http://groups.google.com/group/SDCH. Этот протокол мы экспериментально внедрили для статического англоязычного контента (7 тысяч JavaScript-файлов, 2 тысячи CSS-файлов) в компании LinkedIn, и результаты нас приятно удивили.

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

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

Результаты
- В среднем на 30% уменьшился размер передаваемых данных по сравнению с Gzip.
- Только файлы маленького размера проигрывают относительно Gzip.
- Задержка для кодирования файла составила всего 400 микросекунд.
- Уменьшилось время загрузки страниц, особенно при низкой пропускной способности сети и больших задержках.
- Чем больше веб-ресурс (чем больше файлов участвует в формировании словаря), тем лучше работает эта технология.

Какие существуют проблемы и как их решать:
- генерация словаря может занимать продолжительное время (от нескольких часов до нескольких дней);
- безопасность: какой контент стоит добавлять в словарь, а какой нет;
- HTTPS vs. HTTP;
- вопросы кэширования при использовании CDN;
- на данный момент есть поддержка только в Chrome, Yandex Browser и в следующих версиях Safari.

Инструменты, которые есть в открытом доступе:
- в данный момент практически нет инструментов для генерации словаря и кодирования контента, но ко времени выступления компания LinkedIn планирует выложить свои разработки в открытый доступ, чтобы дать всем заинтересованным компаниям возможность начать свои эксперименты.

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

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

PageSpeed-библиотеки представляют собой набор классов C++ для автоматической оптимизации веб-страниц и ресурсов. Библиотеки являются проектом с открытым исходным кодом.

PageSpeed ​​ускоряет работу вашего сайта и уменьшает время загрузки страницы. Это модуль веб-сервера, который автоматически применяет передовой опыт для ускорения страниц и связанных с ними ресурсов (CSS, JavaScript, изображения), не требуя изменения существующего контента. В отличие от SDCH, PageSpeed в большинстве случаев не требует каких-то масштабных усилий по внедрению и изменения кода на сервере.

Результаты
- Этот подход мы использовали для удаления пробелов и минификации JavaScript на всех наших html страницах, что позволило уменьшить объем HTML-данных в среднем на 20%.
- Задержка при обработке HTML-страницы составляет в среднем 15-20 миллисекунд.

Мы успешно используем оба этих подхода на наших серверах и хотим поделится нашим опытом с вами.

Другие доклады секции
Архитектуры

По любым вопросам обращайтесь:
Бухгалтерия и вопросы оплаты :
Олег Бунин , +7(495) 646-07-68
Организационный комитет :
Олег Бунин , +7 (495) 646-07-68
Программный комитет :
Олег Бунин , +7 (916) 635-95-84
Горячая линия :
+7 (495) 646-07-68, ежедневно с 10 до 22

Почтовый адрес:
119180, Москва, Бродников пер., д. 7 стр. 1, +7 (495) 646-07-68 ООО «Онтико»

Rambler's Top100
Рейтинг@Mail.ru