Как вы планируете создание сайта?

Ответ 1

Некоторые моменты, которые вам нужно знать, чтобы сделать это планирование

• Сколько пользователей в день.
• Сколько данных вы собираетесь контролировать.
• Сколько данных вы собираетесь показывать каждому пользователю.
• Средняя пропускная способность пользователя.
• Среднее время пользователя, использующее ваш сайт.

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

Мера

С вне сайта, с опытом, у вас нет реальных мер. Без каких-либо мер вы действительно не можете быть уверены, но вы можете следовать некоторым руководствам

• Что бы вы ни делали, try to make the grow of your data/features/runs linear and not logarithmic.
• The speed of your site is not (only) depend from the capacity and the speed of your computer. Зависит только тогда, когда компьютер находится на своем пределе. Если компьютер достигает своего предела, вы добавляете дополнительный ресурс. Но скорость должна быть осторожна, когда вы разрабатываете программное обеспечение, а дорогое программное обеспечение скорости тоже стоит.
• У вас есть миллионы данных каждый день в базе данных? вам нужно больше бара и жесткого диска
• У вас есть видео и много больших файлов для отправки? вам нужно увеличить пропускную способность.
• У вас есть люди, которые используют сайт для работы? вам нужна больше скорости и стабильности
• Вы создаете еще один сайт для электронной коммерции? вам нужно повысить безопасность со стабильностью

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

Планирование скорости.

Performance and Capacity: Two diffident animals*. Производительность основывается на более человечной работе, и ее способность базируется на большем количестве компьютерных ресурсов. Чтобы ускорить работу, вам нужно сначала узнать, как заставить компьютер работать плавно и быстро, а затем узнать, как общие трюки, чтобы программы выполнялись быстро, особенно в Интернете, а затем вам действительно нужно тратить больше времени на после его запуска, чтобы улучшить его для производительности в критических областях.

Планирование расширения.

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

Планирование с ограничениями

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

Вы также не создали код, который использует ресурсы многокомпьютера. И когда вы запустите его, вы позаботитесь, чтобы он работал только под одним пулом, чтобы работать правильно.

Этот дизайн с одним пулом более прост в разработке, проще отлаживать, легко контролировать, легко обновлять багги-код и дешевле, но страдает от скорости (один пользователь ждет другого в одном пуле потоков) и не может расширяться в ресурсе, что на самом деле также нужно делать со скоростью.

Поиск статистики

Если вы не знаете, сколько у вас пользователей, вы можете использовать alexa для просмотра похожих сайтов с вашими и средними пользователями/и средними просмотрами страниц в месяц. Тогда вы можете узнать о возможной полосе пропускания.

Не покупайте, прежде чем вам это нужно

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

Автомобиль или Формула-1?

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

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

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

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

Точка зрения клиента

Then, the customer says "I need to support 1000 users" Ну, клиент не знал программирования и пытался найти меру с его точки зрения для сравнения предложений. На самом деле здесь гораздо больше факторов, и 1000 пользователей не являются правильным параметром. Является ли 1000 пользователей в день в минуту или в месяц? Нужны ли для поддержки в режиме реального времени чаты или нужны для просмотра большого количества данных или для быстрой работы? Так что, возможно, это зависит от вас, чтобы правильно продать вашу программу в эфире клиента, объяснив ему, что хорошая программа хороша для одного пользователя из миллиона пользователей, и на самом деле ее начало - это стоимость разработки, а не пользователей.

Теперь, если это вопрос для фактического планирования сайта, тогда простой ответ конечной точки - это начать делать это, а остальное будет показано. Если это вопрос, потому что вы ищете ответы для своего клиента, то вы должны спросить себя: почему Formula One сидят только на одном, и ваш автомобиль может поместиться пять? или сколько стоит фильм? или мы все знаем, как писать, но почему не все из нас пишут и публикуют книгу? Моя точка зрения заключается в том, что стоимость фактически зависит от времени, которое вы тратите на создание проекта, а сам пользователь сам не может этого определить.

Угадай, знай или предсказание?

How do you make a guess about the number of servers, bandwidth, storage, etc... Мы на самом деле не догадываемся, у нас много сайтов, мы собираем каждый день многие статистические данные автоматически, многолетний опыт, и мы знаем из содержания сайта, сколько пользователей может иметь в день и сколько полосы пропускания может есть. У нас также есть много баз данных, которые работают на наших серверах, и мы можем видеть, сколько данных они используют. Для 99% наших сайтов - все, что мало. Так что это знания и опыт, с реальной статистикой в ​​реальном времени. Прогнозирование происходит путем мониторинга трафика и их использования, мы стараемся сделать их лучше, чтобы получить больше трафика, больше пользователей и из того, что мы архивируем, мы пытаемся предсказать, если им понадобится больше ресурсов в будущем. Кроме того, 99% сайтов - это один пул, в котором работают очень простые презентации.

'* Из книги

Ответ 2

Часто это очень сложно, так как система даже не разработана, когда клиент просит ответа на этот вопрос. Это невозможно.

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

Использование дискового пространства для системы документов - это просто количество документов, умноженное на средний размер. Полоса пропускания - это количество запросов, умноженное на средний размер запросов.

Вы просто задокументируете все свои предположения и скажете, что требования к оборудованию основаны на этих предположениях.

Ответ 3

При разработке недавнего сайта ASP.NET MVC я использовал selenium для загрузки теста на мой сайт. В основном вы записываете подборку макросов, в которых вы выполняете случайные задачи.

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

Ответ 4

which figures of reference do you use?

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

Небольшой пример: миллиард запросов в час для двоичного числа в 8 байтов не приведет к сбою и может быть запущен с самого простого веб-сервера. Причиной этого является то, что время запроса будет составлять миллисекунды. Есть 1000 (мс/с) * 60 (с/м) * 60 (м/ч) * 24 (ч/д) = 86,4 миллиона миллисекунд за один день, что означает, что даже если каждый запрос занял миллисекунду 1 миллион требуется, чтобы все еще было доступно, поскольку требуемая скорость для получения 8 байтов была бы в диапазоне 8 кбит/с.

Реальная версия: просмотр данных будет определять требования, а данные, которые извлекаются, почти всегда находятся в базе данных. Дизайн базы данных (даже если концептуально) может помочь определить, сколько данных будет использоваться. В реальной жизни существует множество требований. Максимальная емкость базы данных или файловой системы должна быть проверена. Эту емкость можно вычислить, посмотрев, сколько пространства потребуется каждой строке таблицы, суммируя общее пространство, потребляемое каждым столбцом (то есть идентификатор типа int длиной 6 займет 6 байтов или пробел). После суммирования каждого столбца из одной строки таблицы для каждой таблицы в базе данных будет легко определить, сколько памяти потребуется каждой коллекции таблиц (обычно таблицы связаны через внешние ключи). После учета потребления памяти в таблице пользователи должны быть проверены на соответствие требованиям. В основном интерес представляет то, сколько таблиц каждый пользователь будет получать за каждый сеанс (без данных это будет gesstimation - лучше всего переоценить). Поскольку мы уже знаем или имеем хорошую идею, каков размер таблиц базы данных, мы можем предположить, сколько памяти сервера потребуется пользователю. Сравнение использования этой памяти с количеством ожидаемых пользователей поможет определить, какой сервер использовать или сколько. Далее, чтобы выяснить, сколько таблиц будет (опять же, в среднем gesstimation или с некоторыми собранными тестовыми данными), вставленными в базу данных в результате действий пользователя. Это очень спекулятивно и лучше всего делать с тестированием. Без тестирования предположения следует переоценить. Исходя из того, сколько строк каждый пользователь будет вставлять, можно будет экстраполировать размер базы данных и требования к пропускной способности. Это будет определяться путем расширения требований к данным одного пользователя, требований n пользователей в раз. Данные, требуемые русскими пользователями, позволят увидеть требования к пропускной способности в течение t времени, а также будут определять, как n пользователей будет увеличивать базу данных в течение t времени.

Ответ 5

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

Помните, что в один прекрасный день планирование стоит столько же, сколько дополнительная машина в течение года.

Ответ 6

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

Давайте начнем с производительности, и если вы имеете дело с сетевой архитектурой, где вы обслуживаете ресурсы, то это действительно довольно просто и может быть разделено на 2 разных KPI; время отклика сервера и время загрузки страницы (это должно называться ресурсным временем загрузки, поскольку не все ресурсы в Интернете являются веб-страницами).

Время ответа сервера измеряет время до последнего байта для запроса на заданный ресурс. Обратите внимание, что это не включает такие вещи, как согласование контента. Вы (или бизнес) должны указать ожидаемое время отклика сервера для данных типов ресурсов. Это основано на одном запросе/ответе, например, ответе на запрос для любого ресурса, который подпадает под тип "Модель автомобиля", должно занимать не более 0,5 секунд, время до последнего байта.

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

После того, как вы указали оба варианта, вы можете начать определять непосредственную емкость вашей системы. Сколько запросов в секунду для ресурсов я могу сделать эффективно (как указано выше). Есть множество инструментов, которые помогут вам определить это. Это даст вам немедленную меру. Вы заметите, что я использую термин "немедленный", потому что часто бизнес может развернуться и сказать, здорово, но что произойдет, если нам нужно увеличить эту емкость.

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