.jpg "Оптимизация запросов. Основы EXPLAIN в PostgreSQL (часть 3)")
Подолжаю публиковать авторскую переработку Understanding EXPLAIN от Guillaume Lelarge.
Ещё раз обращу внимание, что часть информации для краткости опущено, так что настоятельно рекомендую ознакомиться с оригиналом.
Рубрика «highload» - 17
Оптимизация запросов. Основы EXPLAIN в PostgreSQL (часть 3)
2013-11-25 в 7:19, admin, рубрики: highload, postgresql, оптимизация, метки: highload, postgresql, оптимизацияКак работает Stack Overflow — железо
2013-11-23 в 22:34, admin, рубрики: hardware, high performance, highload, stack overflow, Администрирование баз данных, высокая производительность, ит-инфраструктураХотелось бы сказать, что Stack Overflow — масштабный проект, но это не так. Я имею ввиду мы добились многого, но я не могу назвать наш проект “большим”, ещё рано. Давайте я приведу в пример некоторые цифры — с какой нагрузкой мы имеем дело сейчас. Срез статистики за 24 часа от 12 ноября 2013 года. Это обычный будний день. Отмечу, что здесь представлена информация только по нашим собственным вычислительным мощностям, без CDN.
Оптимизация запросов. Основы EXPLAIN в PostgreSQL (часть 2)
2013-11-23 в 17:04, admin, рубрики: highload, postgresql, оптимизация, метки: highload, postgresql, оптимизация .jpg "Оптимизация запросов. Основы EXPLAIN в PostgreSQL (часть 2)")
Подолжаю публиковать авторскую переработку Understanding EXPLAIN от Guillaume Lelarge.
Ещё раз обращу внимание, что часть информации для краткости опущено, так что настоятельно рекомендую ознакомиться с оригиналом.
Предыдущие части:
Оптимизация запросов. Основы EXPLAIN в PostgreSQL
2013-11-23 в 5:38, admin, рубрики: highload, postgresql, оптимизация, метки: highload, postgresql, оптимизация 
Почему запрос выполняется так долго? Почему не используются индексы?
Наверное, все слышали об EXPLAIN в PostgreSQL. Но не так много тех, кто понимает, как его использовать. Сам длительное время не мог найти доступного для понимания учебника (плохо искал?).
Надеюсь, эта статья поможет желающим разобраться с этим замечательным инструментом.
Читать полностью »
Ускоряем Nginx за 5 минут
2013-10-29 в 21:48, admin, рубрики: high performance, highload, nginx, optimization, tcp, высокая производительность, Серверная оптимизация, метки: high performance, highload, nginx, optimization, tcp 
Попытайтесь повторить это сами
Как правило, настроенный должным образом сервер Nginx на Linux, может обрабатывать 500,000 — 600,000 запросов в секунду. Мне удалось довести этот показатель до 904,000 запросов в секунду. Хотел бы обратить внимание на тот факт, что настройки описанные ниже, применялись в тестовой среде и, возможно, для ваших боевых серверов они не подойдут.
Минутка банальности.
yum -y install nginx
На всякий пожарный, создадим бэкап исходного конфига.
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.orig
vim /etc/nginx/nginx.conf
А теперь можно и похимичить!
Читать полностью »
Как сделать CDN для своего сайта и почему это полезно для высоконагруженных проектов
2013-10-22 в 13:47, admin, рубрики: CDN, highload, sports.ru, Блог компании Sports.ru, метки: CDN, highload, sports.ruГлавная задача отдела эксплуатации Sports.ru и Tribuna.com — масштабирование сетевой инфраструктуры в условиях постоянного роста трафика (за 1,5 года трафик и кол-во запросов в секунду выросло в два раза), регулярных пиковых нагрузок и аудитории, распределенной по разным странам. Для решения этой задачи мы используем разные технологии; одна из них — создание собственной CDN (сети доставки контента), которая позволяет сократить нагрузку, усилить защиту от DDoS-a и ускоряет загрузку сайта в удаленных регионах. Мы решили поделиться своим опытом в этой области и составили краткое практическое руководство для системных администраторов по разворачиванию и эксплуатации своей CDN.
Встреча разработчиков со студентами МФТИ или «Как собрать Badoo на коленке»
2013-10-22 в 10:03, admin, рубрики: badoo, highload, баду, Блог компании Badoo, Веб-разработка, Учебный процесс в IT, метки: badoo, highload, баду, Учебный процесс в it 
В эту среду наши разработчики, бывшие выпускники МФТИ, проведут встречу со студентами МФТИ и расскажут как создаются большие проекты и как сделать Badoo своими силами.
Никакого маркетинга, пиара и прочего булшита. Только разработка, только хардкор!
Общаться со студентами будут разработчики из отдела A-team — они специализируются на разработке инфраструктурных проектов компании. В Badoo отдел A-team занимается созданием масштабируемых и отказоустойчивых платформ для приложений, разрабатывает приложения для управления кластерами, утилиты автоматизации тестирования/деплоя кода, собирает и исследует тонны данных для повышения качества и производительности много-серверных продакшн-систем.
Работа ведётся на стыке приложений для конечных пользователей и системного ПО.
Если вдруг кто-то из вас учится в другом ВУЗе, но хочет попасть на встречу, то напишите об этом в комментариях к посту или личным сообщением до 15-00 23 октября. Ждем письмо с названием ВУЗа, ФИО, курсом и специальностью.
Где: Долгопрудный, МФТИ, главный корпус, 117 аудитория
Когда: 23 октября, среда, в 19-00
Бонус: Возможность задать каверзные вопросы fisher, antonstepanenko, youROCK и Деми (без аккаунта на Хабре).
Нам удалось выкрасть черновики, по которым разработчики готовятся к выступлению. Ими мы с вами и поделимся.
Читать полностью »
Как мы мигрировали миллионные страны за рабочий день
2013-10-14 в 10:45, admin, рубрики: badoo, highload, баду, Блог компании Badoo, Веб-разработка, высокая производительность, миграция, метки: badoo, highload, баду, миграция 
Badoo — крупнейшая в мире социальная сеть для знакомств с новыми людьми, насчитывающая 190 миллионов пользователей.
Все данные хранятся в двух дата-центрах — европейском и американском. Некоторое время назад мы исследовали качество интернет-соединения у наших пользователей из Азии и обнаружили, что для 7 миллионов пользователей наш сайт будет загружаться в 2 раза быстрее, если мы переместим их из европейского дата-центра в американский. Перед нами впервые встала задача крупномасштабной миграции данных пользователей между дата-центрами, с которой мы успешно справились: мы научились перемещать 1,5 миллиона пользователей за один рабочий день! Мы смогли перемещать целые страны! В первой части мы подробно расскажем о поставленной перед нами задаче и о том, какого результата мы достигли.
Читать полностью »
Нагружаем Node под завязку (2-я из 12 статей о Node.js от команды Mozilla Identity)
2013-09-29 в 14:00, admin, рубрики: compute-cluster, highload, mozilla persona, node.js, node.js holiday season, Блог компании Нордавинд, многопоточность, параллельное программирование, параллельные вычисления .jpg "Нагружаем Node под завязку (2 я из 12 статей о Node.js от команды Mozilla Identity)")
От переводчика: Это вторая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona. Эта статья написана по мотивам выступления Ллойда Хилайеля на конференции Node Philly 2012 в Филадельфии.
Перевод первой статьи, "Охотимся за утечками памяти в Node.js", был опубликован в пятницу.
Процесс Node.js выполняется на единственном ядре процессора, так что построение масштабируемого сервера на Node требует особой заботы. Благодаря возможности писать нативные расширения и продуманному набору API для управления процессами, есть несколько разных способов заставить Node выполнять код параллельно. Мы рассмотрим их в этой статье.
Кроме того, мы представим модуль compute-cluster — маленькую библиотеку, которая облегчает управление коллекцией процессов для выполнения распределённых вычислений.
Постановка задачи
Для Persona нам было необходимо создать сервер, который справился бы с обработкой множества запросов со смешанными характеристиками. Мы выбрали для этой цели Node.js. Нам надо было обрабатывать два основных типа запросов: «интерактивные», которые не требовали сложных вычислений и должны были выполняться быстро, чтобы интерфейс приложения был отзывчивым, и «пакетные», которые отнимали примерно пол-секунды процессорного времени и могли быть ненадолго отложены без ущерба для удобства пользователя.
В поисках наилучшей архитектуры приложения мы долго и тщательно обдумывали способы обработки этих типов запросов с учётом юзабилити и стоимости масштабирования и в конце концов сформулировали четыре основных требования:
- Насыщение. Наше решение должно было использовать все доступные ядра процессора.
- Отзывчивость. Пользовательский интерфейс должен оставаться отзывчивым. Всегда.
- Отказоустойчивость. Когда нагрузка зашкаливает, мы должны нормально обслужить столько клиентов, сколько сможем, а остальным показать сообщение об ошибке.
- Простота. Решение должно легко и постепенно интегрироваться в уже работающий сервер.
Вооружившись этими требованиями, мы можем осмысленно сравнивать разные подходы.
Читать полностью »
Кэширование фронтэнда: Flask, Nginx+Memcached+SSI
2013-08-29 в 8:38, admin, рубрики: flask, highload, memcached, nginx, python, SSI, Varnish, web, Веб-разработка, высокая производительность, метки: flask, highload, memcached, nginx, python, SSI, Varnish, web, фронтендДостаточно давно мне на глаза попались следующие статьи по этой тематике:
- nginx, memcached и SSI
- Nginx + Memcached + SSI — кеширование страниц и блоков (partials)
- Кеширование страниц — ускоряем сайт в 100 раз (Varnish + ESI)
С PHP я дружу, поэтому попробовал примеры и убедился, что это работает. Но всё это имело «фатальные недостатки» :) — PHP, а я фанат Python и по работе занимаюсь в основном бэкендом. Серьёзно говоря, применить на практике это не представлялось возможным.
Однако в начале года поступило предложение поучаствовать в одном амбициозном проекте, изначально подразумевающий HiLoad и прочие плюшки из этой оперы. Пока составлялись бизнес-планы, искались инвесторы и тому подобные дела, я решил изучит вопросы которые на мой взгляд пригодились бы в этой работе, в том числе и вопросы кэширования.
В первую очередь было реализовано черновое решение для моего любимого фрэймворка Flask использующее для кэширования стек Varnish+ESI. Это заработало и даже показало неплохие результаты. Позже пришло понимание, что возможно Varnish «лишний игрок» и всё тоже и даже гибче можно получить на связке Nginx+Memcached+SSI. Был сделан и этот вариант, по производительности особых отличий замечено не было, но последний показался более гибким и управляемым.
Тот проект не вырулил даже на взлетную полосу, или вырулил но без меня. Подумав, я решил «причесать код» и выложить его в OpenSource и на суд общественности.
Читать полностью »