30 мая в Екатеринбурге прошла уральская конференция веб-разработчиков «Development Usability Management Practice» (Dump), которую мне удалось посетить. Основных направлений два, как следует из названия, – это веб-разработки и менеджмент IT технологий.Конференция проходила в новом отеле Angelo, который находится аккурат справа от терминала внутренних авиалиний аэропорта «Кольцово». Отель построен совсем недавно, чуть позже чем сам терминал, и выглядит просто шикарно.
К 9:00 делегация нашей компании прирулила к входу в отель. При входе нас сразу встретили организаторы и после получения бейджика я прошел в общий зал.
Народу было не особо много, и было время полюбоваться сверкающим зданием терминала. Потом потихоньку начали приходить участники. Они кучковались по 3-4 человека. Что интересно в основном из каждой компании направляли группу спецов. После того, как все собарлись нас пригласили слушать доклады. Я пошёл в секцию веб-разработки.
Сервис «Продажа авто»: как он устроен? // Сергей Ефимов, E1.ru
Первым был доклад Сергея Ефимова из E1. Сотрудники E1 и Яндекса были фронтлайнерами конференции, и участвовали не только всекции веб-дева, но и в потоке менеджеров (причём не солдним докладом). Трендом ZFConf‘а было качественное представление докладчиков (как это сделал в частности Алексей Качаев и другие), а на Dump’е среди первых слайдов обычно шли цифры, дабы ничтоже сумнящиеся убедились, что да это всё-таки highload. Не скажу, что это было сделано зря. По показателям хитов/хостов/запросов в секунду/нагрузки на БД можно определить очень многое, и сопоставить разные проекты. Итак E1, для тех кто не знает (а вне Екб его не знает почти никто) – это крупнейший городской портал города, эдакий Rambler но по конкратеному городу. Портал, кстати, мне нравится, много полезных фишек, таких как поиск резюме, машин и недвижимости. Работает уже более 5 лет, на данный момент больше 9 Млн. хитов в сутки, 120 запросов в секунду (rps) на динамику (php). Используют php 5.3, apc, memcached, балансировку nginx ip_hash(), mysql. Вообщем, по-моему отличная демонстрация платформы LAMP + мозга спецов. Основная проблема разработчиков – это практически линейный рост посещаемости. Вместе с проникновением интернета в городе, растет и аудитория портала.
После первого скачка посещаемости система упёрлась в диск. Добавили memcached, стало лучше на год. Но потом скорость отдачи страниц начала падать. Это происходило из-за того, что с одной страницы было много сетевых запросов. Для справки: hello world на php – 15 000 rps, hello world + один запрос к memcached – 800rps. Дают о себе знать сетевые задержки.
«Memory is new disk, disk is the new tape» (c) Jim Gray
Память дешевая, почему-бы её не прикупить. Специфика такова, что массив данных (весь) влезает в память, а теперь её много. Он подготавливается заранее, и всё постоянно лежит в памяти (через apc).
Счетчики марок моделей на сервисе пересчитываются раз в несколько минут (похоже без очередей тут не обошлось). Все варианты сортировок просчитываются. Изменения пользователя кладут в файл (очередь на запись), раз в несколько минут пересчитывают. Ничего не напоминает? Это конйепция offline-cms, правда тут она онлайн, но принцип тот же сайт – статическаий снапшот динамических данных, которые рендерятся не по запросу пользователя, а по расписанию. Однако такой подход допустим не везде и не всегда. Например, в социальных сетях, когда каждая страница авторизированного пользователя – уникальна. Хотя в принципе можно рендерить страницы заранее индивидуально, но что-то мне подсказывает, что памяти при таком раскладе потребляться будет немеряно.
К сожалению APC не работает в CLI режиме, поэтому используется Memcached. Поиск по сайту (имеется в виду авто) – узкое место, он стоит на отдельном Apache, когда он тормозит, всё остальное работает. По статистике он занимает всего 5% запросов.
Аналогичноы образом сделан и постраничный навигатор (ака пагинатор/пейджер). Первый запрос обрабатывается, последующие страницы предварительно собираются. Кстати очень хорошая идея. Почти как кэш процессора 
Можно прикрутить туда очередь, и если таски долго не брались, то вытеснить их.
На секции вопросов и ответов Сергей на мой вопрос, апочему же не используется Memory storage engine, сказал, что просто не дошли руки. На вопрос – «почему php» он справедливо заметил, что наговнокодить можно на любом языке. Насчёт тестированяи всё стандартно – ab.
Вообще с нагрузкой интересная ситуация. Как объяснил Сергей, сервис всегда находится под DDOS. Но она не злонамеренная, просто данные сервиса растаскивают боты на другие сайты. Они не борятся с ней, они научились с ней жить.
«Возникали ли идеи всё переписать?» – «Дааа. Но пока работает, лучше не трогать». Напоминает мой любимый анекдот про солнышко:
Сидит програмист глубоко в отладке. Подходит сынишка:
-Папа, почему солнышко каждый день встаёт на востоке, а садиться на западе?
-Ты это проверял?
-Проверял.
-Хорошо проверял?
-Хорошо.
-Работает?
-Работает.
-Каждый день работает?
-Да, каждый день.
-Тогда ради бога, сынок, ничего не трогай и не меняй.
Резюме доклада: предзагрузка данных, возможно предрендеринг, очереди, apc, балансировка nginx по ip_hash(), вертикальное разбиение системы (на примере отдельного поиска).
Сервис Яндекс.Авто // Дмитрий Качмар, Яндекс
Тему автомобилей продолжил Дмитрий Качмар из Яндекса. Что интересно – это не было совпадением. Основная концепция, которую продвигает Яндекс на конференции (да и не только) – это «вертикальные сервисы-агрегаторы». Самого контенат у Яндекса нет, он получает его либо через партнеров, которые отгружают его в виде XML, либо через поисковых роботов-пауков. НО, на сайтах партнеров поиск как правило организован не так хорошо, как у Яндекса, и требует много вичислительных ресурсов. Яндекс видит свою миссию во взаимовыгодном сотрудничестве с площадками контента. Он берет на себя организацию поиска по сайту, его регулярную переиндексацию, а сайт даёт ему контент. Такое согалешние, в частности, заключено между Яндекс-Авто и E1-Авто. Как заявили представителя E1 в ходе дискуссии, они ничего не теряют, ведь поиск – это только 5% запросов (всё-таки мне кажется они немного лукавят, и речь идёт именно о полнотекстовом поиске, но не о поиске по маркам машин). Яндекс в этом случае приобретает контент, что тоже хорошо.
Архитектура Яндекс Авто
Мотивация по созданию агрегатора примерно такая. Допустим пользователь ищет машину. Он заходит на первую доску объявлений, копается в ворохе спама, ничего не находит. Заходит на вторую, тертью. Везде разный интерфейс, надо привыкать к нему и осваиваться с элементами управления. Сила Яндекса, в этом случае, в унификации поискового интерфейса доступа к агрегированной информации. Сервис вертикальный, т.к. затрагивает только одну тематику, и специально заточен под неё. Например, для машин Ford, которые произведены в России, можно сразу добавлять атрибут «Руль: левый». Кроме унификации, Яндекс делает ещё много того, о чём забывают (или на что не хватает ресурсов) владельцы площадок.
- Унификация интерфейса.
- Фильтрация контента, когда отсеиваются спам объявления.
- Кластеризация контента, когда выделяются общие признаки, объекты делятся на группы. Тема вообще очень интересная. Я когда-то изучал алгоритмы нейросетевой кластеризации.
- Сомнительнойсть контента. Объявления о продаже BMV за 10 000р явно имеют мало общего с реальностью. Такие объявления, кстати, тоже достаточно легко вычислить стаистическими методами.
- Очистка мусора, в ходе которой происходит парсинг объявлений и нормальзация контента.
- Подсчёт релевантгности для облегчения последующего формирования выдачи.
- Добавление к конетнту своих функций, таких как каталог, статистика и т.д.
По сути этот процесс сводится к цепочке Парсинг -> Очистка -> Нормализация -> Анализ. Формируетсяс единая семантическая модель из разных форм представления контента.
Нагрузка Яндекс.Авто
Основное, что я запомнил из доклада – не надо обращаться к хранилищу (БД) напрямую. Данные из БД лучже всего экспортировать и потом уже коннектить к экспортируемым данным клиентов. Кстати в E1 похожая схема (чтение со slave серверов). Необходимость распределённой индексации и балансировки нагрузки не только на поиск, но и на индекс. Также необходимо минимизировать сетевые запросы. Концепция вертикальных сервисов означает декомпозицию одной системы на состовляющие. «Сервис должен уметь деградировать», это значит, что ошибка при работе одного сервиса не должна сказываться на функционировании другого.
Не убивать партнеров. Т.е. Яндекс индексирует конетнт-площадки, то это создает нагрузку, поэтому например картинки яндекс забирает себе, и хранит на своих серверах, тем самым разгружая площадку-донор контента.
На конференции не были анонсированы новые сервисы Яндекса, однако был слайд с Я.Отзывы, Я.Работа и собственно Я.Авто. В яндексе создан свой фреймворк для парсинга, для некоторых площадок, как я понял, создаются плагины к нему. Естественно речь идёт о больших площадках, для каждого блога такоене делается.
Вопросы и ответы
— Вы не разрушите бизнес досок объявлений?
— Нет, мы не принимаем объявления, мы только импортируем их с досок. Мы экономим их вычислительные ресурсы на поиск, и даём унифицированный интерфейс. Они не тратят деньги на организацию своей поисковой системы.
— Какие СУБД вы используете?
— В Яндекс.Авто – MySQL, сейчас мигрируем на хранение в файловой системе. В Отзывах – Oracle, frontend на xScript. Backend – на Java, xml, xslt. Вею-сервер Jetty (который кстати используется в Teamcity) хорошо показал себя, обрабатывает 30K rps.
— Какой размер вашей (Я.Авто) команды? Сколько разработчиков?
— У нас 2 программиста, и все разработчики Они занимаются бекэндом, 1 разработчик фронтэндом, 1 менеджер, 1 аналитик и 2 контент-менеджера, но они работаю по тикетам для всего проекта. Также есть группа «ассесоров»(судя по всему это модераторы, проверяющие корректность поиска), и группа… статистических алгоритмов.
— Работаете ли вы с Auto.ru?
— мы долго вели преговоры, но они боятся, что потеряют бОльшую часто своих клиентов, и попросили нас не ходить к ним. Ну мы и не ходим.
— Как вы монетизируете контент?
— Яндекс.Директом.
— Что вы можете сказать о будущем сервисе Яндекс.Тур?
— Без комментарием. Могу предположить, что в данный момент сервис готов, и старательно вылизывается. -Т.А.
— Как быстро результат попадает в поиск?
— У нас есть несколько видом «колдунчиков» – realtime индексов, и результат отображается почти мгновенно.
Вообще Яндекс хотят в будущем предложить площадкам нечто большее, чем просто индексацию контента. Например корректировку объявлений.
XScript – это существенная часть “движка”, разработанного и применяемого в Яндексе для создания сложных, масштабируемых, высоконагруженных веб-сервисов, работающих в режиме 24×7×365.
XScript рассчитан на сервисы, обладающие следующими особенностями:
- массовая (миллионная) аудитория: XScript стабильно работает в условиях высоких нагрузок, сохраняя при этом достаточную для нормального функционирования сервиса производительность;
- кластерная архитектура: Xscript и web-сервер работают на фронтендах, а контент сервиса формируется на бакендах и передается по протоколам CORBA или HTTP.
При этом Xscript может работать и в конфигурации с единственным сервером. Использование технологии XML/XSLT: данные с бакендов поступают в формате XML, из которого при помощи XSLT-шаблонов формируется результирующий HTML динамический, постоянно обновляющийся контент. Модуль взаимодействия между XScript и CORBA пока не распространяется публично. На сайте выложен репозитарий, периодически обновляемый . Дата масштабного обновления порядка 2 лет назад. А возможно это дата создания его. Ведь некоторые каталоги могут и остаться не тронутыми после создания репозитария. На этом языке написан если не яндекс, то сервисы для него. В исходном коде встречаются файлы написанные на СИ и xml файлы со скриптами.
Резюме: вертикальные сервисы, декомпозиция вместо асбстракции, исключение прямых обращений клиентов к хранилищу.
Питательный суп из HandlerSocket, MySQL шардинг и Redis для больших нагрузок // Кирилл Гафаров, Umap.ru
Специфика проекта uMap.ru – как у всех: много юзеров, много ботов, мало денег. Что можно придумать в короткий срок? Балансировка нагрузки, настройкой БД у них занимается отдельно выделенный человек (DBA). В ходе работы выяснилось, что Memcached «кушает зря» дорогую память, слишком много Master-slave взаимодействий («DBA нервно дышит»). Решение следующее: Percona Server + HandlerSocket—Memcached+Redis. Вообще был унивлён, как мало людей среди ИТшников Урала знает о HandlerSocket. Программисты из uMap провели свои тесты HS, в результате у них получилось, что HS отстает от Memcached на 20-25%, а от Redis на 10%. Они хотят вообще отказаться от Memcached, на каждый чих нужны сетевые соединения, их очень много, и иногда он падает. Сейчас схема организации следующая. Есть пул серверов данных: (MySQL + HS) и бекэндов (Redis+бекэнд движка) и фронт-энд, который распределяет нагрузку на бекэнды. Некий DataProvider распределяет чтение данных. Кирилл даже привёл алгоритм распределения, но сходу его никто не понял. Само распределенеи выполняется по младшему байту id пользователя, в котором 4 бита указывают сервер БД, 4 бита для генерации ID. Соответственно всего возможно max 16 серверов БД и 16 бекэндов. Однако никто не исключает возможность вертикального масштабирования каждого из этих серверов.
Redis используется для генерации ID, каждый Redis сервер обслуживает свой пул ID, данные можно сливать/разделять, можно выполнять живую миграцию. Однако в Redis нет возможностей реляционного поиска. Для этого на всю катушку используется Sphinx.
Преимущества такой системы
- Отказоустойчивость
- Дешевизна
- Производительность
- Доступность. Порог вхождения в HBase/Hadoop гораздо больше.
Недостатки
- HS эффективен, когда данные вмещаются в память, его нужно мониторить.
- HS не поддерживает распределение.
- Получилось не совсем интегрированное решение.
uMap в цифрах
- 1 M запросов в день, 400-450 rps
- 6 серверов в данный момент.
- 30%-ая экономия на железе
- «DBA меньше злится, и требует повышения ЗП на 60% реже».
- Монетизации нет.
Из-зала спросили, почему не используются проприетарные решения. Кирилл закономерно ответи, что требуется эффективность в использовании железа, а проприетарные решения не позволяют достичь её.
Резюме: используем HandlerSocket и распределённые решения, такие как Redis.
Интеграция учётных систем с Гис // Дмитрий Киселёв, Naumen
Этого доклада не было в программе. Один из проектов naumen – это система управления прокладко кабелей с визуальным интерфейсом на карте. В докладе Дмитрий рассказал о подводных камнях работы с Google Maps и Яндекс Картами. Обе системы очень жесткие, и даже перекрасить маркер в другой цвет – это целая проблема. У них нет унифицированного Api и приходится частенько изобретать костыли. У нас кстати был такой опыт 
В основном тормоза у ребят идут в процессе загрузки, загружается порядка 5000 маркеров, и логично что система подтормаживает. Из зала предложили группировать маркеры и грузить группы, а при увеличении карты уже подгружать конкретные маркеры вместо групп. Но видимо не всё так радужно в сфере картографии, раз такое ещё не реализовали.
Перспективы MySQL. Базы данных в веб-разработке // Антон Халиков, NetAngels
Компания NetAngels, по моим данным является одним из крупнейших хостингов Екатеринбурга, и неудивительно, что ими накоплен большой опыт работы с серверами. Первая часть доклада была скорее вводной: история MySQL, корпоративные передряги Монти и создание форков популярнейшей СУБД: Percona, MariaDB, Drizzle. Узнал для себя, что у Drizzle есть возможность шардинга, а это очень интересно. Антон коротко рассказал о каждом из форков, после чего приступил к докладу результатов тестирования. Тестированпие выполнялось утилитой mysqlslap.
MyISAM Benchmark (MariaDB vs Percona vs MySQL)
В тестах этого движка хранения победил MyISAM из поставки MariaDB за счёт более быстрых JOIN и создания временных таблиц. Второе место поделили MyISAM из Percona Server и оригинального MySQL, что неудивительно, т.к. они идентичны. Третье место занял новый движок Maria, которому Монти прочит замену MyISAM. Однако на данный момент он ещё сыроват, что подтверждают тесты.
InnoDB Banchmark (MariaDB XtraDB vs Percona XtraDB vs MySQL InnoDB)
XtraDB – это переписанное программистами из Percona хранилище InnoDB, надо сказать, хорошо переписанное, и вот почему: первое место в тесте занимает реализация XtraDB в MariaDB сервере, второй Percona, а аутсайдером является Oracle MySQL.
Monty says: «Oracle’s MySQL is now dead»
Резюме: судя по тестам Антона, таки да, Oracle MySQL потихоньку загибается. Ждем кто победит в борьбе форков, пока я ставлю на Percona, но по тестам сегодня очень хорошо показала себя Maria.
Интеграция товарного учета с веб-приложениями // Николай Адеев, Artsofte
Ещё одна звезда в плеяде уральских разработчиков – это студия Arttsofte. Очень часто в студию приходят заказы на интеграцию системы товарного учёта (а в России это 1С) с веб-сайтом. Дистрибьютеры пытаются склонить клиента в сторону желто-полосатой продукции (1С-Битрикс), о которой ходят легенды. Такое решение может быть удачным, интеграция между 1С продуктами налажена хорошо, однако во первых это приводит к vendor-lock, а во-вторых при смене одного из компонентов, ни о какой интеграции, как правило, речи идти не может. Поэтому, при интеграции в студии разрабатывают кастомные решения, под конкретного заказчика, чтобы полностью удовлетворить его нужды, а не допиливать коробочные варианты. Интеграция осуществляется через SOAP, REST, XML, CommerceML. Последнее чудо – это русский язык описания структуры на основе XML от 1С
Начиная с 8ой версии 1С поддерживает механизм Publisher/Subscriber для экспорта, и во-многом это облегчает процесс интеграции, т.к. теперь нет необходимости делать поллинг интегрируемой системы.
Резюме: 1с – кошмар программиста, интеграция процесс трудозатратный.
Типичные ошибки программистов, проектировщиков, дизайнеров, верстальщиков. // Никита Шляхов, СКБ Контур
В этой презентации рассказывалось о типичных ошибках в веб-программировании. Первой из них был конечно же копи-паст. Копирование кода, это скорее даже не техническая ошибка, а просто лень разработчика. Лень включить мозг и проанализировать этот маленький кусок кода, как же он работает. Зачем? Ведь можно просто скопипастить его легким движенеим руки. Вообще хорошой практикоя является установка в репозитарий phpcpd(php copy-paste detector), который выявляет соответствующую метрику кода, и если после комитта она стала бы больше, то не принимать такой коммит, ведь скорее всего он содержит копи-паст. Второй ошибкой является изобретение своих велосипедов. Об этом я уже писал, так что останавливаться на этмо не буду. Ну и отсутствие унификации и несоблюдение корпоративных стандартов (таких, как станлдарты кодирования и верстку) тоже является большой проблемой в современном веб-деве.
Также были рассмотрены не только ошибки программистов, но и ошибки дизайнеров. Например дизайнер нарисовал подложку в виде кляксы под пунктом меню, и каждый клчксы у него разные. В итоге пришлось делать несколько вариантов одного и того же. ИМХО это происходит из-за того, что люди работаю разобщённо. Мало кто думает, что будет дальше происходить с его работой, кто будет её доедлывать и зачем вообще он работает. В хорошо собранных командах такого не происходит. Всегда есть обратная связь между членами коллекива разработчиков, дизайнеров, верстальщиков и тестировщиков.
После этого доклада все собарлись на обед. В Angelo построена очень красивая столовая. Вот фотка оттуда:
Высокие нагрузки Контур-стайл. // Павел Егоров, СКБ Контур
В этом докладе Павел рассказывал о распределённой БД Kanso. разрабатываемой внутри компании. Инфраструктура хранения данных разрабатывалась для самого высоконагруженного проекта компании СКБ Контур – Контур-Экстерн.
NoSQL БД Kanso
Kanso в переводе с японского значит «простота», бд является представителем класса NoSQL решений, соответственно поддерживает совсем немного операций. Всего две! Добавление (append) и произвольное чтение (read). Данные в Kanso хранятся в файлах, операции удаления не предусмотрено. Есть файл для данных(контента() и мета данных (название, смещенеи в файле данных, контрольная суммаи т.д.). Система хранения писалась как аналог GFS (Google File System), как и Hadoop. Но на момент создания системы Hadoop был ещё сырой, а теперь Kanso уже сильно интегрирована в ПО контура.
Кроме вопроса хранения, разработчики плотно занимались вопросами поиска, ведь такая организация не дает вообще никаких поисковых возможностей. Для этого используется индексирование файла внешним демоном по тем полям контента, по которым в дальнейшем необходимо будет его производить. Т.е. в любое время часть информации файла данных будет в индексе, а часть ещё нет. Индексированеи выносится на стороннюю машину, чтобы разгрузить текущую. Отсюда возникает проблема запаздывания индекса. Для её решения разработана система Live Index или RT-index (иак она называется в Sphinx), при которой запись производится не в хранилище непосредственно, а через индекс, который при этом обновляется. В Sphinx кстати, здорово сделано, там если подключить SphinxSE, то появляется таблица, в которую можно писать, это и есть RealTime индекс. Для приложения практически ничего не меняется. В системе контура имеется несколько front-серверов и index-серверов, связаных по топологии «сеть», т.е. любой фронт-сервер может обратиться к любому индекс-серверу, НО, потом он привязывается к нему, и в дальнейшем работает только с ним.
Если индекс не влезает в память, то он по определённому алгоритму вытесняется на диск. Для хранения индекса используется BerkleyDB. Кроме индекса по мета-данным есть специальный индекс по страничному навигатору. Индексация идёт по полям: userid, startIndex, count => docIds[]
Реализация изменения/удаления в Kanso
Для этого надо перестать смотреть на мета-файл как на файл, а смотреть на него как на лог. Пусть это кусок plain-text мета-файла:
… | event: created, uid: 123, offset: 34234, length: 53453 | event: modified, uid: 123: offset: 3423, length: 324 | event: deleted …
Вопросы и ответы
— Есть ли Kanso в OpenSource?
— Нет. Но есть же Hadoop.
— А как вы защищены от кривых данных, которые пишутся в БД? Ведь удаления нет? Систему можно забить незначимым контентом.
— А кто защищён от ошибок программиста? Человеческий фактор есть всегда. У нас есть специальная утилита, которая создает новый kanso-файл, переносит туда значимые данные, а потом удаляет старый.
— Как физически организовано хранение kansа-файла? Он ведь может достигать лимита размера файла в ФС?
— Как и в GFS, файл данных харнится в виде множества файлов (chunks) размазанных по машинам кластера. И я жумаю не в одной копии.
— Как организована рабоат с индексами?
— Все индексы знают о всех данных. Из-за этого происходит много сетевых обращений. Т.е. на одну запись выполняются следующие обращения: 1 к мастеру, 3 на запись к слейвам, 3 на коммит записи. Всего 7. Вот мне кстати непонятен момент, зачем коммит, если транзакций нет?
Спортивные проекты Яндекса // Яндекс
В этом доалкде раскрывалась тема сезонных проектов. Они обалдают следующими особенностями:
- Время жизни проекта совпадает с временем проведения спортивного события (чемпионат, олимпиада и т.д.)
- На создание спортивного проекта тратится сил не меньше, чем на создание любого другого. Задействуется множество разных специалистов.
- Физически мероприятие может быть где-угодно, и из-за разницы во времени пик посещаемости может придти скажем на 3 ночи.
- Спортивные проекты сегда сдаются в срок
Любой спортпроект яндекса – это набор виджетов. При HTTP-запросе загружается страника, которая потом по JS подтягивает содержимое виджетов. Виджеты независимы друг от друга, их программный интерфейс – стандартизирован.
Из-за этого один пользователь даёт несколько (по количеству виджетов) хитов. Некоторые не дожидаются обновления виджета со счётом и жмут F5. Для реализации используеся xScript, бекэнды на Python+django.
Вопросы и ответы
— Вы уже готовитесь к Олимпиаде-2012?
— Мы ждем её с ужасом.
— Как у вас со сроками?
— Удивительно, но такие событийные проекты всегда сдаются в срок.
Резюме: денормализация интерфейса и стандартизация программных интерфейсов виджетов.
Высокие нагрузки в NauPhone Call Center // Ветошкин Никита, Naumen
Компания Naumen также занимается предоставлением Call-центров, построенных по технологиям IP-телефонии. В докладе рассказывалось об устройстве программно-аппартаного NauPhone.
Высокие нагрузки => Масштабируемость => Многокомпонентность, Многопоточность. При создании таких систем не обойтись без сервера очередей, разработчики также используют программную общую шину (BUS), которая снижает нагрузку на сервера, и организует единое пространство коммуникации компонентов системы. В качестве языков программирования используется Pyhton и многопоточный асинхронный C++, сервисы и скрипты Python, boost::ehatever, lxml.
Резюме доклада: многопоточность и многокомпонентность, python неплох, как системный язык.
Высокие нагрузки на портале E1.RU // Cергей Ефимов, Е1.RU
В реальном бизнесе идеальных решений нет, если либо рабочие, либо не рабочие.
E1 сегодня – это 375 000 уникальных посетителей в сутки, 11 Млн просмотров, 50 сервисов. А нагрузка постоянно растёт, поэтому приходится адаптироваться к ней. E1 использует тот же принцип, что и Яндекс – вертикальные сервисы. Отдельный сервис – на отдельной машине. Для раздачи статики используется Nginx, на бекэндах используется Apache + mod_accel с локальным кэшем. В результате, если программист допустил ошибку, то падает только подпроект, на котором она возникла. Любой сервис живёт на своей машине, сейчас перезжают в кластер. Mod_accel не держит большую нагрузку, > 2058 активных коннкетов и он вдауне.
Хранение данных на E1
Схема хранения данных следующая. Два master-сервера, к которым обращается приложение, на каждый по slave-серверу, и один BackUp slave, с которого снимаются резервные копии. На master’а идут записи, на slave’ах выполняются тяжелые поисковые запросы, а резервирование делается только с backup-slave. В качестве ОС используется FreeBSD 6/7, Debian 4. Железо – сервера HP (это корпоративный стандарт), Raid5 они не любят, т.к. он легко затыкается на многопотчоном I/O, а используют RAID10.
Кэширование в E1
Кэшируют всё, что только можно кэшировать. Всегда предусмотрен аварийный путь кэша. Упал memcached – кэшируем в файлы. Используется общий распределённый Memcached (хотя как мне кажется хоть он и общий, но имеется в виду в рамках одного проекта). Посетитель привязывается к одному серверу.
Резюме доклада: кэшировать надо по максимуму, вертиклаьные сервисы, запас мощности.
Круглый стол «Разработка и проектирование API»
Было довльно скучно и я последние пол-часа провел в секции менеджмента, где увлечённо обсуждали дизайн приложений для социальных сетей.
Наши на DUMP
Наша компания на конференции раздавала флайеры Wanted. К этой задаче наш дизайнер подошел с юмором, в результате чего родились вот такие флайеры.
Наш флайер на конференции
Афоризмы DUMP
- «Впечатление от #dumpit странное. Кажется, что интересно было всегда на том треке, где меня не было.»
- «на приеме у интерфейсолога: «доктор, посмотрите, что это у меня к апи прилипло?»
- «Вывод по докладу про интерфейс соц. сетей: на рынок приложений для соц. сетей ни ногой!»
- «Enlang your penis!)»
- «Можно чем вы занимаетесь в %? Ну например 30% вы… Пьем пиво))»
- «На E1 6 программистов, и все они разработчики»
- «дайте апи для пива!»
- «У дизайнеров с инструментами вечночеловеческая тема: «Если бы губы Никанора Ивановича да приставить к носу Ивана Кузьмича»
- «считаю исследования «что лучше» для прототипов интерфейса бессмысленной и беспощадной. Инструмент должен быть по руке»
- «логично, но не питонично. Или питонично, но не логично, я запутался.»
- «Все-таки разработчики более зажигательно холиварят. Юзабелисты для этого слишком добрые и человечные»
- «навык перевода из любой системы в любую дается всем на 1-м курсе мат-меха, УрГУ. Жаль, что больше его нет»
- «Е1 – это не идеальная, а рабоча схема»
- «Интерфейсологи уже вовсю едят, а разработчики в параллельной секции до сих пор задают умные вопросы )»
- «вспомнился прикол с #msdevcon – я директор, приехал на конференцию со своим программистом, чтоб его никто не украл »
- «разработчики что-то фигачат-фигачат, а потом кричат: «Саша что делать-то?»
- «NauPhone принимает стопицот звонков в сутки #dumpit угу. Как та секретарша печатала – но такая фигня получается! »
- «И снова Яндекс. Я начинаю думать, что они везде :–)»
- «На самом то деле главная функция менеджеров яндекса – пресекать попытки разработчиков выбежать на трамвайные пути =(«
- «Можно высказывать свое мнение, но Папа и Мама главные!»
- «люди хотят знать: следит ли за ними яндекс ) Следит)»
- «Как вам метод разработки – коллективная галлюцинация? Яндекс использует во всю)»
- «все, чем я хотел бы заниматься в жизни – это писать map/reduce функции на эрланге, но в Яндексе мне не разрешают «
- «не забудьте опубликовать статистику по перераспределению персонала по компаниям после конференции»
- «по-моему, глубокая оптимизация таблиц и запросов быстро выпадает из мейнстрима. Этим должны заниматься роботы,не люди»
- «приятного аппетита, не уроните айфон в суп »
- «#dumpit где я? 0_о»
- «Разработчики битрикса икают. »
- «Оказывается, слово конь однокоренное со словом конец»
- «сначала бухгалтерия выглядела для нас как темные глубины афроамериканцев»
- «Мой сын рисует такие же картинки. Дяденьки из Яндекса возьмите его ПМом!»
- «судя по твиттеру, я не в тот зал сел, у менеджмента праздник и веселье, а у разработчиков – унылые базы и длл-ки»
- «жестоко ставить когото между мной и кофе-брейком.»
- «Админы – это самая сильная сторона проекта, поэтому обозначим их квадратиком»
Фотки (качественные, от организаторов)
https://www.facebook.com/media/set/?set=a.219621368062669.63201.187464147945058
https://www.facebook.com/media/set/?set=a.219614961396643.63192.187464147945058
Источник: https://tokarchuk.ru/2011/05/dump-2011-ekb/
Просмотров: 1229