Итак, HighLoad++ состоялся. Если говорить кратко, конференция мне понравилась. Ниже мои личные впечатления о конференции, краткие тезисы доклада и презентация.
Текст доклада дописываю, есть мечта к концу недели это доделать (сейчас готова ровно половина). Тогда же текст опубликую, возможно в серии отдельных постов и в виде одной большой PDF-ки тут.
Мои впечатления о конференции
Итак, мне понравилось. Интересные доклады – много интересных докладов. Жалко, что не было
Яндекса – они делают хорошие доклады. В первый день была проблема поесть и попить, но ко второму дню ситуация как-то улучшилась. Народу чуть-чуть больше, чем хотелось бы (иногда в аудиторию к докладчику не пролезть через тела тех, которые устроили «пробку» на входе в зал). Но интересные или очень интересные доклады, много обсуждений, новых идей. Встретил старых знакомых, это всегда приятно 
Огранизационно всё было четко, понравился дизайн мелочей – бейджиков, шаблона презентаций и прочего – просто и со вкусом. В общем и целом – так держать, Олег 
Краткие тезисы
Требуемое время: 50 минут Докладчик: Андрей Смирнов
Цель доклада – рассказать о проблемах кеширования в распределенных высоконагруженных проектах и о возможных путях решения этой проблемы. Предполагаемый уровень подготовки аудитории – начинающий++.
Современный высоконагруженный проект может использовать десятки гигабайт распределенной памяти, используемой под кеш, организованной в виде кластера memcached-серверов. Зачем нужен memcached? Как работать с таким хранилищем, как распределить ключи по элементам кластера? Как назвать ключ, соответствующий кешу? Как обеспечить атомарность операций, “блокировки”?
Как эффективно использовать такое хранилище? Как исключить возможность одновременного построения “тяжелых” кешей разными мордами? Как сбросить одновременно группу кешей? Как отлаживать (собирать статистику) о кешировании? Как работает slab-аллокатор? Для чего еще может быть полезен memcached в веб-проекте?
Видео с конференции
Презентация
Полный текст доклада
Материалы
- Тезисы (RTF)
- Презентация (PowerPoint)
- Полный текст доклада (PDF)
Спасибо
Ты то, кстати, всегда мог поесть в штабе – ты же докладчик. А на второй день в комнате докладчиков мы еще и вином проставились
)
2Олег Бунин: круто проставились….. прошлые 2 конфы хоть пивка попили…. а тут просто все денежку собрали и разбежались…. говно-организатор Вы, Олег!!! Третий (три раза был участником) раз сливаете организацию. Пропало доверие!
А что, записи-таки будут выкладывать ?
2Олег: чорт, я не знал, что там поесть дают… Может, там медитируют над презентацией
Зачем мешать?
Записи Smotri.com обещает выложить в ближайшее время, как смонтируют, насколько я знаю.
Все или почти все видео выступлений с HighLoad++ можно посмотреть тут: http://smotri.com/community/video/highload/
Очень медленно идет в онлайне!
А не расскажите ли Вы нам как бороться с лагами кешеда.. В принципе при каждой рендере страницы у меня бывает 0-3 «подвисаний» сокета кешеда(200-250мсек)
Фейсбук поборол это уйдя на UDP, но клиент свой покуда не открыл.. Смотрю тут на memcache.redundancy Все думаю – это обычный мирроринг, или возможно получение одного и тогоже ключа с двух серверов( отказ сразу двух сокетов это уже фантастика) и если один подвис малек – значение будет получено с другого.. те без лага.. или как?
Бороться надо кардинально – никаких «подвисаний» быть не должно, т.е. время отклика должно быть минимальным, и уж точно без подвисаний.
Причин подвисаний может быть много очень, надо искать: * загруженность сети; * потери пакетов в сети; * загруженность сервера, где стоит memcached; * загруженность морды (где работает PHP, речь о нем, как я понимаю); * …
Redundancy определяет изменение функции хэширования ключа, чтобы ключ хранился на нескольких серверах (а не на одном), при этом если он не будет обнаружен на одном из них, будет попытка поиска на других.
«Лаг» или «подвисание» будет, покуда его не устранить, поэтому ‘redundancу’ скорее помешает, чем поможет (два «лага» вместо одного).
Фейсбук «борол» проблемы очень (очень!) большой нагрузки, если у Вас они уже есть, то решения проблемы становятся более изощренные и разнообразные.
Сухой остаток: ищите причину «затыков».
хм, куда-то мой комент куку
К сожалению найти затык не получается. Запросы к базе идут без задержек, а вот кешед постоянно глючит.
200мсек – восстановление TCP Почему теряется пакет – не известно, где и кем теряется – тоже. Мы получаем только свершившийся факт. Стоят три сервера воткнутые напрямую друг в друга. Нагрузка – минимальна – 97 запросов в секунду
клиенты кешедов – последние билды сервера – тоже последние, с включенным USE_THREADS ( с выключеным было тоже самое
)
Очень-очень странно, попробуйте persistent соединения, wireshark или tcpdump, должна быть причина такого поведения.