Подтвердить что ты не робот

Почему Windows Azure не масштабируется?

Я пытаюсь масштабировать веб-сайты на Widows Azure. До сих пор я тестировал Wordpress, Ghost (блог) и простой HTML-сайт и все равно: если я масштабирую их (добавляю экземпляры), они не будут быстрее. Я уверен, что должен сделать что-то неправильно... Это то, что я сделал:

  • Я создал новый общий веб-сайт с простым шаблоном HTML Bootstrap. http://demobootstrapsite.azurewebsites.net/
  • Затем я установил ab.exe из Apache Project на хостинг-сервере (4 ядра, 12 ГБ оперативной памяти, 100 Мбит).

Я провел тест два раза. Первый раз с одним общим экземпляром и во второй раз с двумя общими экземплярами с помощью этой команды:

ab.exe -n 10000 -c 100 http://demobootstrapsite.azurewebsites.net/

Это означает, что ab.exe собирается создать 10000 запросов со 100 параллельными потоками.

Я ожидал, что время ответа теста с двумя общими экземплярами будет значительно ниже, чем время ответа только с одним общим экземпляром. Но среднее время на запрос даже немного выросло с 1452,519 мс с одним общим экземпляром до 1460,631 мс с двумя общими экземплярами. Позже я даже запустил сайт на 8 общих экземплярах без какого-либо эффекта. Моя первая мысль заключалась в том, что, возможно, общими случаями являются проблемы. Поэтому я разместил сайт на стандартной виртуальной машине и снова проверил тест. Но проблемы остаются прежними. Кроме того, добавление большего количества экземпляров не сделало сайт более быстрым (даже немного медленнее).

Позже Я снял видео со Скоттом Гензельманом и Стефаном Шакову, в котором они объяснили функции Azure Scaling. Стефан говорит, что Azure имеет своего рода "липкую балансировку нагрузки", которая будет перенаправлять клиента всегда на тот же экземпляр/виртуальную машину, чтобы избежать проблем совместимости с statefull-приложениями. Поэтому я проверил журналы WebServer, и я нашел файл журнала для каждого экземпляра с примерно один и тот же размер. Обычно это означает, что каждый экземпляр использовался во время теста.

PS: Во время тестового прогона я проверил время отклика веб-сайта с моего локального компьютера (из другой сети, кроме сервера), и время ответа было около 1,5 секунд.

Вот результаты теста:

###################################### 
1 instance result
###################################### 

PS C:\abtest> .\ab.exe -n 10000 -c 100 http://demobootstrapsite.azurewebsites.net/
This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking demobootstrapsite.azurewebsites.net (be patient)
Finished 10000 requests


Server Software:        Microsoft-IIS/8.0
Server Hostname:        demobootstrapsite.azurewebsites.net
Server Port:            80

Document Path:          /
Document Length:        16396 bytes

Concurrency Level:      100
Time taken for tests:   145.252 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      168800000 bytes
HTML transferred:       163960000 bytes
Requests per second:    68.85 [#/sec] (mean)
Time per request:       1452.519 [ms] (mean)
Time per request:       14.525 [ms] (mean, across all concurrent requests)
Transfer rate:          1134.88 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   14   8.1     16      78
Processing:    47 1430  93.9   1435    1622
Waiting:       16  705 399.3    702    1544
Total:         62 1445  94.1   1451    1638

Percentage of the requests served within a certain time (ms)
  50%   1451
  66%   1466
  75%   1482
  80%   1498
  90%   1513
  95%   1529
  98%   1544
  99%   1560
 100%   1638 (longest request)

###################################### 
2 instances result
###################################### 

PS C:\abtest> .\ab.exe -n 10000 -c 100 http://demobootstrapsite.azurewebsites.net/
This is ApacheBench, Version 2.3 <$Revision: 1528965 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking demobootstrapsite.azurewebsites.net (be patient)
Finished 10000 requests


Server Software:        Microsoft-IIS/8.0
Server Hostname:        demobootstrapsite.azurewebsites.net
Server Port:            80

Document Path:          /
Document Length:        16396 bytes

Concurrency Level:      100
Time taken for tests:   146.063 seconds
Complete requests:      10000
Failed requests:        0
Total transferred:      168800046 bytes
HTML transferred:       163960000 bytes
Requests per second:    68.46 [#/sec] (mean)
Time per request:       1460.631 [ms] (mean)
Time per request:       14.606 [ms] (mean, across all concurrent requests)
Transfer rate:          1128.58 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   14   8.1     16      78
Processing:    31 1439  92.8   1451    1607
Waiting:       16  712 402.5    702    1529
Total:         47 1453  92.9   1466    1622

Percentage of the requests served within a certain time (ms)
  50%   1466
  66%   1482
  75%   1482
  80%   1498
  90%   1513
  95%   1529
  98%   1544
  99%   1560
 100%   1622 (longest request)
4b9b3361

ОТВЕТЫ

Ответ 1

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

Например; предположим, что Small VM может принимать 100 запросов в секунду, обрабатывая каждый запрос на 1000 мс (и если это было 101 запрос в секунду, каждый запрос начал бы замедляться, чтобы сказать 1500 мс), то масштабирование до большего количества малых виртуальных машин не увеличит скорость при котором один запрос может обрабатываться, он просто увеличивает нас до 200 запросов в секунду при 1000 мс каждый (так как теперь обе машины не перегружены).

Для производительности по запросу; сам код (и производительность процессора Azure VM) повлияет на то, как быстро может быть выполнен один запрос.

Ответ 2

Учитывая полное отсутствие в вопросе о наиболее важной детали такого теста, мне кажется, что вы просто проверяете свою пропускную способность интернет-соединения. 10 Мбит/с - очень распространенная ставка.

Нет, он не масштабируется.

Ответ 3

Я обычно запускаю logparser против журналов iis, которые были сгенерированы во время теста нагрузки, и вычисляет RPS и задержку (время, занятое поле). Это помогает изолировать медленность от сети, до обработки сервера до фактического отчета по тестированию нагрузки.

Ответ 4

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

Например, если базовый уровень показывает, что веб-сайт отвечает в 1,5 с запросами, когда он не находится под нагрузкой, и снова с 1,5 с под нагрузкой, то это означает, что веб-сайт легко справляется с нагрузкой. Если под нагрузкой веб-сайт занимает 3-4 секунды с использованием одного экземпляра, то это означает, что он не обрабатывает нагрузку так хорошо - попробуйте добавить еще один экземпляр и проверьте, улучшено ли время ответа.

Ответ 6

Некоторые идеи:

  • Является ли Azure дросселированием, чтобы предотвратить атаку DOS? Вы делаете множество запросов из одного места на одну страницу.
  • Попробуйте небольшие веб-сайты, а не общие. Емкость и масштабирование могут быть совершенно разными. Загрузка 50 запросов/сек не кажется ужасной для общей службы.
  • Попробуйте определить, где это время. 1.4s - это действительно долгое время.
  • Выполнять тесты нагрузки с нескольких разных компьютеров одновременно, чтобы определить, происходит ли дросселирование, или на вас влияет литая балансировка нагрузки или другие сетевые артефакты.
  • Вы сказали, что это нормально при нагрузке около 10 одновременных запросов на 50 запросов/секунду. Постепенно увеличивайте нагрузку, которую вы кладете на сервер, чтобы определить точку, в которой он начинает задыхаться. Сделайте это и на нескольких машинах.
  • Можете ли вы войти на веб-сайты? Вероятно, не... посмотрим, можете ли вы реплицировать те же проблемы на веб-роли Cloud Service и анализировать оттуда с помощью Performance Monitor и типичных инструментов IIS, чтобы увидеть, где узкое место, или даже на машине или в инфраструктуре Azure.