Рубрика «highload» - 21

в 8:13, , рубрики: evernote, highload, архитектура системы, Блог компании Evernote Corporation, серверы, метки: , , ,

В прошлогоднем обзорном посте, посвященном архитектуре Evernote, мы дали общее описание серверов — “шардов”, которые используем и для хранения данных и для логики приложений. Поскольку Evernote — более персональный сервис, чем, скажем, социальная сеть, то мы можем легко разнести данные отдельных пользователей по различным шардам, чтобы обеспечить достаточно простую линейную масштабируемость. Каждая пара таких шардов управляет двумя виртуальными машинами:

image

Каждая из этих виртуальных машин хранит транзакционные “метаданные” в базе данных MySQL на массиве RAID-1 из пары 300-гигабайтных дисков Cheetah со скоростью вращения шпинделя 15000 rpm. Отдельный массив RAID-10 из 3-терабайтных дисков Constellation (7200 rpm) разбит на разделы для хранения больших файлов текстового поискового индекса Lucene для каждого пользователя. Спаренные виртуальные машины дублируют каждый из этих разделов от текущей основной к текущей дополнительной машине с помощью синхронного DRBD.
Читать полностью »

в 8:58, , рубрики: highload, mysql, Веб-разработка, метки: ,

Предыстория

Есть проект, в рамках которого приходится работать с большим объем данных. В частности есть одна денормализованная таблица, в которой хранятся все актуальные предложения существующих клиентов, а также устаревшие предложения, помеченные is_deleted = 1, ожидающие удаления.

Количество записей в данной таблице до недавнего времени колебалось от 30 до 50 миллионов. Обычный OPTIMIZE даже при таких условиях не всегда срабатывал. Поэтому отец-основатель (Евгений Васильевич aka haron) придумал пересобирать таблицу таким образом: все актуальные (is_deleted = 0) копировались в таблицу с идентичной структурой с добавлением префикса по дате и времени, а когда копирование завершалось, оставалось только удалить исходную таблицу, а новую переименовать в исходную.

Такой подход работал надежно, пока не потребовалось повысить скорость поиска предложений. И тут начинается наша небольшая история.Читать полностью »

в 19:02, , рубрики: actor model, akka, comet, highload, java, play framework, scala, высокая производительность, метки: , , , ,

Измерение производительности Play Framework 2.0

Я уже рассказывал о программной платформе Typesafe Stack 2.0. В том посте шла речь об одном из компонентов платформы — фрэймворке Akka 2.0, реализующем модель акторов на JVM. Сегодня я хочу написать о возможностях другой составляющей Typesafe Stack — фрэймворке Play 2.0. Хотя о функциональности данного компонента уже рассказывали здесь и здесь, тема производительности решений под управлением Play 2.0 по-моему осталась не раскрытой.

Тестирование фрэймворка будет проводиться с помощью простейшего приложения разработанного на его основе. В результате выполнения тестов необходимо ответить на следующие вопросы. Какое максимально возможное количество одновременных подключений? Сколько оперативной памяти потребляют эти подключения? Сколько запросов в единицу времени может обработать тестируемое приложение?
Читать полностью »

в 9:05, , рубрики: devconf, highload, php, Блог компании DevConf, Веб-разработка, высокая производительность, метки: , ,

[HighLoad] Алексей Рыбак: мастер класс — Основы построения масштабируемых высоконагруженных веб проектов 10 июня 2012
Интервью с ведущим МК на DevConf2012 — Алексеем Рыбаком (Badoo.com)
devconf.ru/offers/31

Это мой хобби-проект где-то с 2006 года, и я постоянно его дополняю.
Это крайне интересный опыт, он сильно отличается от того, что я приобретаю на работе, поэтому буду читать до тех пор, пока не надоест.

Только-только устоялись базовые подходы к разработке масштабируемых приложений, ещё каких-то 10 лет назад нашей отрасли вообще толком не существовало! Мы по-прежнему далеки от каких-то сред разработки или фреймворков, которые дали бы нам все необходимые решения из коробки. Начинает появляться некоторое количество технологий и инструментов, которые продвигаются именно как универсальное решение проблем масштабирования.
Читать полностью »

в 20:23, , рубрики: golang, highload, Веб-разработка, высокая производительность, метки: ,

Неуловимый Go.

Помните анекдот про неуловимого Джо? Именно восклицанием «Да кому он нужен!», прозвучавшим в форме вопроса "ЗАЧЕМ?", был встречен на Хабре релиз первой стабильной версии GO 1.

Именно на этот вопрос я хочу ответить циклом статей, оформленных в необычном для Хабра формате — в виде пошаговой совместной разработки действующего веб-проекта — с живым обсуждением и добавлением функционала. А чтобы вдвойне оправдать внесение цикла ещё и в хаб «Высокая производительность», мы поставим перед собой задачу создать не просто «хомяка», а проект, который наглядно продемонстрирует habri et orbi способность выдерживать значительные естественные нагрузки.

Вместо аперитива: реализация простейшего динамического веб-приложения на языке Go работает в 5-20 раз быстрее аналогичной Python-реализации. И всего в два раза уступает скорости отдачи статики Nginx-ом.

В рамках этого проекта, помимо самого языка Go, мы косвенно затронем и другие (относительно новые) технологии веб-разработки — HTML5, CSS3, Redis, MongoDB. Также я постараюсь вытащить из закутков долговременной памяти некоторые из трюков в области безопасности и экономии на спичках, коих накопилось много за полтора десятка лет работы в этой области. Устраивайтесь поудобнее, запасайтесь терпением и кофе — под катом «много букв», а ведь это только вводная часть :)
Читать полностью »

1...10...192021
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js