Но если работник появляетесь в офисе не в России, то это однозначно указывает на то что он не в России и поэтому компания довольно просто может решить проблему с требованием физической локации сотрудника для конкретного проекта
Есть требование чтобы разрвботчик был в России. На 100% можно это гарантировать только через физическую фиксацию в офисе. Вот они и решили эту проблему таким вот образом, а то что есть офисы за рубежём это дело десятое. Главное внедрить дественный способ одинаковый для всех, потом можно гайки подкрутить или ресурсы перераспределить. То что некоторых специалистоа они потеряют то это не беда - за забором очередь (1 апреля у них ярмарка вакансий)
Написав «ещё одна» вы подразумеваете еще кого-то кроме указанной в посте компании? Когда дело касается действительно высоких нагрузок (даже гигантских) готовое универсальное решение будет проигрывать самописному (при условии что пишут профессионалы со знанием предметной области).
Это здорово что подобные «велосипеды» изобретаются «еще одной» крупной компанией.
Скажу по другому.
Как 3млн. ВНЕШНИХ подключений удерживаются Nginx?
То как они взаимодействуют с внутренними процессами, отдельный разговор (и тут у меня нет вопросов, т.к. решений множество, на что автор и указал в своем сообщении).
Помню на какой то конференции товарищи презентовали железку которая могла держать более 1млн. одновременных подключений и там была реализована черная магия, а на выходе (к обработчику подключений) множество небольших запросов с ключом сессии.
Например в Windows это можно сделать через NLB который действует на третьем уровне сетевого протокола (по сути работает на уровне драйвера, до выделения порта) и перераспределяет запросы на множество сетевых адаптеров (возможно и виртуальные), но это решение довольно не оптимально в плане производительности (наверняка есть супер железки которые выполняют подобные действия и одну из них как раз использовали для своего решения в mail.ru)
Как вам уже ответили, это работа с ожиданиями I/O операций.
Закрытие подключений, повторное использование socket, правильная работа с обработкой вновь поступающих подключений.
Оптимизированная работа с приемом и обработкой трафика (это не так просто как звучит, т.к. из удаленных источников данные могут приходить в довольно неожиданных порциях). На допущениях того что трафик в приложении идет через локальное подключение можно довольно сильно оптимизировать свой сервер обработчик.
«Fraud» трафик в конце концов.
Думаю что не целесообразно тратить кучу времени на реализацию полноценного web сервера когда есть уже готовые и проверенные временем решения (iis/http.sys под windows и nginx для остальных)
rule задал правильный вопрос на счет ограничения в количестве одновременных подключений к серверу по tcp/ip.
В статье я не заметил ни слова о том как преодолено ограничение в количестве локальных портов.
Как Nginx может держать открытыми 3 млн внешних подключений?
Ведь все они приходят с одного внешнего порта (ip адреса) для которого драйвер tpc/ip будет использовать всего 65535 портов (к тому же часть из которых зарезервированы), которые даже после закрытия соединения еще какое то время удерживаются в ожидании повторных подключений с удаленного адреса.
Вполне все логично и обяснимо.
Захват происходит по ссылке. Очевидно что такая переменная выделятся уже не из стека (что характерно для структур), а из кучи и хранится там пока есть хотябы одна ссылка на эту переменную (в данном случае ссылка храниться в делегатах).
Вообще нужно аккуратнее со всякими ref и замыканиями работать
Парни из гугла подошли к решению проблем хранения множества паролей с другой стороны. По сути данный метод был с нами очень давно — запоминания паролей в браузере с сохранением данной информации в облаке. Это было не удобно. Теперь они делают тоже самое но убрав промежуточные звенья.
Правда я бы не доверил гуглу ниодного своего запароленного ресурса, но это мое личное дело.
Это естественно т.к. этот шрифт создавали и оптимизировали исключительно для латиницы, остальные символы там для «чтобы было». Если заморачиваться еще и на кириллицу, то скорее всего придется разрабатывать еще один шрифтправда в нем латиница будет выглядеть не очень
Вся разница в обязательствах. Раньше я покупал текущую версию и обновления на год вперед, то сейчас просто текущую версию плюс обязательство что если меня все устраивает, то я куплю лицензию и в следующем году иначе меня накажут запретив пользоваться текущей версией.
Но если работник появляетесь в офисе не в России, то это однозначно указывает на то что он не в России и поэтому компания довольно просто может решить проблему с требованием физической локации сотрудника для конкретного проекта
Есть требование чтобы разрвботчик был в России. На 100% можно это гарантировать только через физическую фиксацию в офисе. Вот они и решили эту проблему таким вот образом, а то что есть офисы за рубежём это дело десятое. Главное внедрить дественный способ одинаковый для всех, потом можно гайки подкрутить или ресурсы перераспределить. То что некоторых специалистоа они потеряют то это не беда - за забором очередь (1 апреля у них ярмарка вакансий)
Это здорово что подобные «велосипеды» изобретаются «еще одной» крупной компанией.
Как 3млн. ВНЕШНИХ подключений удерживаются Nginx?
То как они взаимодействуют с внутренними процессами, отдельный разговор (и тут у меня нет вопросов, т.к. решений множество, на что автор и указал в своем сообщении).
Помню на какой то конференции товарищи презентовали железку которая могла держать более 1млн. одновременных подключений и там была реализована черная магия, а на выходе (к обработчику подключений) множество небольших запросов с ключом сессии.
Например в Windows это можно сделать через NLB который действует на третьем уровне сетевого протокола (по сути работает на уровне драйвера, до выделения порта) и перераспределяет запросы на множество сетевых адаптеров (возможно и виртуальные), но это решение довольно не оптимально в плане производительности (наверняка есть супер железки которые выполняют подобные действия и одну из них как раз использовали для своего решения в mail.ru)
Закрытие подключений, повторное использование socket, правильная работа с обработкой вновь поступающих подключений.
Оптимизированная работа с приемом и обработкой трафика (это не так просто как звучит, т.к. из удаленных источников данные могут приходить в довольно неожиданных порциях). На допущениях того что трафик в приложении идет через локальное подключение можно довольно сильно оптимизировать свой сервер обработчик.
«Fraud» трафик в конце концов.
Думаю что не целесообразно тратить кучу времени на реализацию полноценного web сервера когда есть уже готовые и проверенные временем решения (iis/http.sys под windows и nginx для остальных)
В статье я не заметил ни слова о том как преодолено ограничение в количестве локальных портов.
Как Nginx может держать открытыми 3 млн внешних подключений?
Ведь все они приходят с одного внешнего порта (ip адреса) для которого драйвер tpc/ip будет использовать всего 65535 портов (к тому же часть из которых зарезервированы), которые даже после закрытия соединения еще какое то время удерживаются в ожидании повторных подключений с удаленного адреса.
Захват происходит по ссылке. Очевидно что такая переменная выделятся уже не из стека (что характерно для структур), а из кучи и хранится там пока есть хотябы одна ссылка на эту переменную (в данном случае ссылка храниться в делегатах).
Вообще нужно аккуратнее со всякими ref и замыканиями работать
Не зная деталей делать подобные выводы глупо.
Правда я бы не доверил гуглу ниодного своего запароленного ресурса, но это мое личное дело.