Что наиболее важно для создания архитектуры веб-приложения? Масштабируемость, ремонтопригодность или производительность?

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

  1. Масштабируемость
  2. Поддерживаемость кода
  3. Производительность

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

масштабируемость >> ремонтопригодность >> производительность

Эти результаты меня несколько удивили, поскольку я всегда считал, что производительность является ключевым фактором для создания масштабируемых систем.

  1. Что вы думаете о важности этих трех факторов?
  2. Я также утверждал, что для их достижения необходимо заранее тщательно планировать и проектировать. Есть ли у вас какие-либо другие обязательные советы?

web-applications performance scalability maintainability web-architecture
person Rene Pickhardt    schedule 29.07.2013    source источник
comment
единственная наихудшая стратегическая ошибка, которую может совершить любая софтверная компания: они решили переписать код с нуля. joelonsoftware.com/articles/fog0000000069.html   -  person PiTheNumber    schedule 07.08.2013

Ответы (2)


arrow_upward
0
arrow_downward

Масштабируемость отличается от производительности.

Производительность обычно измеряется скоростью выполнения отдельного запроса. На моей локальной машине с еще одним пользователем мои запросы обычно очень быстрые, 10 мс или меньше. Теперь поместите это на внешний интернет-сервер с 50 000 одновременных пользователей, и вы не увидите таких скоростей.

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

Если это сайт социальной сети, я бы ранжировал элементы следующим образом:

Масштабируемость > Производительность > Обслуживание

person Tim P.    schedule 29.07.2013

arrow_upward
0
arrow_downward

Я считаю, что это должно быть

ремонтопригодность >> масштабируемость >> производительность

Масштабируемость/производительность

Для меня масштабируемость — это особый вид проблемы с производительностью. Производительность также включает время отклика. Но я бы оценил масштабируемость как более важную, чем время отклика. Особенно для социальной сети. Но оба типа близки друг к другу в этом сравнении.

Как правило, проблемы с производительностью — это то, с чем вам лучше всего справляться, если они появляются. Если вы попытаетесь оптимизировать свой код для проблемы, с которой не сталкивались, вы, скорее всего, просто потратите свое время. Что вы можете сделать, так это имитировать пользовательский трафик на странице, чтобы вызвать проблемы с производительностью.

Ремонтопригодность

Для меня важнее ремонтопригодность, потому что это дороже. Об этом был пост в блоге stackoverflow, но я не могу его найти прямо сейчас. Проблемы с производительностью в основном можно решить, если вы просто купите лучшее / больше оборудования и бросите его на проблему. Оборудование относительно дешевое и постоянно дешевеет. Действительно дорого стоит время кодирования программистов.

person PiTheNumber    schedule 07.08.2013