Оценка товарного оборудования для приложения - PullRequest
Новая
       31

Оценка товарного оборудования для приложения

1 голос
/ 14 января 2010

Предположим, я хотел разработать сайт переполнения стека. Как я могу оценить количество аппаратного оборудования, необходимого для поддержки этого сайта, исходя из 1 миллиона запросов в день. Существуют ли какие-либо тематические исследования, объясняющие возможные улучшения производительности в этой ситуации?

Я знаю, что узкое место ввода / вывода является основным узким местом в большинстве систем. Каковы возможные варианты улучшения производительности ввода / вывода? Немногие из них, которых я знаю,

  1. кэширование
  2. Репликация

Ответы [ 3 ]

2 голосов
/ 14 января 2010

Вы можете улучшить производительность ввода-вывода несколькими способами в зависимости от того, что вы используете для настройки хранилища:

  1. Увеличьте размер блока файловой системы, если ваше приложение отображает хорошую пространственную локальность в своих операциях ввода-вывода или использует большие файлы.
  2. Используйте RAID 10 (чередование + зеркалирование) для производительности + избыточность (защита от сбоя диска).
  3. Используйте быстрые диски (Performance Wise: SSD> FC> SATA).
  4. Разделение рабочих нагрузок в разное время дня. например Резервное копирование в течение ночи, нормальный ввод-вывод приложений в течение дня.
  5. Отключите обновления atime в вашей файловой системе.
  6. Кэширует NFS-файл. A.k.a. Стог сена (Facebook), если хранит данные на NFS-сервере.
  7. Объединение небольших файлов в большие куски, a.k.a BigTable , HBase .
  8. Избегайте очень больших каталогов, т. Е. Большого количества файлов в одном каталоге (вместо этого делите файлы между разными каталогами в иерархии).
  9. Используйте кластерную систему хранения (да, не совсем стандартное оборудование).
  10. Оптимизируйте / проектируйте свое приложение для последовательного доступа к диску, когда это возможно.
  11. Используйте memcached . :)

Возможно, вы захотите взглянуть на раздел «Извлеченные уроки» Архитектура StackOverflow .

1 голос
/ 14 января 2010

1 миллион запросов в день - 12 в секунду. Переполнение стека достаточно мало, чтобы вы могли (с интересными приемами нормализации и сжатия) полностью разместить его в оперативной памяти 64-гигабайтного Dell PowerEdge 2970. Я не уверен, где кэширование и репликация должны играть роль.

Если у вас возникли проблемы с размышлениями о нормализации, доступен PowerEdge R900 с 256 ГБ.

Если вам не нравится единственная точка отказа, вы можете подключить несколько из них и просто отправить обновления через сокет (предпочтительно на отдельную сетевую карту). Даже пиковая нагрузка 12 К / с не должна быть проблемой для системы с основной памятью.

Лучший способ избежать узкого места ввода / вывода - не делать ввод / вывод (насколько это возможно). Это означает, что превайлер-подобная архитектура с пакетной записью (без проблем потерять несколько секунд данных), в основном файл журнала, и для репликации также записывает их в сокет.

1 голос
/ 14 января 2010

проверьте этот удобный инструмент:

http://www.sizinglounge.com/

и еще один гид от Dell:

http://www.dell.com/content/topics/global.aspx/power/en/ps3q01_graham?c=us&l=en&cs=555

Если вы хотите создать собственное сообщество, похожее на stackoverflow, вы можете зарегистрироваться с помощью StackExchange .

Вы можете прочитать некоторые тематические исследования здесь:

Высокая масштабируемость - как Rackspace теперь использует MapReduce и Hadoop для запроса терабайтов данных http://highscalability.com/how-rackspace-now-uses-mapreduce-and-hadoop-query-terabytes-data

http://www.gear6.com/gear6-downloads?fid=56&dlt=case-study&ls=Veoh-Case-Study

...