Метка «highload» - 6

в 10:42, , рубрики: highload, memcached, nginx, php, Веб-разработка, метки: , ,

Делаю полностью статичный сайт. На самом деле, php выполняет роль бэкенда: если html файла нет, то сгенерировать его и положить в кэш, а далее nginx отдает html файл из кэша сразу, не трогая php вообще.

Сайт должен получиться огромным. Покрайней мере, я сразу стараюсь делать из расчета на высокую нагрузку. И на данный момент, когда php выполняется лишь единожды для генерации страницы, теперь самое узкое место — это отдача уже готовых статичных html файлов.

Следует знать, что при обращении к файлу он помещается в кэш в оперативной памяти ядром системы, и поэтому, как многие думают, заранее хранить статику в каком-нибудь tmpfs нет смысла, совсем. memcached же именно это и делает, и по какой-то причине все его нахваливают, и особенно любят использовать для кэширования html страниц.

Я убедился в обратном и хочу поделиться с вами, что хранить кэш html страниц в memcached не стоит, и какая есть ему лучшая альтернатива.Читать полностью »

в 10:42, , рубрики: flash-память, highload, Блог компании КРОК, высокая производительность, высоконагруженные приложения, жесткие диски, ит-инфраструктура, цод, метки: , , , ,

Современный сервер – это электронное устройство, где движущихся механических частей почти нет. Почти – потому что жесткий диск, например, ярко выделяется в этом ряду.

Flash память в дата центрах: почему она иногда дешевле жестких дисков?
Всё это в некоторых случаях можно заменить на одно компактное устройство

При передаче информации между электронными компонентами сервера технологическим пределом является скорость света. Жесткий диск же не может крутиться неограниченно быстро, и его скорость упирается в механику. Следовательно, скорость обработки информации им в сотни и тысячи раз медленнее, чем в процессорах и памяти. Читать полностью »

в 5:14, , рубрики: highload, Блог компании Dell, высокая производительность, Железо, коммутация, Облачные вычисления, цод, метки: , , , ,

На Хабре было уже достаточно много топиков на тему ЦОД и вычислительных кластеров, но интересно ли Вам, на каком оборудовании работает гигант facebook или, например, Московский Internet Exchange? Что лежит в основе СКИФ—МГУ «Чебышёв» и какие «железки» в своей сети использует Большой адронный коллайдер? Добро пожаловать под кат, как говорится!

Осторожно! Много картинок и текста.
Читать полностью »

в 3:10, , рубрики: highload, innodb, mysql, mysql performance, replication, метки: , , , ,

Данный пост не будет рассказывать про индексы, планы запросов, триггеры для построения агрегатов и прочие общие способы оптимизации запросов и структуры БД. Так же не будет рассказывать про оптимальные настройки с префиксом innodb_. Возможно прочитав текст ниже вы лучше поймёте смысл некоторых из них. В данном посте речь пойдёт об InnoDB и его функционирование.

Какие проблемы может помочь решить этот пост?

  • Что делать если у вас в списке процессов множественные селекты которым казалось бы никто не мешает?
  • Что делать если всё хорошо настроено, запросы пролетают как ракеты и список процессов постоянно пустой, но на сервере высокий LA и запросы начинают работать немного медленнее, ну например вместо 100мс получается 500мс ?
  • Как быстро масштабировать систему, когда нет возможности всё переделать?
  • У вас коммерческий проект в конкурентной среде и проблему надо решать немедленно?
  • Почему один и тот же запрос работает то быстро то медленно?
  • Как организовать быстрый кеш и поддерживать его в актуальном состояние?

Читать полностью »

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