когда я говорю о хайлоаде, то подразумеваю набор железа, софта и всего этого в совокупности настроенного так, чтобы оно смогло выдержать нагрузку, пока не будет исчерпана пропускная способность сетевого канала.
вот у меня входящая скорость скорость интернета 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 запросов в секунду. я ламер криворукий. вот.
Это маркетинговый термин, каждый по-своему понимает, но «я занимаюсь хайлоад-проектом» звучит круто. По сути обозначает ситуацию, когда при большом количестве запросов приходится что-то крутить на уровне архитектуры приложения, потому что обычное горизонтальное масштабирование плохо справляется. Кстати, количеством 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-запись, куда вписать хост второй машины, осблуживающей тот-же самый сервер, и таким образом оно расширяется?
опять повторюсь, поэтому я сторож, что ничего не знаю. извините.
абсолютно каждому TCP/IP соединению присваивается порт, то что сервер прослушивает 80 порт, не значит, что он использует только его. на самом деле, порт задействуется на каждое подключение клиента к серверу, тобишь, подключаться 65к человек к серверу и все. приехали. сервер встанет.
Клиенту же не обязательно держать открытым соединение - соединился с сервером и бросил подключение - сервер ждет пока клиент у него данные запросит (или примет) пока по тайм-ауту соединение не отвалится, а клиент в это время фигачит еще тысячами такие соединения.
Интересные две строки. Как они относятся к моему вопросу? Занимает каждое tcp-соединение на стороне сервера целый отдельный порт? Если да, то где про это почитать?
Если запросов будет много на сервере можем получить, например, переполнение conntrack-таблицы, и все соединения сверх будут отваливаться. Ну и man C10K.
А, ну ссори, только тебе нужно было Спуффингу отвечать, потому что в моем сообщении, на которое ты ответил, я говорил как раз об этом, мне показалось что есть вопросы и стоит проиллюстрировать.
тащем-та, я о том и говорил, что это есть тот самый занятый порт на сервере, и если их станет 65к, то сервер заглохнет. нет? и как этого избежать? потому что, они же заняты, вот они!
Highload это значит масштабирование. Пусть у тебя один сервер обслуживает хоть тысячу запросов в секунду, если всего ты обслуживаешь сто тысяч запросов в секунду. П.С. Load average 100 это же очень плохо, или ты просто про среднее значение загрузки процессора? Если да, то тоже плохо, запаса ровно ноль.
хайлоад Spoofing то что сервер прослушивает 80 порт, не значит, что он использует только его. на самом деле, порт задействуется на каждое подключение клиента к серверу, тобишь, подключаться 65к человек к серверу и все. приехали. сервер встанет.
а TIME_WAIT'ы, которые далее приведены, как называть? их сервер может спокойно дропать? разве это не тот самый отдельный порт? что если 65к юзеров будут передавать данные, тобишь, займут все доступные порты.
нет, я остаюсь при своем мнении. либо скажите, как это пофиксить.
можно придумать миллиард разных ситуаций и прочего, я говорю о том что возникает в голове когда нужно объяснить в одной фразе, будем считать что запросы не тяжелые, но с данными работают
Правильным вопросом будет скорее «когда заканчивается „обычный“ проект и начинается highload?»
Тогда, когда твоя текущая инфраструктура начинает показывать первые признаки того, что она перестает справляться с нагрузкой. Если у тебя VPS на 128 МБ — для тебя это может быть 10 запросов в секунду. Для кого-то это может быть 10 тысяч запросов. Суть не в них, а в том, существует ли необходимость для масштабирования и оптимизации инфраструктуры.
Если твой сайт не справляется с нагрузкой — всё, теперь ты в клубе highload.
Не подумал про экзотику. Насчет sparc T3 и 128 потоков, а там потоки случайно не как hypertheading? Просто я слышал, что в общем HT дает прирост в сумме на 10%-30% к производительности, а не в 2 раза, а именно ядер там всего 18.
Это маркетинговый термин, каждый по-своему понимает, но «я занимаюсь хайлоад-проектом» звучит круто. По сути обозначает ситуацию, когда при большом количестве запросов приходится что-то крутить на уровне архитектуры приложения, потому что обычное горизонтальное масштабирование плохо справляется. Кстати, количеством 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 ядрах это слишком много.
ну дык если взять вырубить транзакции (или имитировать неблокирующую запись), прикрутить кеш, то как правило среднестатистической говновебприложение снова «успевает» и так можно допиливать долго
конечно если у нас финансы или какойнить макаронный треш - то только «продвинутые решения»
Может быть, но почитай мой исходный пост, я там спрашивал, что потоки случайно не hyperthreading про спарки, так как в них не разбираюсь. И поэтому сказал, что LA для HT нельзя считать отталкиваясь от числа потоков, а нужно фактически считать от количества ядер.
но когда уже и это, не помогает - начинается ультра- или экстра- хайлоад. В ход идут «тяжелые вооружения» - начинается вдумчивое чтение документации, изучение исходников...