2008-09-25 РИТ:Высокие нагрузки-2008 (2)
2 День первый2.1 Что такое нагрузка
Хороший доклад, «еще раз о компьютерной архитектуре от практика-железячника».
Диски, память, сеть. Кэш, кэш, кэш.
Прочувствуйте «физику» процесса, подивитесь огромному GAPу эффективности диска на последовательном и рандомном доступе.
Мимоходом «похоронены» SAS/SCSI диски — их удел только в «кеширующих» машинах с высоковероятным рандом-доступом, а в основном нечего выделываться, берите обычные SATA и используйте правильные алгоритмы, (сортировки дисковых массивов — только слиянием и т. п.).
RAIDы вроде тоже заругали (или в другом докладе, не помню) — смысл, что надежность должна обеспечиваться уровнем выше, типа вместо 3 живучих «Тигров» пусть будет 30 Т-34.
По памяти и CPU был тезис, что хотя многопроцессность была отстой, современная многотредовость рулит (тредов должно быть не меньше, чем дисков плюс процессоров, а еще лучше заложить запас).
AMD с привязкой памяти к процессорам must die.2.2 О проектах, отягощенных производительностью
Очень ценный доклад, наиболее профильный для нашей компании. Докладчик сразу отметил, что сейчас есть два самых распространенных полюса систем:
общедоступная вебсистема, дофига пользователей, большие объемы, куча транзакций, никакой сложной логики, пофиг на отказы (нажмите Refresh, если что не нравится и т. п.)
корпоративные системы — сложная логика, то есть одна транзакция дает движение в куче таблиц-счетов и т. п., и вообще объем кода в строчках и человеко-годах огромен. Ошибаться нельзя, падать нельзя, но нагрузка плевая.Но есть и редкий третий тип. Речь зашла о редких высоконагруженных «бизнес-логичных» системах (такие имеет смысл ловить наверно только в ЖКХ — офигически сложные расчеты всяких там льгот, куча транзакций и т. п.), или какой другой массовый биллинг (телекоммуникационный). Банки думаю не — кроме яндекс.денег, любой интернет-банк по нагрузке отдыхает.
Ну а дальше, докладчик прошелся по всем аспектам разработки таких систем, разрушая мифы, раздавая эпитеты и приговоры различным технологиям:
СУБД кроме Oracle, DB2, MySQL и PostgreSQL — ересь,
Oracle DBA зажрались и в массе лохи,
Java есть современный надежный Cobol, и это есть хорошо.
С# сам по себе ничего, но развертывание дороговато, (в основном за виндовс-сервер-лицензии).
Python прет (Django?), возможно будущее за Java+Python.
Всех (обоих) творцов на Erlangе гнать-избегать,
RoR — тормозит,
двухзвенка масштабируется отстойно (привет «Oracle и PL/SQL» подходу), по сравнению с трехзвенкой,
потому что кэш СУБД слишком тупой-низкоуровневый.
нефиг выделываться с XML-сериализацией — CPU на ветер.
Другие мысли:
на инфраструктуру — 10 % прибыли.
автоматизация тестирования форм — обязательно (видимо имелись в виду веб-формы).
В общем, наверно самый полезный для нас доклад, надо дождаться видео (я даже запросил DVD-диски, может пришлют), и смотреть всем.2.3 Как писать высокопроизводительные сервера
Жаркий дискуссионный вопрос. Давным-давно, во времена первого апача, порождавшего при обслуживании пул с трудом переключаемых процессов, все уяснили, что переключение контекста процесса есть штука чудовищно дорогая, и ее надо минимизировать. На помощь пришли методы телекоммуникационщиков из систем реального времени — никакой многозадачности с планировщиком («кузнец нам не нужен»), должна быть однопроцессная система с конечным автоматом (FSM), обрабатывающем события. На таких принципах реалован очень популярный вебсервер статики nginx. Но много минусов — кроме статики он ничего не умеет, стандартные вебфреймворки к нему не прикрутишь.
Автор же доклада принес благую весть — треды в apache2 уже достаточно эффективны и хороши, можно держать их тысячами и пользоваться всеми благами апача (или они пока только в BSD хороши, а в линуксе тормозят — уже не помню, но это не принципиально).
А если применить собственный механизм переключения облегченных тредов (которых обозвали «зелеными тредами», «ко-рутинами»), то вообще никакого проигрыша конечному автомату не будет. Да, у этих корутин есть некоторые болезни (для переключения используется тот же механизм, что для обработки C++ исключений, поэтому от исключений придется отказаться), но в целом, это прогресс и возможно гвоздь в гроб идеи FSM.
Ну еще известна шизофреничная сложность отладки программы с тредами, на что докладчик искренне удивлялся — «зачем отлаживать? не проще ли писать без ошибок?».
Вроде как проверено на крупных яндекс-проектах, типа краулера и верхнего уровня поиска.
Была жесткая дискуссия, требовали доказательств, цифр, корректного эксперимента.
Я лично склонен поверить докладчику.
Причем с корутинами думаю не столкнусь, а то что апач2 с тредами хорош (пусть даже чуть хуже FSM) — это хорошо, возможно альтернативы ему отомрут сами со временем.2.4 HCS — система хранения данных в Рамблере
Расшифровку аббревиатры забыл — некая библиотека для реализации некоторой алгебры операций (слияния, фильтрация, агрегация,…) над сверхбольшими плоскими файлами. (1011 строк, 10Tb/ 200Gb обновлений в день).
Работает быстро (сравнивали правда с неоптимизированными движками MySQL), но, насколько я понял, это не параллелиться (а ведь есть Hadoop, который вроде как можно было бы применить для этих задач).
Вроде готовится к публикации в опен-сорс.2.5 Сервис хранения данных на базе SQL Server Data Services
Маркетинговый доклад. Верный признак «чисто маркетинга», когда всякие «архитектурные» картинки рисуются блоками с градиентной заливкой, всякий гламур и анимация на слайдах. По сути некая компиляция whitepaperов разных технологий (SaaS, DaaS, PaaS,… все модные buzzwords, все в кучу).
Интерес (судя по заполненности зала) был слабоват.2.6 Проблемы работы с большими объемами реляционно слабосвязанных данных в высоконагруженных веб-проектах
Очень невнятное название, не шибко внятное содержимое. Типа у нас тут реляционная база и большая нагрузка — давайте выкинем нормальную форму нафиг, но при этом, вместо использования стандартных механизмов хранения часто требуемых данных во всяких кешах, завести опять таки в реляционной БД, специально денормализованные таблицы.
В общем и новизны нет, и не похоже, что решение оптимально и вообще адекватно задаче.2.7 Масштабирование системы баннерной рекламы с централизованной базой данных
Примитивная и кривоватая реализация баннероторговли и баннеропубликации на Oracle.
Зачем там Oracle — совершенно непонятно, скорее всего унаследованный код финансовых модулей на PL/SQL, которых лень переписывать, вокруг чего начали воротить все остальное. Ибо надежность там не нужна, транзакционность и немедленность реакции — тоже (грузят апельсины бочками данные SQLLoaderом), вообще как-то все ---. Похоже еще есть момент экономии на лицензиях (другой логики для централизованности СУБД я не вижу).
Бизнес примитивный и надеюсь скоро вымрет, когда баннерорезки будут у всех, кроме полных даунов (и накручивающих трафик роботов), а реклама станет контекстной и уйдет в поисковики.
[ List view ]Comments
Please login to comment.