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

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

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

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

performance hardware capacity-planning
person Boolean    schedule 14.01.2010    source источник
comment
Вау - это нагруженный вопрос. :)   -  person George Johnston    schedule 14.01.2010
comment
Это наука о планировании мощностей, плюс программная архитектура, плюс все остальное, так что ответ 42.   -  person Nikolai Fetissov    schedule 14.01.2010
comment
Все ответы были полезными. Спасибо - Бала   -  person Boolean    schedule 19.01.2010

Ответы (3)


arrow_upward
2
arrow_downward

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

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

Вы можете просмотреть раздел «Извлеченные уроки» в StackOverflow Architecture. .

person Sudhanshu    schedule 14.01.2010
comment
10. Оптимизируйте/разработайте свое приложение для последовательного доступа к диску, когда это возможно. Как этого добиться, учитывая такой веб-сайт, как переполнение стека. 7 Объединяйте небольшие файлы в более крупные фрагменты, также известные как BigTable, HBase. Я думаю, что это распределенная база данных с ключевым значением. Есть ли учебник? - person Boolean; 14.01.2010
comment
HBase основан на Google BigTable. В ссылке на HBase, которую я предоставил, есть все, что вам нужно для начала работы (но HBase может не обязательно быть лучшим решением для того, что вам нужно - сначала определите свои точные требования к хранилищу данных, а затем решите, подходит ли он для того, что вы хотите). Для чего-то вроде stackoverflow вам нужно выяснить, какие наиболее распространенные операции выполняются (после запуска сайта потребуются измерения, мониторинг и т. д.). Тогда вы захотите оптимизировать самые верхние операции. Помните, что оптимизация происходит после развертывания (даже если ее нужно немного переписать). - person Sudhanshu; 14.01.2010
comment
Вы можете попробовать это для HBase: stackoverflow.com/questions/tagged/hbase stackoverflow.com/questions/1750556/ - person Sudhanshu; 15.01.2010

arrow_upward
1
arrow_downward

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

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

person jspcal    schedule 14.01.2010
comment
Собственно вопрос у меня общий и не хочется покупать дорогостоящие сервера. Я планирую написать приложение Hadoop для анализа данных. Я просто хочу знать, есть ли какие-либо тематические исследования по этому поводу. - person Boolean; 14.01.2010
comment
попробуйте это исследование: highscalability.com/ - person jspcal; 15.01.2010

arrow_upward
1
arrow_downward

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

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

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

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

person Stephan Eggermont    schedule 14.01.2010
comment
но есть проблема с единой точкой отказа справа. как вы этого избежите. - person Boolean; 14.01.2010