Чайник из Юты pinned «Пожалуй, буду разбавлять подобные посты в официальном стиле ещё и неким подобием дневника разработки вебсервера. Конечно, без всги/авсги/ювсги/придумайте-сами, а просто standalone. Однако, так даже интереснее: всегда хотел поработать напрямую с http. Сразу…»
Channel Public Channel
ЧА - Subscribers
- 122
- Photos
- 216
- Videos
- 3
- Links
- 144
Showing posts older than #30 · Back to latest
Older Posts 11 shown
Post #28
77
Пожалуй, буду разбавлять подобные посты в официальном стиле ещё и неким подобием дневника разработки вебсервера. Конечно, без всги/авсги/ювсги/придумайте-сами, а просто standalone. Однако, так даже интереснее: всегда хотел поработать напрямую с http. Сразу поставлю цель: выжать 50k RPS. Для начала, со статичным http-ответом. Сразу введу хэштег: #родтзе50кРПС #roadthe50kRPS
Post #27
75
Лонгриды хуйня, нужно больше жизненности в посты добавлять. А то всё серьезно-официально. Скучно, в общем, да и ненужно особо
Post #26
76
Следует ли делать полный рефактор проекта время от времени?
Если мы не говорим о бизнесе, то ответ очевиден. Да, конечно же надо, поскольку кодовая база всегда расширяется, а вот архитектура приложения - не всегда рассчитана на такое. Да и просто со временем, скапливается легаси - что плохо сказывается как на понятности кодбазы, что ещё сильнее мешает новым разработчикам влиться в процесс разработки.
Да и в целом, это довольно хорошая практика с той точки зрения, что во время полного рефактора уже набиты шишки, которых при переписывании проекта уже либо не будет, либо будет куда меньше (не забываем, что иногда приходится держать баланс между исправлением шишек и обратной совместимостью). Также можно и корректировать архитектуру, внося новые детали, которые позволят в меньшей степени требовать рефактора.
Однако, такие решения хороши для относительно небольших проектов. С монструозными проектами с сотнями тысяч строк кода, это будет не то, что затруднительно - это будет слишком дорого. Стоит понимать, когда есть целесообразность переписывать код, а когда - лучше либо частями это делать, либо вовсе свыкнуться с легаси, лишь попытавшись немного облегчить ситуацию.
И напомню, что речь не идёт о бизнесе. По крайней мере, о практически всём бизнесе. Бывают исключения, когда приложение прямо таки требует переписывания, однако, они не настолько частые, а в условиях не особо крупных компаний - предпочтут тащить на горбу этот сломанный-поломанный кусок программного обеспечения. Как никак, бизнес - это про говнокод, у которого есть лишь одно предназначение: работать, любым образом.
Вывод: рефактор - вещь хорошая, и даже нужная, однако не всегда имеет целесообразность.
Если мы не говорим о бизнесе, то ответ очевиден. Да, конечно же надо, поскольку кодовая база всегда расширяется, а вот архитектура приложения - не всегда рассчитана на такое. Да и просто со временем, скапливается легаси - что плохо сказывается как на понятности кодбазы, что ещё сильнее мешает новым разработчикам влиться в процесс разработки.
Да и в целом, это довольно хорошая практика с той точки зрения, что во время полного рефактора уже набиты шишки, которых при переписывании проекта уже либо не будет, либо будет куда меньше (не забываем, что иногда приходится держать баланс между исправлением шишек и обратной совместимостью). Также можно и корректировать архитектуру, внося новые детали, которые позволят в меньшей степени требовать рефактора.
Однако, такие решения хороши для относительно небольших проектов. С монструозными проектами с сотнями тысяч строк кода, это будет не то, что затруднительно - это будет слишком дорого. Стоит понимать, когда есть целесообразность переписывать код, а когда - лучше либо частями это делать, либо вовсе свыкнуться с легаси, лишь попытавшись немного облегчить ситуацию.
И напомню, что речь не идёт о бизнесе. По крайней мере, о практически всём бизнесе. Бывают исключения, когда приложение прямо таки требует переписывания, однако, они не настолько частые, а в условиях не особо крупных компаний - предпочтут тащить на горбу этот сломанный-поломанный кусок программного обеспечения. Как никак, бизнес - это про говнокод, у которого есть лишь одно предназначение: работать, любым образом.
Вывод: рефактор - вещь хорошая, и даже нужная, однако не всегда имеет целесообразность.
Post #25
86
Оказывается, при указании Content-Type: plain/text, тело ответа автоматически скачивается в файл. К примеру, заходя по
Мораль: если собрались работать с http, советую прежде почитать RFC.
localhost:9090/easter, у меня, как выше на скрине, просто скачивается одноимённый файл с телом ответа в этом самом файле (естественно, всё без расширения). Замена в заголовках ответа plain/text на дефолтный text/html чинит проблему. Мораль: если собрались работать с http, советую прежде почитать RFC.
Post #24
85
Однако, как вы уже поняли...
Post #23
82
посмотрите на этот код. Выглядит пристойно, не так ли? Браузер в теории должен просто взять, и показать текст "You found an easter-egg!".
Post #22
92
Представьте, что у вас есть веб-сервер. И у вас условно трафика на несколько тысяч запросов в секунду. Вы решили прямо в обработчиках запросов вкрутить принты - ну а что, логгирование так-то вещь полезная.
Представили? А теперь представьте, как вы плачете, потому что производительность упала на 20-30%.
И знаете, почему?
Да, всё верно. Питоний
Но что же тогда делать? Как делать логгирование?! Мы все умрём??
Нет. Если вы не хотите использовать всеразличные логгеры, коих полным полно - а хотите сделать так, чтобы логгеров было полным-полно и плюс ваш - можете сделать многопоточный логгер.
Суть такого логгера состоит в том, что при условном вызове
Поздравляю, вы сделали неблокирующий принт.
Представили? А теперь представьте, как вы плачете, потому что производительность упала на 20-30%.
И знаете, почему?
Да, всё верно. Питоний
print достаточно медленный, чтобы его блокирующий вызов во время обработки каждого запроса по итогу дал весьма неутешительные результаты при измерениях, особенно - на фоне результатов без этих принтов. Он может отнимать целые 60 микросекунд - что очень даже много, на фоне того, что запрос без этого обрабатывается всего за 140 микросекунд. Да, принт настолько сильно может влиять на производительность, если пихать его туда, где с высокой скоростью много раз в секунду должны происходить телодвижения.Но что же тогда делать? Как делать логгирование?! Мы все умрём??
Нет. Если вы не хотите использовать всеразличные логгеры, коих полным полно - а хотите сделать так, чтобы логгеров было полным-полно и плюс ваш - можете сделать многопоточный логгер.
Суть такого логгера состоит в том, что при условном вызове
logger.info(...), вместо того, чтобы прямо в нашей функции открывать файл на чтение (или вообще не закрывать дескриптор на протяжении всей жизни процесса; но если вы так сделаете, то знайте: я вас найду), или просто выводить надпись на экран аки принт - просто при инициализации логгера, создайте отдельный поток, а в конструкторе не забудьте прописать аттрибут с очередью. Думаю, объяснять про очереди мне не нужно - сами сможете почитать про Queue (кьюеуе, оно самое). Из этой самой очереди, наш второй поток и будет брать текст, который уже и будет записываться в файл/выводиться на экран. Поздравляю, вы сделали неблокирующий принт.
- 👍 1
Post #20
86
Никита я всё вижу
Post #19
84
Ничего
Channel created