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

Load average: 100

вовсе не обязательно иметь, ИМХО.

вот у меня входящая скорость скорость интернета 512кбайт/секунду.

заголовок

GET / HTTP/1.1\r\nHost: spfng.com\r\n\r\n

весит 41 байт, плюс расход на сеть не знаю стека TCP/IP, пусть будет 64 байта итого.

512 кбайт / 64 байта = сервер должен выдерживать 8594 запроса в секунду. если выдерживает, значит хайлоад. если нет, значит я ламер криворукиЙ, не могу настроить его.

на данный момент мой блог на nginx, php-fpm, sqlite3 выдерживает 4200 запросов в секунду. я ламер криворукий. вот.

сервер должен выдерживать 8594 запроса в секунду.

«Выдержать» в смысле не свалиться или в смысле отдать контент?

Это маркетинговый термин, каждый по-своему понимает, но «я занимаюсь хайлоад-проектом» звучит круто. По сути обозначает ситуацию, когда при большом количестве запросов приходится что-то крутить на уровне архитектуры приложения, потому что обычное горизонтальное масштабирование плохо справляется. Кстати, количеством rps и la это никак не измеряется.

P.S. Вышесказанное - мое личное мнение и наблюдение.

отдать контент. обслужить всех клиентов. и чтобы никто не закрыл сайт обиженным. а то, что сеть нагружена на 100% и кто-то не сможет достучаться до хоста даже пингом, это просто форс-мажор, как во время пакет шторма или дос атаки. :)

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

ну это все сугубо имхо, может я ошибаюсь.

отдать контент.

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

а что серверу валиться?

Ограничения какие-нибудь на количество сокетов, или коннектов к БД, или еще что-нибудь зависящее именно от числа одновременных запросов.

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

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

Ограничения какие-нибудь на количество сокетов, или коннектов к БД

вот это уже интереснее, потому что ядро допустим тюнингуется, чтобы осблуживать диапазон портов от 1024 до 65536.

# sysctl -a | grep local_port_range
net.ipv4.ip_local_port_range = 32768	61000

а когда количество запросов на хост превысит (65536 - 1 - 1024), что тогда? тогда наверно создавать в DNS еще одну A-запись, куда вписать хост второй машины, осблуживающей тот-же самый сервер, и таким образом оно расширяется?

опять повторюсь, поэтому я сторож, что ничего не знаю. извините.

а когда количество запросов на хост превысит (65536 - 1 - 1024), что тогда?

я не сторож, но мне кажется, что на DoS'щем клиенте, возможно, кончатся порты. а серверу будет пофиг, зачем ему порт на каждое входящее соединение?

абсолютно каждому TCP/IP соединению присваивается порт, то что сервер прослушивает 80 порт, не значит, что он использует только его. на самом деле, порт задействуется на каждое подключение клиента к серверу, тобишь, подключаться 65к человек к серверу и все. приехали. сервер встанет.

да ладно. можно пруф? man tcp и man accept тебя не поддержали.

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

Интересные две строки. Как они относятся к моему вопросу? Занимает каждое tcp-соединение на стороне сервера целый отдельный порт? Если да, то где про это почитать?

Не занимает, пруф:

$ netstat -n | grep 178.248.233.6
tcp        0      0 10.0.1.210:39570        178.248.233.6:443       ESTABLISHED
tcp        0      0 10.0.1.210:39572        178.248.233.6:443       ESTABLISHED
tcp        0      0 10.0.1.210:39571        178.248.233.6:443       ESTABLISHED
tcp        0      0 10.0.1.210:39567        178.248.233.6:443       TIME_WAIT  
tcp        0      0 10.0.1.210:39566        178.248.233.6:443       TIME_WAIT

Но какую-нибудь vps'ку простенькую ты можешь положить даже при помощи ab:

$ ab -n 1000 -c 100 http://10.0.2.148:8080/test.html
This is ApacheBench, Version 2.3 <$Revision: 1604373 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 10.0.2.148 (be patient)
Completed 100 requests
Completed 200 requests
Completed 300 requests
Completed 400 requests
Completed 500 requests
Completed 600 requests
Completed 700 requests
Completed 800 requests
Completed 900 requests
Completed 1000 requests
Finished 1000 requests


Server Software:        SimpleHTTP/0.6
Server Hostname:        10.0.2.148
Server Port:            8080

Document Path:          /test.html
Document Length:        6 bytes

Concurrency Level:      100
Time taken for tests:   0.822 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      189000 bytes
HTML transferred:       6000 bytes
Requests per second:    1216.75 [#/sec] (mean)
Time per request:       82.186 [ms] (mean)
Time per request:       0.822 [ms] (mean, across all concurrent requests)
Transfer rate:          224.58 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.5      0       6
Processing:     2    5  36.3      4     816
Waiting:        1    5  36.3      3     816
Total:          3    5  36.5      4     821

Percentage of the requests served within a certain time (ms)
  50%      4
  66%      4
  75%      4
  80%      4
  90%      4
  95%      4
  98%      7
  99%      8
 100%    821 (longest request)

Все запросы с моего клиента (10.0.2.1) на 10.0.2.148:8080 ушли, на клиенте у меня соединений с сервером нет (потому что ab их побросал), а на сервере:

$ netstat -an | grep 10.0.2.1 | wc -l
1000

И выглядят они вот так (привожу часть):

tcp        0      0 10.0.2.148:8080         10.0.2.1:60063          TIME_WAIT  
tcp        0      0 10.0.2.148:8080         10.0.2.1:60295          TIME_WAIT  
tcp        0      0 10.0.2.148:8080         10.0.2.1:60856          TIME_WAIT  
tcp        0      0 10.0.2.148:8080         10.0.2.1:60398          TIME_WAIT  
tcp        0      0 10.0.2.148:8080         10.0.2.1:60194          TIME_WAIT  

Если запросов будет много на сервере можем получить, например, переполнение conntrack-таблицы, и все соединения сверх будут отваливаться. Ну и man C10K.

Не занимает, пруф

ОК, спуфи фигню спорол

Но какую-нибудь vps'ку простенькую ты можешь положить даже при помощи ab

А вот это меня уже совершенно не волнует, я не просил простыню.

А вот это меня уже совершенно не волнует,

А, ну ссори, только тебе нужно было Спуффингу отвечать, потому что в моем сообщении, на которое ты ответил, я говорил как раз об этом, мне показалось что есть вопросы и стоит проиллюстрировать.

а на сервере

1000

тащем-та, я о том и говорил, что это есть тот самый занятый порт на сервере, и если их станет 65к, то сервер заглохнет. нет? и как этого избежать? потому что, они же заняты, вот они!

Ну тогда это тебе надо было кому-то еще отвечать, потому что у меня был только один вопрос: «при чем тут это?».

например, переполнение conntrack-таблицы

-j CT --notrack

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

Highload это значит масштабирование. Пусть у тебя один сервер обслуживает хоть тысячу запросов в секунду, если всего ты обслуживаешь сто тысяч запросов в секунду.
П.С.
Load average 100 это же очень плохо, или ты просто про среднее значение загрузки процессора? Если да, то тоже плохо, запаса ровно ноль.

Хайлоад - это когда одного сервера физически не хватит для обработки запросов и необходимо горизонтальное масштабирование. Все остальное не хайлоад.

1000000 requests per second, в реальном проекте

Странный параметр, не учитывает суть запроса. А если 100 запросов по гигантскому объёму данных?

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

Сказочный долбоеб.

а TIME_WAIT'ы, которые далее приведены, как называть? их сервер может спокойно дропать? разве это не тот самый отдельный порт? что если 65к юзеров будут передавать данные, тобишь, займут все доступные порты.

нет, я остаюсь при своем мнении. либо скажите, как это пофиксить.

Голову себе дропни, хайлоадер мамкин.

т.е. ты не знаешь, и/или не желаешь просвящать. ладно.

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

это когда традиционный код уже не успевает обрабатывать элементарные запросы, возникает необходимость в более «продвинутых решениях»

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

Правильным вопросом будет скорее «когда заканчивается „обычный“ проект и начинается highload?»

Тогда, когда твоя текущая инфраструктура начинает показывать первые признаки того, что она перестает справляться с нагрузкой. Если у тебя VPS на 128 МБ — для тебя это может быть 10 запросов в секунду. Для кого-то это может быть 10 тысяч запросов. Суть не в них, а в том, существует ли необходимость для масштабирования и оптимизации инфраструктуры.

Если твой сайт не справляется с нагрузкой — всё, теперь ты в клубе highload.

Load average 100 это же очень плохо, или ты просто про среднее значение загрузки процессора? Если да, то тоже плохо, запаса ровно ноль.

Почему это 0? Один старый sparc T3 умеет 128 потоков. А есть и многопроцессорные серверы.

Не подумал про экзотику. Насчет sparc T3 и 128 потоков, а там потоки случайно не как hypertheading? Просто я слышал, что в общем HT дает прирост в сумме на 10%-30% к производительности, а не в 2 раза, а именно ядер там всего 18.

Bullshit

Это маркетинговый термин, каждый по-своему понимает, но «я занимаюсь хайлоад-проектом» звучит круто. По сути обозначает ситуацию, когда при большом количестве запросов приходится что-то крутить на уровне архитектуры приложения, потому что обычное горизонтальное масштабирование плохо справляется. Кстати, количеством rps и la это никак не измеряется.

Подписываюсь под каждым словом.

Не подумал про экзотику.

Сейчас и amd64 процессоры по 30 потоков умеют (E7-8890V2). В широком ходу 2-хсокетные серверы на xeon e5 v3. 32 потока.

Насчет sparc T3 и 128 потоков, а там потоки случайно не как hypertheading? Просто я слышал, что в общем HT дает прирост в сумме на 10%-30% к производительности, а не в 2 раза, а именно ядер там всего 18.

Сильно зависит от задачи. Увеличение числа ядер тоже далеко не всегда дает выигрыш. Если все потоки в проце будешь использовать на всю катушку непрерывно около <=80% времени, то смысл в HT есть. Ядер в T3 16, и сравнение с интелом не корректно. Учти, что интеловский HT и TurboBoost в некоторых задачах лучше отключить.

Про TurboBoost это я знаю да, как он частоту перекидывает. Просто я имею в виду что 30 потоков с HT это примерно как 20 без HT, и лучше считать исходя из этого. В таком случае возможно load average 100 для сервера с 128 потоками всего на 18 ядрах это слишком много.

Это сокет, мань.

Тебе бесполезно что-то писать как про 16 (а не 18 ядер) в T3, так про потоки и некорректное сравнивание спарка с интел.

Просто я имею в виду что 30 потоков с HT это примерно как 20 без HT

Реально может быть на интеле 30 c HT как 12 без HT при 15-ядерном процессоре.

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

конечно если у нас финансы или какойнить макаронный треш - то только «продвинутые решения»

Может быть, но почитай мой исходный пост, я там спрашивал, что потоки случайно не hyperthreading про спарки, так как в них не разбираюсь. И поэтому сказал, что LA для HT нельзя считать отталкиваясь от числа потоков, а нужно фактически считать от количества ядер.

это и есть т.н. хайлоад :)

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

RTFM в общем...