программа для оптимальной производительности и масштабируемости с самого начала? - PullRequest
1 голос
/ 07 июня 2009

Первый вопрос по stackoverflow. У меня нет предыдущего опыта работы с веб-сайтом с большим трафиком, и я бы посчитал себя где-то между новичком и программистом среднего уровня ... пожалуйста, будьте осторожны:)
Я пытаюсь создать социальный сайт, который, как я надеюсь, в конечном итоге будет обрабатывать много трафика и пользователей. Тем не менее, я не знаю, будет ли концепция работать, и программирование для масштабируемости - это много дополнительной работы по сравнению со сложением неаккуратного кода, который функционально работает одинаково. Кроме того, поскольку я относительно не осведомлен о программировании для высокой масштабируемости, я обнаружил, что провожу много исследований, которые еще больше меня тормозят (highscalability.com удивительно ... В настоящее время я пытаюсь выяснить автономные очереди)

Мой вопрос, должен ли я:
A)
1. собрать некоторый неоптимальный, но функциональный код (несколько небрежный код, чрезмерные запросы к базе данных, отсутствие кэшей и т. Д.)
2. работа по сбору трафика
3. переписать и реструктурировать код

или Б)
1. Полностью исследуйте масштабируемые проекты и применяйте их с самого начала, поэтому мне не нужно много реструктурировать
2. работа по сбору трафика

Любой совет приветствуется, спасибо.

Ответы [ 4 ]

4 голосов
/ 07 июня 2009

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

Я предлагаю вам начать с получения книги от 37 Signals Crew - Getting Real: http://gettingreal.37signals.com/

Смешайте A и B. Постарайтесь получить хорошую ситуацию с хостингом. Подумайте о способах , которые вы можете кэшировать (memcache - это просто). Пишите четкий код, но не тратьте слишком много времени ...

«Выпуск досрочно, выпуск часто».

-

Вот рассказ о двух проектах.

  1. Разработано в свободное время - взломано вместе - выпущено рано (и часто). Он вырос до 15 000 пользователей и 6 000 000 просмотров в месяц (за 5 месяцев).
  2. Разработано в корпоративном менталитете «сделай все, что нужно». Заняло 4 месяца, 10+ человек, десятки тысяч долларов. Он достиг максимума у ​​~ 100 пользователей.

Пусть мудрость направляет вас ...

3 голосов
/ 07 июня 2009

Я бы выбрал вариант А. Генерировать трафик на сайт намного сложнее, чем повышать производительность. Если ваша идея уникальна, то ваша цель - выход на рынок. http://highscalability.com/ содержит множество хороших статей о том, как другие решали проблемы масштабируемости.

2 голосов
/ 07 июня 2009

Потратьте пару недель на изучение Кэла Хендерсона * Создание масштабируемых веб-сайтов , Масштабируемых интернет-архитектур Тео Шлосснагла , и, конечно, сайт, который вы уже нашли, превосходного Тодда Хоффа highscalability.com . Как минимум, вы поймете компромиссы между (A) и (B) и сможете принять лучшее решение.

Также проведите время за просмотром Amazon Web Services , особенно их EC2 (Elastic Cloud Computing) и S3 (Simple Storage System). Группа в моей компании только что развернула веб-приложение в инфраструктуре Amazon, и это было значительно проще, чем пытаться запустить его на собственном физическом оборудовании.

Если вы все еще находитесь на ранней стадии идеи и просто хотите отработать свои идеи и провести небольшие эксперименты, (A) сработает хорошо. Но как только вы решите, что хотите развернуть небольшую пробную версию, ведущую к полнофункциональному продукту, вам абсолютно необходимо следовать (B).

Когда вы начнете переходить в режим (B), я бы предложил вам использовать AWS, чтобы сэкономить почти все усилия и капитальные затраты при настройке собственной инфраструктуры. Используйте часть времени, которое вы сэкономите, используя AWS, чтобы полностью выучить (B) и применить уроки. Тогда, если вам это удастся, ваша масштабируемая архитектура позволит вам арендовать столько машинных часов AWS, сколько вам нужно. Если у вас ничего не получится, вы узнаете много очень полезных вещей, которые можно применить к вашей следующей идее (или работе) для стартапа.

Имейте в виду, что это не вариант выбора. Как только вы поймете основные принципы масштабирования, вы сможете начать с пути (B) с чем-то простым, и в то же время почувствовать себя комфортно, зная, как вы перейдете к следующему шагу. У Данги есть несколько очень интересных презентаций по этим направлениям. Взгляните на этот , и вы увидите, как они начинали с одной машины, переключились на машину сервера приложений и машину базы данных, на три сервера приложений и машину базы данных и так далее.

1 голос
/ 07 июня 2009

Это звучит как A), что приведет к неаккуратному, плохо продуманному коду, который работает, но не будет хорошо масштабироваться и почти наверняка потребует переписать , если у вас уже есть пользователи и вам необходимо предоставить Провел . Устранение проблем, которые можно было решить, если у вас уже есть дорожные звуки, напоминающие кошмар.

Я бы определенно пошел с B). Размышление, исследование и планирование архитектуры вашего приложения, не только для оптимизации или производительности, но и просто для разумного общего дизайна, является абсолютной необходимостью для любого нетривиального программного приложения.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...