The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Cloudflare перешёл с NGINX на прокcи Pingora, написанный на языке Rust, opennews (??), 16-Сен-22, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


155. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +5 +/–
Сообщение от Ivan_83 (ok), 16-Сен-22, 15:40 
Новость не про раст а про то что клоуды сменили архитектуру приложения на более подоходящую им.


Кто не осилил прочитать оригинал:

1. их не устраивало что у nginx много процессная архитектура, где в каждом процессе по одному евент пулу.
Это приводило к сложности балансировки нагрузки на проц и низкому переиспользованию конектов к конечным серверам.

2. луа тормозила, а они именно там писали логику какую то свою.
А луа они юзали потому что боялись накосячить програмируя на С.
Это такая шиза у смузихлёбов:
- они юзают приложение на С, оно их устраивает
- они слышали что С страшно опасный и потому сами боятся на нём писать
- они заявляют что они компетентны и ваще супер-пупер, море им по колено


По большому счёту тут произошло то что происходит всегда у больших корпораций: потребности выросли и стали слишком специфическими, а дальше они сели писать себе свой велосипед.

Что касается раста и архитектуры.
Я понимаю почему nginx такой какой есть, это был компромис между функционалом/сложностью.
Написать многопоточное приложение у которого будет и пул потоков и один kqueue()/epoll() на весь процесс и все потоки в нём - сложно.
Ещё сложнее сделать чтобы там настройки применялись на лету без полного рестарта.

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

Ответить | Правка | Наверх | Cообщить модератору

169. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Ivan_83 (ok), 16-Сен-22, 16:06 
И попутно.
Всякие libev, libevent и прочее что я видел это были решения как раз для построения модели:
1 поток - один kqueue()/epoll()/poll().
А дальше крутись как хочешь.

Это системная проблема индустрии, которую С програмисты в опенсорце не решили.
Или я плохо искал.
Отчасти это потому что epoll()/poll() разделяют события записи/чтения на дескрипторе, и один сокет может тригернуть сразу два разных потока, и их нужно между собой синхронизировать. (а может и больше двух, там ещё ошибки тригерят пробуждение потоков).
kquque() может тригерить а может не тригерить несколько потоков, зависит от флагов указанных при добавлении дескриптора.

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

Вот о чём речь, когда доходит до построения рабочего решения: куча потоков на одном kqueue()/epoll()/poll().

Ответить | Правка | Наверх | Cообщить модератору

180. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +1 +/–
Сообщение от Аноним (-), 16-Сен-22, 16:35 
> В целом конечно же раздельное тригирение потоков на запись/чтение оно должно было увеличить производительноть, типа в сокет можно и писать и читать сразу, но на практике там же в ядре тоже какие то блокировки для этого есть, и к этому нужны блокировки в приложении, чтобы один поток не грохнул данные связанные с сокетом пока второй с ними работает.

Специализация раста как раз в том, чтобы такие вещи отслеживать статически, и ругаться на тебя, когда у тебя не получилось. Чтобы ты помыкавшись с борроу-чекером и так и эдак, понял бы наконец что ты плохо продумал менеджмент ресурсов, и туд бэ надо воткнуть костылей Arc/Mutex/RefCell/... потому что без них статически управлять не выходит никак. Или даже выкинул бы всё, и начал заново со структур данных, которые позволяют статически следить за памятью.

В C это практически невозможно. Теоретически да, но практически тебе senior'ы руки оторвут и в ж засунут, и выставят за дверь без выходного пособия, если ты попытаешься что-то такое сотворить. Потому что хрен ты такой код отладишь, и никто не хочет возиться с ним после того, как тебя уволят. Лучше сразу выкинуть такой код вместе с автором.

Ответить | Правка | Наверх | Cообщить модератору

227. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +1 +/–
Сообщение от Ivan_83 (ok), 16-Сен-22, 21:45 
Сплошная пропаганда раста в ваших словах.

Написать на С такой код возможно, не писали его до сих пор потому что хватало и более простой модели.
Те экономилась куча усилий ценой небольших потерь в редких случаях.
И в общем то были и есть костыли как перераспределять нагрузку между такими потоками-эвентлупами.

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

У меня в msd  потоки активно обменивались и сообщениями и работой, потому что всё было в рамках одного процесса.

Те тут претензия большей частью к тому что у нгинха по процессам разнесено.

Ответить | Правка | Наверх | Cообщить модератору

231. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +1 +/–
Сообщение от Аноним (-), 16-Сен-22, 22:46 
> Написать на С такой код возможно,

Это ты на личном опыте? Я ссылался в том числе и на личный опыт: если ты попробуешь какие-то неочевидные сразу правила владения объектами внедрить в C, тебя уволят. Потому что документировать такие вещи крайне сложно, ещё сложнее держать документацию актуальной, и практически невозможно уследить за каждым программистом, чтобы тот следовал бы этим правилам. Как следствие никто не будет полагаться на то, что это будет работать.

Ответить | Правка | Наверх | Cообщить модератору

246. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Ivan_83 (ok), 17-Сен-22, 02:14 
Я говорю про код.
Не знаю что подразумевается под "неочевидные правила владения".
Делается либа/фрейворк подобный тому что в nginx и работа с сокетами и прочее делаются через неё, оно же дёргает калбэки при пооступлении событий.
Ответить | Правка | Наверх | Cообщить модератору

327. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Прохожий (??), 17-Сен-22, 17:21 
> Написать на С такой код возможно, не писали его до сих пор потому что хватало и более простой модели.

И почему же никто до сих пор не написал?

Но ок, соглашусь, что на Си реально было бы написать этот код. Только стОил бы такой код ГОРАЗДО дороже, чем на Rust. Почему? Да потому что в Си пришлось бы днями и ночами дыры вылавливать там, где Rust их существование делает абсолютно невозможным. В такой конторе, как Cloudflare, подобные дыры приводили бы к ОГРОМНЫМ убыткам.

Ответить | Правка | К родителю #227 | Наверх | Cообщить модератору

336. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Ivan_83 (ok), 18-Сен-22, 02:33 
Вам тоже пора таблетки принимать.

У них этого кода на С просто тоннами, начиная с линуха и заканчивая тем же самым nginx.

И на чём там раст написан?

Ответить | Правка | Наверх | Cообщить модератору

337. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +1 +/–
Сообщение от Аноним (337), 18-Сен-22, 03:05 
Ты казался мне как минимум на одно среднеквадратичное отклонение адекватнее среднего опеннетовца. Но этот тред и особенно этот коммент показали мне, что я ошибался. Может перепутал с кем?

Испытываю досаду. Столько бисера насыпал, и всё для заурядного мамкиного тролля.

Ответить | Правка | Наверх | Cообщить модератору

356. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Прохожий (??), 18-Сен-22, 13:08 
Никому неизвестный не отягощённый интеллектом аноним, которому по делу сказать абсолютно нечего, испытал досаду. Вот горе-то!
Ответить | Правка | Наверх | Cообщить модератору

360. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Ivan_83 (ok), 18-Сен-22, 14:55 
Откуда берётся компелятор раста?


https://www.rust-lang.org/tools/install
> curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

Это же мать его антипаттерн безопасного использования курла.
Осталось только дождатся когда на sh.rustup.rs положат что то более интересное и потом растовики будут объяснять своим босам почему у них вся инфраструктура полегла под шифровальщиками, майнерами или все данные упёрли.

Самая шиза что при таком способе установки у смузихлёбов там 1/6 скрипта занимает дрючиво с выбором бизапасного набора крипты для курла/вгета.


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

Ответить | Правка | К родителю #337 | Наверх | Cообщить модератору

382. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Аноним (-), 19-Сен-22, 22:00 
> Откуда берётся компелятор раста?

Оттуда же откуда и gcc:

emerge dev-lang/rust

Ответить | Правка | Наверх | Cообщить модератору

344. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от freecoder (ok), 18-Сен-22, 07:48 
А на чем раст написан? Расскажи, пожалуйста.
Ответить | Правка | К родителю #336 | Наверх | Cообщить модератору

359. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Ivan_83 (ok), 18-Сен-22, 14:43 
Лучше расскажите мне как вы на новом железе забутстрапитесь, особенно если кроскомпилировать нечем.
Накорябаете раст на асме?

Или собирать раст при помощи и с кусками llvm это ок, но С/С++ не ок?

Ответить | Правка | Наверх | Cообщить модератору

355. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Прохожий (??), 18-Сен-22, 13:04 
Раст написан на Расте. Это во-первых. Во-вторых, мгновенно весь софт, который уже написан на Си (Плюсах), не перепишешь. Но! Если есть возможность переписать, то лучше это сделать, чем бесконечно рыться в поисках багов. Неужели такие простые вещи надо так долго разжёвывать?
Ответить | Правка | К родителю #336 | Наверх | Cообщить модератору

357. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Ivan_83 (ok), 18-Сен-22, 14:30 
О да.
Покажите бутстрапный компилятор раста на асме :)

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

Ответить | Правка | Наверх | Cообщить модератору

375. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Аноним (375), 19-Сен-22, 12:56 
>Современными средствами баги ищутся легко и просто

А софт как был багованным, так и остался.

Ответить | Правка | Наверх | Cообщить модератору

235. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +1 +/–
Сообщение от Аноним (235), 16-Сен-22, 23:09 
> В C этот практически невозможно. Теоретически да, но практически

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

Ответить | Правка | К родителю #180 | Наверх | Cообщить модератору

237. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  –1 +/–
Сообщение от Аноним (-), 16-Сен-22, 23:12 
> На С целые операционные системы пишут, включая реалтаймовые,

Ты внутрь заглядывал? Они делают не то, о чём я пишу. То о чём я пишу тщательно все избегают, потому что хрен кто справится с этим.

Ответить | Правка | Наверх | Cообщить модератору

248. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Ivan_83 (ok), 17-Сен-22, 02:30 
То что вы описываете - мало кому нужно, потому и не делают.
Ответить | Правка | Наверх | Cообщить модератору

254. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Аноним (-), 17-Сен-22, 05:14 
Зелен виноград.
Ответить | Правка | Наверх | Cообщить модератору

172. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Аноним (172), 16-Сен-22, 16:22 
> Взять раст - дань моде и это один из подходящих для этого фреймооврков, который изображает из себя отдельный язык.
> Точно так же можно было взять какойнить эрланг.

Раст потому что 90%-99% кода написано за тебя. Берёшь async-runtime который реализует ту модель асинхронности, которая тебе больше нравится, например с одним пулом потоком и одним kqueue/epoll на весь процесс и все потоки, пишешь на этом http сервер, полагаясь на готовый парсер-http, который тебе все эти "Accept-Encoding" переведёт в enum'ы, и будет кидать ошибки если кривой http попадётся. Хелловорд-сервер можно написать за день. Потом несколько месяцев на покрытие тестами/бенчмарками, допиливание необходимой функциональности/оптимизацию.

Эрланг же слишком много берёт на себя. async-runtime тебе навязывается языком, выбрать другой или написать свой у тебя не выйдет. Да и тормозной он в сравнении с растом.

> По большому счёту тут произошло то что происходит всегда у больших корпораций: потребности выросли и стали слишком специфическими, а дальше они сели писать себе свой велосипед.

Нет, что произошло -- системное программирование стало настолько простым, что чем допиливать чужие велосипеды под себя, можно собрать свой из готовых частей. Нет необходимости, например, создавать платформу сервера со встроенным lua, чтобы расширить возможности конфигурации. Зачем нужна эта рантайм-конфигурация, если можно сконфигурировать под задачу статически?

Если ты приглядишься, ты увидишь то же самое везде.

WASM вместо jvm: ты можешь хоть на коленке написать виртуальную машину wasm под себя, или взять готовую. В виде интерпретатора байткода, или на jit-компиляторе. И вся обвязка в виде нативных API которые ты раскрываешь, тоже под твоим контролем.

RISC-V вместо армов с интелями: хоть на коленке разработай свой чип с тем что тебе нужно и без того, что не нужно.

Мы идём к светлому будущему, в котором full-stack будет начинаться с verilog, простираться через написание собственной ОС под собственный чип, и заканчиваться конкретным юзерспейс софтом. Это не значит, что все эти компоненты до последней строки будут написаны в компании, понятно она будет тягать код с github'а, сотнями тысяч строк. Но возможности по компоновке этого кода в единый продукт такие, что раньше и не снилось.

Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

228. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +1 +/–
Сообщение от Ivan_83 (ok), 16-Сен-22, 21:53 
Сказки смузихлёбов: думать нинада, только смузи и сыры, раст сам всё сделает.

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


> Нет, что произошло -- системное программирование стало настолько простым

Потому что период активного изменения АПИ закончен как в линухе так и в бсд, и есть куча актуальной документации и либ, накопленные за 20 лет.


> Мы идём к светлому будущему, в котором full-stack будет начинаться с verilog, простираться через написание собственной ОС под собственный чип, и заканчиваться конкретным юзерспейс софтом.

Нет, не идёте, вы грезите :)

Ответить | Правка | Наверх | Cообщить модератору

236. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Аноним (236), 16-Сен-22, 23:10 
> В С ты тоже берёшь нужную тебе либу с нужной моделью асинхронности, либу которая будет тебе парсить что захочешь и вот у тебя сервер.

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

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

Открой для себя cargo tree. Там все библиотеки расписаны. Да, если ты пишешь http сервер их там будет пара сотен на старте. Но видишь ли, прочитать список пакетов из двух сотен и поинтересоваться зачем каждый из них нужен -- это развлечений ну на день отсилы. На самом деле меньше, потому что про половину или даже большую часть ты и так знаешь. А когда ты интеллектуально капитулируешь, говоря "вообще ничего не понятно", ты обрекаешь себя на написание всей функциональности этих крейтов. Развлечений на пару-тройку лет. Это если на расте писать, на C ты это будешь писать и отлаживать лет десять.

Этот список пакетов столь же "непонятен" как и 200 .c сорцов из какого-нибудь монолита на C. Он вызывает те же самые чувства при первом взгляде. Совершенно нормально не понимать, как устроена и работает большая и сложная система. Даже прям скажем ненормально понимать с первого взгляда как она работает. Это одолевается тем же путём: вешаешь на стену лист A0, берёшь маркер и начинаешь на нём рисовать "файлы", их краткое описание (которое ты сочиняешь, читая сорцы), кросс-депендансы, и тп. Через неделю ты уже неплохо ориентируешься в коде, и готов приступать к конкретной задаче, ради которой ты затеял изучение этого кода.

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

> Потому что период активного изменения АПИ закончен как в линухе так и в бсд, и есть куча актуальной документации и либ, накопленные за 20 лет.

Да-да. Мир такой, какой он есть, и он никогда не изменится. Ты знаешь сколько поколений до тебя верили в эту сказку? Почему-то чем дольше что-то продолжается по времени, тем сильнее люди верят в то, что оно вечно. Хотя ровно наоборот: чем дольше стоит, тем глубже прогнило, и тем ближе время, когда оно рухнет. Как только способность меняться утеряна (а она утеряна полностью через 10 лет после последних крупных изменений), так сразу начинается необратимый процесс гниения.

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

> Нет, не идёте, вы грезите :)

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

Ответить | Правка | Наверх | Cообщить модератору

247. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Ivan_83 (ok), 17-Сен-22, 02:29 
Я не большой знаток либ, я велосипедостроитель.
libev/libevent реализуют модель подобную той что в nginx.
Библиотек реализующих модель клауда я не знаю, потому что не интересовался.


> Открой для себя cargo tree. Там все библиотеки расписаны.

Очередной репозиторий пакетов на каждый чих.
Проблема в том, что там есть разные версии, всего этого слишком много и избыточно много зависимостей.
Я вижу как плохо всё в том же питоне с этим, и в других языках где сходные горы заивисомстей сами подтягиваются тоже жизнь лёгкой не кажется.
А если пытатся говорить за безопасность - кто вообще знает что в этих крайтах лежит?


> Да-да. Мир такой, какой он есть, и он никогда не изменится.

kqueue(), epoll() - лет 20, poll(), select() - сильно больше.
За последние лет 10 там завезли немного флагов, для kqueue() зввезли работу с какими то подсистемами.

Насколько я видел, даже возможности epoll() почти нигде не раскрыты целиком, а уж возможности kqueue() вообще используются на минималках.

И в целом там особо ничего нечего улучшать.
Можно сходить по пути МС с их портом завершения в/в, но там свои минусы есть, в нынешних реалиях, особенно линукса, оно скорее ухудьшит производительность в сравнении с тем что поверх epoll() можно нагородить.


> Естественно. Ясновидение это всегда грёзы. Но ты сам понаблюдай, и ты увидишь.

Вы обычный фонатик раста, который о системном программировании мало что знает.

Ответить | Правка | Наверх | Cообщить модератору

255. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Аноним (-), 17-Сен-22, 05:28 
> Я не большой знаток либ,

Откуда тогда наглости набрал врать про то, что под любую модель можно найти библиотеку?

> libev/libevent реализуют модель подобную той что в nginx.

Это ведь форки древнего libpth, я правильно помню? И где их используют? Хоть один продакшн реди проект на них есть?

> kqueue(), epoll() - лет 20, poll(), select() - сильно больше.

О, это ядрёные API, которые всё равно в большинстве случаев требуют оберток, чтобы их можно было бы эффективно использовать. Это как с read/write, которые для большинства применений невыносимо тормозны без юзерспейс буфера. Но, каким бы ты не был велосипедостроителем, ты же не велосипедишь каждый раз аналог stdio.h?

Плюс они часто системно-зависимы и велосипеды приходится оснащать костылями для портабельности. Кому это нужно? Только мамкиным велосипедостроителям.

> Вы обычный фонатик раста, который о системном программировании мало что знает.

Расплачься ещё, плюнь мне в лицо, и скажи вывсеврети. Это даст тебе моральное право ещё десять лет игнорировать изменения мира и жить в своём виртуальном мирке.

Ответить | Правка | Наверх | Cообщить модератору

303. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Ivan_83 (ok), 17-Сен-22, 15:04 
> Откуда тогда наглости набрал врать про то, что под любую модель можно найти библиотеку?

Наверное можно, или написать самому.


> Это ведь форки древнего libpth, я правильно помню? И где их используют? Хоть один продакшн реди проект на них есть?

libpth - впервые слышу.
libevent - фаерфокс и хромиум, turnserver, prosody, unbound
libev - ничего не нашлось из того что у меня установлено.


> О, это ядрёные API,

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


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

Зависит от задачи.
У меня для glib файловый мониторинг сделан на kqueue(), никаких обёрток особо не потребовалось.
Но в целом да, это низкоуровневое решение и сразу буизнес логику поверх kqueue()/epoll() писать нельзя, это не недостаток, просто оно так устроено.


> Это как с read/write, которые для большинства применений невыносимо тормозны без юзерспейс буфера.

Так только дебило-джун будет читать по одному байту в цикле, даже не знаю зачем вы пишите такую банальщину.


> ты же не велосипедишь каждый раз аналог stdio.h

Нет.
Я читаю/пишу либо файл целиком либо кусками хотя бы по 512кб.


> Плюс они часто системно-зависимы и велосипеды приходится оснащать костылями для портабельности. Кому это нужно? Только мамкиным велосипедостроителям.

Я пишу под фрю, и иногда проверяю что на линухе тоже работает, остальная портабельность мне не интересна.
И нет, мне не так трудно поддерживать её самому.

> Это даст тебе моральное право ещё десять лет игнорировать изменения мира и жить в своём виртуальном мирке.

Нет, я вижу ваши рассуждения и ваш опыт, он между строк читается: тяп-ляп, либу-фигак, при этом ничего что там ниже либы происходит вы не знаете и не понимаете. И если что я не виноват - раст всё проверил и сказал что ОК.

У меня же своя libev/libevent, я взял и написал обёртку над kqueue() и epoll() которая позволяет писать переносимый код между бсд и линухом, и как пример там msd, ssdpd приложения есть.
Я прошёлся по всем граблям в обеих ОС.
Это и есть системное программирование про которые растбои кричат, а не вот этот ваш раст запускать.

Прикол в том, что даже Visual Basic ещё есть вакансии, а для С програмистов ваканский куча, мне работы точно хватит до смерти :)
И да, я не продаю знание языка С, я продаю знание технологий, просто я в основном на С общаюсь с компом, и это удобно, потому что все ОС на нём написаны.
А вы фонатеете по языку, знание которого бесполезно если вам нечего на нём писать.

Ответить | Правка | Наверх | Cообщить модератору

318. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Аноним (-), 17-Сен-22, 16:42 
> Наверное можно,

"Наверное". Прежде чем утверждать что можно, убедись в этом. Потому что когда ты утверждаешь то, о чём не знаешь -- это называется враньё.

> или написать самому.

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

> libevent - фаерфокс и хромиум, turnserver, prosody, unbound

Я удивлён. C'шники они как правило велосипедисты, и готовы затянуть разработку на два лишних года, лишь бы не использовать депендансы. С другой стороны, фф с хромом это не C'шники, это C++. Эти чуть менее склонны велосипедить.

> Я читаю/пишу либо файл целиком либо кусками хотя бы по 512кб.

То есть велосипедишь буферизированный ввод вывод? Как ты парсишь http в таком варианте? Вот распарсил ты "Accept-En", и буфер кончился, дальше ты копируешь Accept-En в начало буфера, и заказываешь чтение на хвост буфера? Ну-ну. Прикинь я из std получаю функцию readline, которая все эти штуки делает самостоятельно.

> Я пишу под фрю, и иногда проверяю что на линухе тоже работает, остальная портабельность мне не интересна.

А вот большинству системных программистов интересна. Им интересно чтобы, в первую очередь, стабильно работало на linux'е, во-вторую очередь на bsd, в-третью очередь на прочих unix'ах, и для некоторых проектов ещё важна венда. И что ещё интереснее, часто неизвестно заранее, что из этого списка потребуется после.

Не надо свой специальный случай распространять на всё системное программирование.

> Нет, я вижу ваши рассуждения и ваш опыт, он между строк читается: тяп-ляп, либу-фигак, при этом ничего что там ниже либы происходит вы не знаете и не понимаете. И если что я не виноват - раст всё проверил и сказал что ОК.

1. Если я использую либы, это не значит, что я не понимаю как эти либы работают.

2. Мне нет нужды доказывать кому-то, что я понимаю как реализуются гринтреды посредством написания велосипеда гринтредов.

> Прикол в том, что даже Visual Basic ещё есть вакансии, а для С програмистов ваканский куча, мне работы точно хватит до смерти :)

Хватит. И чё ты тогда в комментах развоевался?

> И да, я не продаю знание языка С, я продаю знание технологий,

Хаха. "Знание технологий". Если ты велосипедишь без уважительной причины, то это не "знание технологий", это "знание теории". Оторванность от практики уровня профессора расеянского вуза.

Ответить | Правка | Наверх | Cообщить модератору

338. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Ivan_83 (ok), 18-Сен-22, 03:36 
Когда нечего сказать надо докопатся по пацански, да?


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

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


> То есть велосипедишь буферизированный ввод вывод? Как ты парсишь http в таком варианте? Вот распарсил ты "Accept-En", и буфер кончился, дальше ты копируешь Accept-En в начало буфера, и заказываешь чтение на хвост буфера? Ну-ну. Прикинь я из std получаю функцию readline, которая все эти штуки делает самостоятельно.

https://github.com/rozhuk-im/liblcb/blob/master/src/proto/ht...
вот так я это делаю.
В начале надо поймать crlfcrlf - маркер окончания заголовка, а уже потом парсить.
Ни std ни readline я не юзаю - нету в них смысла. Это инструменты уровня консольных утилит, чтобы по быстрому накодить приложуху которая работает меньше секунды и завершается.
А проблемы с внезаптным концом данных при парсинге - это детский сад, который у меня был в 2003 году.
Те вы мало того что пытаетесь мне сообщить о важности мытия рук перед едой, о которой сами недавно узнали, так ещё и не дошли до стадии что руки надо мыть с мылом - те парсить когда весь заголовок приедет.
Осталось дождаться когда вы сделаете важное открытие, что оказывается заголовок парсить не всегда нужно, а когда нужно, но это будет через пару лет, вы узнаете что там есть проверки валидности пришедшего согласно RFC.


> А вот большинству системных программистов интересна. Им интересно чтобы, в первую очередь, стабильно работало на linux'е, во-вторую очередь на bsd, в-третью очередь на прочих unix'ах, и для некоторых проектов ещё важна венда.

Какому большинству!?
Вашим двум однокурсникам?
Почему меня это должно волновать?
Чтобы вы знали, nginx на линухе поддерживается и пилится по такому же остаточному принципу, по крайней мере долгое время так было. И все новые фрёвые фичи даже с каррента уже юзаются в нгинхе.

> 1. Если я использую либы, это не значит, что я не понимаю как эти либы работают.
> 2. Мне нет нужды доказывать кому-то, что я понимаю как реализуются гринтреды посредством написания велосипеда гринтредов.

Ты палишься как зелёный джун в каждом посте, куда уж больше :)
Это я к тому что ты там собрался профилировать обвязку над kqueue()/epoll() - это просто дичь.
Хотя что взять с человека который обмазывается либами которые работают неведомым ему образом, ты же пихнёшь в обвязку чтото что тебе кажется простым а потом будешь с профайлером искать чего оно так тормозит. У крестовиков такое постоянно происходит: вроде написана очевидная штука а оказывается что она жестоко грузит проц ненужными действиями.

Я вот когда пользую ffmpeg, OpenCV - даже не стесняюсь признавать что я не понимаю как они работают, там тонны математики и десятки тысяч человеко/часов.


> Хаха. "Знание технологий". Если ты велосипедишь без уважительной причины, то это не "знание технологий", это "знание теории". Оторванность от практики уровня профессора расеянского вуза.

Звучит как будто вы с урока в туалет отпрашиваетесь - всё бы вам уважительные причины :)

Речь шла именно про знанение технологий с которыми работаешь.
Пока вы там со своим буферезированным std будете файл с диска по хттп отдавать перекладывая в сокет, я возьму sendfile(), и для tls приколхожу ядерную реализацию чтобы ядро само всё делало, по возможности используя аппаратный акселератор в железе.
Ну и фишка в том, что у меня msd проксирует потоки, и он тоже испольует sendfile() вместо обычного send(), тем самым экономя проц на копировании данных с юзерспейса в ядро, потому что в кольцевой буфер только один источник записи но потенциально куча читателей.
Этого всего нет и не будет ни в каких библиотеках, никаких растах.
Это именно низкоуровневый кодинг с использованием всех доступных фич ОС.
Так же как на линуксах делают магию со splice, каждый раз отдельно под каждую задачу.

Ну или упомянутые выше OpenCV - что вы там со своим знанием раста сделаете?
Соберёте тестовый пример?
OpenCV сам по себе "язык" по круче раста для работы с изображениями и видео, пофик с какого языка ты её юзаешь.

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

А если ты знаешь только язык то ты имплементатор/переводчик, которому всё расжовывают и он просто с человеческого на свой язык переписывает, без возможности что то понять или сделать самостоятельно более сложное решение.
Я одно время так занимался переводом математических идей на С, и мне не нравится такая работа.

Правда имплементировать крипту мне нравится, я даже свою реализацию ECDSA сделал с нуля на С.
Там и математика полностью своя.
Можешь падать в обморок или бится истерике: С, криптография и не дипломированный специалист в области крипты в одном  решении сошлись.


Надо ради прикола в ваш раст своего С кода понакомитить, по больше, чтобы он помер по быстрее :))))

Ответить | Правка | Наверх | Cообщить модератору

322. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Прохожий (??), 17-Сен-22, 17:06 
Слона-то я и не заметил. Ты реально ОСИЛИЛ прочитать оригинал? И что там говорится про существенно улучившуюся СТАБИЛЬНОСТЬ работы приложения благодаря смене ЯП?
Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

353. "Cloudflare перешёл с NGINX на собственный прокcи Pingora, на..."  +/–
Сообщение от Sw00p aka Jerom (?), 18-Сен-22, 11:40 
>и низкому переиспользованию конектов к конечным серверам.

а что они уверены, что каждый ориджин сервер будет держать открытым соединение?

>потребности выросли и стали слишком специфическими, а дальше они сели писать себе свой велосипед.

так и должны были поступать, а не использовать коробочное решение. Они таким же макаром могли переписать нджинкс под себя, но увы страх перед С. Жду новостей на тему "Как мы избавились от раст и сократили число серверов, попутно перенесли парсер ХТТП на какой-то SoC или FPGA :)"

Ответить | Правка | К родителю #155 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру