Здравствуйте, Sharov, Вы писали:

S> Я правильно понимаю, что когда я вбиваю www.test.com, мой запрос попадает сначала прокси? Т.е. www.test.com:80 это реально адрес прокси, который получает от меня запрос,

Да, конкретно www.test.com:80 твой запрос сегодня примет nginx/1.16.1

S> устанавливает со мной соединение, а уже от себя обращается к реальному серверу, например 192.168.1.123, который html и отдает.

Да.

S> Если я новостной сайт, о каком прогреве идет речь? Загнал все сегодняшние статьи в кэш и все. Что нужно сутки кэшировать? Что за данные, какая предметная область?

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

Здравствуйте, Anton Batenev, Вы писали:


S>> Если я новостной сайт, о каком прогреве идет речь? Загнал все сегодняшние статьи в кэш и все. Что нужно сутки кэшировать? Что за данные, какая предметная область?
AB>Новости читают не только за сегодня, но и за вчера и недельной давности. Например, 11 сентября 2020 года может быть повышенный спрос на новости 2001 года.

Так что там сутки прогревать, можно и за месяц, они(заметки) небольшие + ssd? Что за данные, для которых нужны сутки? Это уже какие-то гигантские порталы, все обо всем...

Здравствуйте, Sharov, Вы писали:

S> Так что там сутки прогревать, можно и за месяц, они(заметки) небольшие + ssd? Что за данные, для которых нужны сутки? Это уже какие-то гигантские порталы, все обо всем...

Сами тексты новостей действительно небольшие, но в кэшах лежат обычно не они, а готовые куски верстки, отресайзеные оптимизированные изображения и т.д. Чтобы система не стоила космических денег под каждую задачу выбирается главный ресурс и жертвуется остальными. Например, медиа файлы обычно хранят на больших но медленных хранилищах. Медиа-прокси же должны иметь хорошую сеть, но один такой прокси-сервер не в состоянии закэшировать весь медиа-танк и холодный старт приводит к тому, что кэш будет прогреваться (до полного заполнения выделенного ресурса RAM/HDD) длительное время на "длинном хвосте" менее частых (но более разнообразных) запросов.

При чем не обязательно должен быть гигантский портал. Типичная контент-помойка типа пикабу или яплакал легко за месяц нагенерирует сотню-другую GB данных.

Здравствуйте, Sharov, Вы писали:
S>Я правильно понимаю, что когда я вбиваю www.test.com, мой запрос попадает сначала прокси? Т.е. www.test.com:80 это реально адрес прокси, который получает от меня запрос,
S>устанавливает со мной соединение, а уже от себя обращается к реальному серверу, например 192.168.1.123, который html и отдает.
Ну, для начала надо посмотреть в настройки браузера. В них может быть прописан статический прокси или скрипт для динамического выбора прокси.
Например, 192.0.0.1:8080.
Клиент идёт по этому адресу и указывает Host: www.test.com.
Далее, вот уже этот прокси, как правило, идёт по "официальному" пути — резолвит www.test.com через DNS, и получает IP адрес.
Уже в этот момент всё может стать интересно, т.к. DNS может мапиться на геораспределённые сервера CDN, т.е. пользователь из РФ получит другой IP адрес, чем пользователь из США.

Теперь мы подключаемся к найденному IP адресу по порту 80, и опять отдаём ему хидер Host: www.test.com.
По этому адресу запросто может стоять nginx, который смотрит на Host и URL запроса, и принимает решение:
— отдать статику из локального файла (а делает он это очень хорошо)
— отдать данные из кэша
— связаться с апстрим-сервером, например backend.hosting.local, который может вообще не торчать наружу в интернет.
S>>Ещё более хороший прокси умеет самостоятельно отдавать статику без какого-либо "прогрева кэша", что позволяет получить хорошую скорость сразу после старта, а не через сутки работы.
S>Если я новостной сайт, о каком прогреве идет речь? Загнал все сегодняшние статьи в кэш и все. Что нужно сутки кэшировать? Что за данные, какая предметная область?

Как вы себе представляете процесс "загона сегодняшних статей в кэш"?
Обычный, прямолинейный прокси стартует с пустым кэшем. Вот пришёл входящий запрос — поехали в апстрим (а это дорого и долго!), получили ответ, сохранили в кэш, отдали клиенту.
Получили другой запрос, получили ответ, сохранили в кэш, отдали клиенту.
С точки зрения основного сервера, пустой прокси неотличим от обычного клиента — он всё видит в первый раз.
Статика — это такие ресурсы, у которых стоит Expiration:Never. Единожды попав в кэш прокси, они остаются там навсегда (ну, более-менее навсегда, до вытеснения).
Поэтому более эффективный способ — заранее скопировать их на прокси сервер, т.к. Bulk copy через низкоуровневые протоколы файлового трансфера эффективнее, чем тянуть их же по кусочкам через http.
Но для такого прокси сервер должен понимать, что /styles/main.css должен мапиться в папку на локальном диске; а /content/today.html нужно тащить с апстрима.
То есть появляется описание конфигурации прокси, правила роутинга, вопросы перезапуска при смене правил, и т.п.

Здравствуйте, Sharov, Вы писали:


S>1)А можно базовый и дурацкий вопрос с тз. работы сокетов во всем этом? Вот у нас сервер регистрирует(bind) сокет на 80 порту, вот у нас куча запросов
S>в этот сокет и мы либо создаем отдельный поток для обслуживания, либо что-то неблокирующее(не суть). Т.е. куча запросов на один сокет\порт,
S>а как они будут отдаваться? Все через этот единственный сокет или для каждого запроса будет свой отдельный сокет(но тогда ответ клиенту придет не с 80 порта)?

S>2)Еще вопрос, отчасти связанный с 1. Вот у меня rp, вот у меня 80 порт и пара серверов(бд\веб) в бэке, т.е. всего получается мне нужно не более 3-х сокетов?

Сокет идентифицируется адресом-портом клиента и адресом-портом сервера. При accept'е создается новый сокет, удаленная пара адрес-порт и локальная пара адрес-порт. Локальный порт будет 80ый. Для каждого клиента (соединения), таким образом, исходящий серверный порт будет таки 80ым, но сокеты будут разные.

А как обслуживать сокеты — по потоку на сокет, или на всех (на пул) асинхронных сокетов по потоку — это дело хозяйское

Здравствуйте, Sharov, Вы писали:

T>>>Конкретно про nginx можно почитать интервью с его автором https://xakep.ru/2012/01/09/58122/
M>>Прошло 7 лет.
M>>Интересно, как их коммерческие дела? На чем зарабатывают?

S>За 600$ млн. продали nginx.

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

Здравствуйте, Marty, Вы писали:

M>Сокет идентифицируется адресом-портом клиента и адресом-портом сервера. При accept'е создается новый сокет, удаленная пара адрес-порт и локальная пара адрес-порт. Локальный порт будет 80ый. Для каждого клиента (соединения), таким образом, исходящий серверный порт будет таки 80ым, но сокеты будут разные.
M>А как обслуживать сокеты — по потоку на сокет, или на всех (на пул) асинхронных сокетов по потоку — это дело хозяйское

Вдогонку вопрос: а как сокет льет данные в карту? Вот у меня ~60000 сокетов, которые отличаются только ip\port клиента. Под каждый сокет у меня есть буфер в памяти, так? Каждый буфер как-то отображается в память карты (DMA?), какая там механика после send?

Здравствуйте, Marty, Вы писали:

S>>За 600$ млн. продали nginx.
M>Это не ответ. До этого же зарабатывали как-то, и покупатель, видимо, хочет тоже зарабатывать. Вряд ли чисто для себя приобрёл

Своя компания была, зарабатывали консалтингом, вестимо.

Здравствуйте, Sharov, Вы писали:

S>Вдогонку вопрос: а как сокет льет данные в карту? Вот у меня ~60000 сокетов, которые отличаются только ip\port клиента. Под каждый сокет у меня есть буфер в памяти, так? Каждый буфер как-то отображается в память карты (DMA?), какая там механика после send?

Как хочет, так и льет. Твои юзер-спейс буфера сокету пофигу, хоть один буф используй. Как только ты сделал send, то там уже твоими данными занимается реализация стека TCP/IP, а как она уже в сетевуху льет, это вообще третий вопрос

Здравствуйте, Marty, Вы писали:

M>Как хочет, так и льет. Твои юзер-спейс буфера сокету пофигу, хоть один буф используй. Как только ты сделал send, то там уже твоими данными занимается реализация стека TCP/IP, а как она уже в сетевуху льет, это вообще третий вопрос

Воот, самое интересное. И как стек льет, какие механизмы?

Здравствуйте, Sharov, Вы писали:

M>>Как хочет, так и льет. Твои юзер-спейс буфера сокету пофигу, хоть один буф используй. Как только ты сделал send, то там уже твоими данными занимается реализация стека TCP/IP, а как она уже в сетевуху льет, это вообще третий вопрос

S>Воот, самое интересное. И как стек льет, какие механизмы?

Виндовые сорцы закрыты, линуксовые открыты, изучай