Домашнее задание, написать эффективный TCP-сервер с определенными требованиями. Код должен быть покрыт юнит-тестами. Раньше TCP-сервера писать не приходилось, потратил три дня почти full-time, отослал результат. Ответили что стилистически код понравился, но сервер недостаточно эффективен, в частности имеются лишние копирования данных. Оценил что на исправление замечаний может уйти еще N часов. Забил.
Что бы вы ответили на предложение "написать эффективный TCP-сервер" в качестве тестового? Звучит как бред.
компания во главе с говнокодерами из Network Optix
не способа вообще ничего стоящего написать
юзают qt в еммедеде
вместе с кутешной тупой, медленной и не эффективной сетевой имплементацией
и подцепленным гстриммером
че там они реально кодят когда уже все накожено до них и все готово?
я всегда улыбался когда встречал отзывы о той бестолковой компании
и завышенным чсв их типа свиньёров
так что я улыбнулся когда очередной чел опять помянул ее
стилистика... лишнее копирование...
типичный отказ тех кто никого никогда не нанимает))
ps если че, я вообще никаким боком к нетоптикусу
просто реверсил как то их говнософт
гугля параллельно встречал отзывы
S>Домашнее задание, написать эффективный TCP-сервер с определенными требованиями. Код должен быть покрыт юнит-тестами. Раньше TCP-сервера писать не приходилось, потратил три дня почти full-time, отослал результат. Ответили что стилистически код понравился, но сервер недостаточно эффективен, в частности имеются лишние копирования данных. Оценил что на исправление замечаний может уйти еще N часов. Забил.
S>Что бы вы ответили на предложение "написать эффективный TCP-сервер" в качестве тестового? Звучит как бред.
Видимо, что-то поменялось у NO. У меня было всего три этапа, третий как раз system design. По первым двум этапам было адекватное впечатление, но system design смазало все откровенно. Задача была на построение архитектуры подобной торенту, что-то в этом роде. Я ее подзавалил, хотя не могу сказать, что полностью. Из уст собеседующего постоянно сквозило, что у него нет времени на разговоры, причем с какой-то злобой все произносилось.
Самое интересное, время они сами назначают.
Касаемо эффективности, вот судя по вопросам на первых двух этапах, не показалось, что там сильный уклон в эту сторону. Да, было разворачивание списка)
Здравствуйте, Shmj, Вы писали:
S>Что бы вы ответили на предложение "написать эффективный TCP-сервер" в качестве тестового? Звучит как бред.
В 22 году любое тестовое задание звучит как бред. Возможно, ради вот прямо компании мечты можно сделать исключение, но если это просто очередная компания из списка — зачем тратить свое время? Не лучше ли за это время пройти пару-тройку собеседований в более адекватных компаниях?
А уж эффективный сервер написать... а операционку им написать не надо?
Здравствуйте, Shmj, Вы писали:
S>Что бы вы ответили на предложение "написать эффективный TCP-сервер" в качестве тестового? Звучит как бред.
Вообще задание интересное, у меня у самого небольшой бзик к оптимизации. Не люблю кучу лишних копирований. В основном как раз по работе и пишу сервера, которые должны работать на слабом железе. Но давать такое задание на собеседовании даже в голову не придет, это перебор.
S>Домашнее задание, написать эффективный TCP-сервер с определенными требованиями. Код должен быть покрыт юнит-тестами. Раньше TCP-сервера писать не приходилось, потратил три дня почти full-time, отослал результат. Ответили что стилистически код понравился, но сервер недостаточно эффективен, в частности имеются лишние копирования данных. Оценил что на исправление замечаний может уйти еще N часов. Забил.
S>Что бы вы ответили на предложение "написать эффективный TCP-сервер" в качестве тестового? Звучит как бред.
Ну почему как бред. Надо просто немного повести диалог — уточнить, что конкретно там хотят видеть. Предложить решение — скажем, юзаем буст асио, корутины, тредов создаем по количеству ядер умножить на два. У всех разное ожидание "эффективного сервера", может там сразу скажут, что не любят лишнее копирование данных. Сказать им — тогда юзать смарт-поинтеры и не будет никакого копирования. Может и тестовое тогда не понадобится вообще, а можно намекнуть — зачем вам тестовое, если решение вот оно описано нами только что. Вот отказ от диалога с их стороны — косяк, нужно наверное тогда забить.
Здравствуйте, Denwer, Вы писали:
D>Вообще задание интересное, у меня у самого небольшой бзик к оптимизации. Не люблю кучу лишних копирований. В основном как раз по работе и пишу сервера, которые должны работать на слабом железе. Но давать такое задание на собеседовании даже в голову не придет, это перебор.
Здравствуйте, Shmj, Вы писали:
D>>Вообще задание интересное, у меня у самого небольшой бзик к оптимизации. Не люблю кучу лишних копирований. В основном как раз по работе и пишу сервера, которые должны работать на слабом железе. Но давать такое задание на собеседовании даже в голову не придет, это перебор.
S>Ок, приведите тут ваш "эффективный TCP-сервер".
Здравствуйте, reversecode, Вы писали:
R>и много вы написали эффективных серверов и вообще на тестовых заданиях ?
Ни одного, но задача интересная и при наличии стимула я бы повозился. Общее представление о том, как это делать, у меня имеется.
R>даю намёк R>на тестовом задании показывают общие знания R>а не на дурняк кому то делают работу за спасиба
Я не считаю, что написание эффективного hello world сервера это работа, которая чего-либо стоит в плане пользы. Вполне себе хорошее тестовое задание. И вполне себе бесполезный на практике код (т.к. любой адекватный проект будет использовать готовую библиотеку, а не велосипед).
R>ну и к тому же, та компания не написала и не пишет никаких эффективных серверов R>обычный говнокод
Ну говнокод, так говнокод. Я же не говорю, что для любой компании буду тратить 3 дня на тестовое задание. Всё зависит от числе собеседований, от офферов, от самой компании. Если это будет Гугл, который будет меня потенциально приглашать в Цюрих, я ему HTTPS-реализацию на ассемблере напишу. Ну или попытаюсь, по крайней мере.
R>так что я бы сказал любой кандидат там оверквалифай для той компании
R>ну и вообще та компания никого никогда не нанимает
Я уже понял, что у тебя личная вендетта к той компании. Мой ответ был без какой-либо специфики относительно конкретной компании. К примеру первую работу я получил, написав реализацию malloc и GUI к этой реализации, визуализирующий выделение памяти, на WinAPI. Я на это потратил выходные и не считаю это плохой задачей, мне это было интересно и работу я получил в итоге.
Здравствуйте, kaa.python, Вы писали:
Тё>>Взять готовую библиотеку. Но это же про C++, правда? Там у них своя атмосфэра.
KP>Ну вообще взять готовую библиотеку — это современный C++ путь. Но могут быть и исключения
Здравствуйте, Тёмчик, Вы писали:
Тё>>>Взять готовую библиотеку. Но это же про C++, правда? Там у них своя атмосфэра.
KP>>Ну вообще взять готовую библиотеку — это современный C++ путь. Но могут быть и исключения
Тё>Библиотека копирует буфер!
Да ладно. Даже на жаве netty ничего не копирует зазря, а напротив там куча приседаний, лишь бы не скопировать нечаянно.
S>Неужели вы, простой Вася из Урюпинска, сможете написать что-то более эффективное?
Ну конечно не сможет. Впрочем как и авторы подобных тестовых заданий.
П.С.
Вспомнил историю про лишнее копирование. Лет 7 назад писали для СХД небольшой модуль, который данные (без обработки) из диска в сеть передавал (или наоборот, не помню точно). В классическом подходе нужно прочитать данные с диска в userspace, а потом послать их в нужный сокет. То есть нужно дважды из userspace в kernelspace переходить. Казалось, что sendfile должен сильно помочь. Переписали, поймали несколько deadlock-ов из-за ошибок в ядре и после замеров стало понятно, что производительность лучше не стала, а код сильно усложнился. Возможно это произошло из-за того, что sendfile был сырой на тот момент. Все это я к тому рассказал, что все эти теоретические измышления про скорость работы не всегда работают. Нужно смотреть запуски программы на конкретном железе в реальном окружении.
Здравствуйте, vsb, Вы писали:
Тё>>Библиотека копирует буфер!
vsb>Да ладно. Даже на жаве netty ничего не копирует зазря, а напротив там куча приседаний, лишь бы не скопировать нечаянно.
Зато может, выделяет из кучи под новый буфер каждый раз- а значит, жрет и тормозит на GC.
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, vsb, Вы писали:
Тё>>>Библиотека копирует буфер!
vsb>>Да ладно. Даже на жаве netty ничего не копирует зазря, а напротив там куча приседаний, лишь бы не скопировать нечаянно.
Тё>Зато может, выделяет из кучи под новый буфер каждый раз- а значит, жрет и тормозит на GC.
Здравствуйте, vsb, Вы писали: vsb>Я не считаю, что написание эффективного hello world сервера это работа, которая чего-либо стоит в плане пользы. Вполне себе хорошее тестовое задание. И вполне себе бесполезный на практике код (т.к. любой адекватный проект будет использовать готовую библиотеку, а не велосипед).
Задача может быть и не плохая, просто эффективность нужно мерить в цифрах, иначе это не серьезно
если бы было сравнение работы реализации эталонной и кандидата, тогда можно о чем то судить, а просто смотреть код и рассуждать об эффективности, не думаю что это правильно
Здравствуйте, Shmj, Вы писали:
S>Просто сама постановка вопроса. Вот, для примера, образцовая реализация TCP-сервера из книги: http://www.khmere.com/freebsd_book/src/06/poll_socket.c.html S>Ну или что-то подобное можно найти открытое, которое уже реализовали 300 раз и пытались оптимизировать лучшие умы человечества. S>Неужели вы, простой Вася из Урюпинска, сможете написать что-то более эффективное?
Хорошо было бы увидеть истинно эффективную реализацию сервера от этой конторы, что бы было с чем сравнивать
Мне кажется правильно сказал reversecode про "завышенное чсв свиньёров"...
Здравствуйте, Shmj, Вы писали: S>Просто сама постановка вопроса. Вот, для примера, образцовая реализация TCP-сервера из книги: http://www.khmere.com/freebsd_book/src/06/poll_socket.c.html S>Ну или что-то подобное можно найти открытое, которое уже реализовали 300 раз и пытались оптимизировать лучшие умы человечества. S>Неужели вы, простой Вася из Урюпинска, сможете написать что-то более эффективное?
Образцовый сервер из книги писал лохопед и вот почему: если хотя бы в одном из входящих соединений со стороны пользователя начнут принимать данные очень медленно, скажем, по байту в секунду, то запросы других пользователей к серверу будут ждать обработки очень и очень долго.
Грамотный инженер слушал бы все запросы в главном потоке, а обработку каждого запроса делал бы во вновь создаваемом потоке. Таким образом, обработка каждого запроса пользователя станет независимой. После обработки запроса поток можно спокойно удалять.
Второе: в книжном сервере загружено лишь одно ядро процессора да и то кэш этого ядра процессора будет постоянно вымываться из-за смены порядка обработки запросов к серверу от разных пользователей. В нашем случае, все ядра процессора будут загружены работой из-за независимой, многопоточной обработки запросов и кэши каждого из ядер процессора не будут вымываться, потому что каждое ядро процессора будет обрабатывать свой поток с нужными только этому потоку данными.
G>В 22 году любое тестовое задание звучит как бред. Возможно, ради вот прямо компании мечты можно сделать исключение, но если это просто очередная компания из списка — зачем тратить свое время? Не лучше ли за это время пройти пару-тройку собеседований в более адекватных компаниях?
А вот мне скорее нравится, когда тестовые задания дают на дом. По крайней мере у меня с ними обычно не возникает больших проблем.
Как правило в этом случае есть довольно много времени на решение. Обычно, когда я получаю такое задание, я сначала внимательно читаю его, чтоб понять что к чему, потом забиваю и оставляю на следующий день. Обычно сутра я уже прекрасно понимаю, как я буду делать задание в голове есть не только решение, но архитектура(разбивка на классы).
Вообще на работе я часто поступаю примерно так же, если не ясно, как делать ту или иную задачу, я делаю перерыв, иду попить кофе, пообедать, вот форум могу почитать, или вообще забить до следующего дня. После перерыва в мозгу как правило появляется понимание.
Со стороны конторы, плюс тестового задания в отсеивании кандидатов, которые просто так ходят по собеседованиям от нечего делать.
Но сейчас мода поменялась, сейчас почти все серьезные да и несерьезные работодатели берут пример с Гугла и заставляют решать тебя алгоритмические задачи непосредственно на собеседовании. Так уж получилось, что я никогда не занимался спортивным программированием и не участвовал в олимпиадах, а на работе навык быстрого решения алгоритмичесмких задачь не прокачивается совсем.
В итоге, на таких собеседованиях я либо мгновенно понимаю как решать задачу (что бывает не часто), либо мой мозг говорит, "сделай перерыв", отказывается что-то решать, и вообще не хочет думать, в этом случае я начинаю выглядить перед интервьюерами (да и сам перед собой) полным дебилом.
Учитывая современные тенденции, ИМХО мне все-таки придется научиться решать задачи на скорость если я планирую еще поработать, потому, что скоро на такой метод собеседований перейдут вообще все. Проблема в том, что мне очень скучно просто так сидеть и прорешивать задачи уж лучше тестовые задания
G>А уж эффективный сервер написать... а операционку им написать не надо?
Вообще, для человека, постоянно работающего с сетью, написать tcp сервер — это не сложная задача, но вот под словами "эффективный" можно могут скрываться совершенно разные вещи. Тут сложно что-то сказать не видя кода этого самого сервера, может быть там какие-то совершенно банальные студенческие ошибки, может быть он с сетью никогда не работал.
просто вася из урюпинска может написать более эффективный nginx
да и всегда мог написать
почему не писал или не напишет сейчас
это уже тема прям отдельного большого бесконечного топика
Здравствуйте, ksandro, Вы писали:
K>А вот мне скорее нравится, когда тестовые задания дают на дом. По крайней мере у меня с ними обычно не возникает больших проблем.
Нет, ну если ты решаешь "для себя", в целях самообучения, тренировки и т.д -почему бы и нет.
Но если ты решаешь только для того, чтобы тебя допустили до интервьювера — хм, это сомнительная инвестиция времени.
K>Со стороны конторы, плюс тестового задания в отсеивании кандидатов, которые просто так ходят по собеседованиям от нечего делать.
Также отсеют тех, кто ценит свое время.
А вот тех, кто попросит сделать задание друга — наоборот, привлекут.
Ну бог с ними, с конторами. Мы же, как кандидаты, должны думать о себе.
Зачем делать задание, если можно просто пойти на собеседование без заданий?
K>Но сейчас мода поменялась, сейчас почти все серьезные да и несерьезные работодатели берут пример с Гугла и заставляют решать тебя алгоритмические задачи непосредственно на собеседовании.
Ты пропустил следующее изменение моды. Компании, в исступлении копирующие Гугл, то и дело совершают каминг-ауты с и констатируют неэффективность таких методов.
И, тут у меня закралось сомнение, а в какой стране ты ищешь работу? Ну то есть в РФ уже лет наверное 10 тестовые задания стали скорее исключениями.
K>Так уж получилось, что я никогда не занимался спортивным программированием и не участвовал в олимпиадах, а на работе навык быстрого решения алгоритмичесмких задачь не прокачивается совсем.
Ну даже не знаю, у меня пару лет назад был забег по собеседованиям, и даже тогда, на пике hiring freeze, только 1 из 30 компаний предлагала задание. И еще две — решать алгоритмические задачки.
С тех пор периодически пингую рынок, и сейчас, на фоне взрывной нехватки айтишников, ни разу не встретил требование решить ТЗ ни алгоритмических задач.
Ну да, наверное, я просто не пробовал устроится в Яндекс ))
K>Вообще, для человека, постоянно работающего с сетью, написать tcp сервер — это не сложная задача, но вот под словами "эффективный" можно могут скрываться совершенно разные вещи. Тут сложно что-то сказать не видя кода этого самого сервера, может быть там какие-то совершенно банальные студенческие ошибки, может быть он с сетью никогда не работал.
Да это вообще плевок в кандидата.
Настолько неконкретные требования.
И как я понимаю, задавать уточняющие вопросы через HR весьма тяжело.
Еще раз.
Надо уважать свое время.
Уважать себя.
Если сам себя не уважаешь — почему работодатель это будет делать?
И у айтишников есть объективные причины проявлять жесткость на переговорах.
Вот, за прошлый год стоимость найма подросла процентов 25. В этом году (если верить аналитическим агентствам, которым платит моя контора за доступ к исследованиям) вообще до 40% дойдет
Здравствуйте, Тёмчик, Вы писали:
KP>>Ну вообще взять готовую библиотеку — это современный C++ путь. Но могут быть и исключения
Тё>Библиотека копирует буфер!
Нет. Написано ж выше: библиотека может выбросить исключение!
Здравствуйте, Gradiens, Вы писали:
G>Здравствуйте, ksandro, Вы писали:
G>Нет, ну если ты решаешь "для себя", в целях самообучения, тренировки и т.д -почему бы и нет. G>Но если ты решаешь только для того, чтобы тебя допустили до интервьювера — хм, это сомнительная инвестиция времени.
Наверное я решаю скорее для себя. Но тут у меня обычно есть какой-то интерес решить задачу и попасть на собеседование, даже как-то было, что решал, получал приглашение на собеседование, но отказывался туда идти.
А вот просто взять какой-нибудь leetcode и начать прорешивать не могу, как-то сразу интерес теряю.
G>Также отсеют тех, кто ценит свое время. G>А вот тех, кто попросит сделать задание друга — наоборот, привлекут.
Да, что отсеят тех кто ценит свое время, я согласен.
Ну, тех кто просит сделать друга на собеседовании вычислить не так уж сложно.
G>Ну бог с ними, с конторами. Мы же, как кандидаты, должны думать о себе. G>Зачем делать задание, если можно просто пойти на собеседование без заданий?
Да вот придешь на собеседование без заданий, а там тебя заваливают алгоритмическими задачками. Как правило, если есть тестовое задание, на собеседовании уже кодинга на время не будет.
G>Ты пропустил следующее изменение моды. Компании, в исступлении копирующие Гугл, то и дело совершают каминг-ауты с и констатируют неэффективность таких методов.
Ну вообще это логично, если человек может пойти в гугл, он и пойдет в Гугл, но про камминг-ауты было бы интересно почитать.
Ну вот не знаю, меня где-то на 70% собеседований заставляют решать алгоритмические задачи, где-то совсем простые, где-то непростые, но почему-то везде заставляют...
G>И, тут у меня закралось сомнение, а в какой стране ты ищешь работу? Ну то есть в РФ уже лет наверное 10 тестовые задания стали скорее исключениями.
По большей части в РФ, и если пишут иностранные рекрутеры, тоже бывает отвечаю, сейчас это не так интересно, раньше до ковида можно было нахаляву скататься в Европу на собеседование... сейчас это уже как-то не практикуют.
Ты не очень понял что я написал, сейчас везде алгоритмические задачи и кодинг непосредственно на собеседовании, и это у меня плохо получается, раньше тестовые задания встречались чаще и с ними у меня процент прохождения собеседований был намного выше.
Но вообще и задания на дом иногда встречаются.
G>Ну даже не знаю, у меня пару лет назад был забег по собеседованиям, и даже тогда, на пике hiring freeze, только 1 из 30 компаний предлагала задание. И еще две — решать алгоритмические задачки. G>С тех пор периодически пингую рынок, и сейчас, на фоне взрывной нехватки айтишников, ни разу не встретил требование решить ТЗ ни алгоритмических задач. G>Ну да, наверное, я просто не пробовал устроится в Яндекс ))
Возможно я просто хожу на собеседования, где предлагают выше рынка, там встречаются и задачи и тестовые задания (чаще задачи). Хотя может раньше я ходил по всем подряд и поэтому результаты были лучше
G>Да это вообще плевок в кандидата. G>Настолько неконкретные требования. G>И как я понимаю, задавать уточняющие вопросы через HR весьма тяжело.
Ну, мы ж не знаем, как там в реальности была сформулирована задача, я бы воздержался от громких фраз типа "плевок". Мы не видели ни полный текст задания ни код, который отправил кандидат.
G>Еще раз. G>Надо уважать свое время. G>Уважать себя. G>Если сам себя не уважаешь — почему работодатель это будет делать? G>И у айтишников есть объективные причины проявлять жесткость на переговорах. G>Вот, за прошлый год стоимость найма подросла процентов 25. В этом году (если верить аналитическим агентствам, которым платит моя контора за доступ к исследованиям) вообще до 40% дойдет
Да это все понятно, я просто говорю, что лично мне с тестовое задание нравится больше чем онлайн кодинг алгоритмических задач.
А если хочешь выше рынка, то как правило приходится соглашаться на правила собеседований от работодателя.
Здравствуйте, scf, Вы писали: scf>У меня было четкое понимание, что создание потока — это дорого и поэтому придумали тредпулы.
Можешь попробовать открыть мою домашнюю страницу и оценить в деле насколько дорого выходит создание и уничтожение нового потока на каждый запрос пользователя.
Здравствуйте, Shmj, Вы писали:
S>Ок, приведите тут ваш "эффективный TCP-сервер".
Нет универсального эффективного сервера, есть эффективный сервер под конкретные задачи. В том числе верно спроектированный/выбранный протокол. Кстати, очень часто вижу как в таких серверах вызываются функции на выделение и удаление памяти, причем в тех местах, где просто просится буффер на коннект или же просто смена алгоритма позволяет избежать вообще выделение памяти.
Здравствуйте, reversecode, Вы писали:
R>нет эффективной готовой библиотеки для С или С++ R>даже asio для студентов, можете ее автору так и сказать
Ну я использовал АСИО в своих проектах, держала нагрузку очень хорошо. Я даже не помню что бы там процессор был загружен при нескольких тысячах коннектов.
Здравствуйте, Pitirimov, Вы писали:
P>Можешь попробовать открыть мою домашнюю страницу и оценить в деле насколько дорого выходит создание и уничтожение нового потока на каждый запрос пользователя.
Что там можно увидеть? Пустая страничка с бекграунд фото какой то музыкальной системы.
S>Неужели вы, простой Вася из Урюпинска, сможете написать что-то более эффективное?
Что-то имеете против простых "Вась из Урюпинска"? Напомню, у простого Игоря из Алма-Аты, в свободное от работы сисадмином время, получилось — значит и у Васи может получиться.
S>Что бы вы ответили на предложение "написать эффективный TCP-сервер" в качестве тестового? Звучит как бред.
Послал бы лесом этих клоунов, а если потроллить бы захотелось, то месяц бы уточнял требования и расшифровку эффективности и после послал бы лесом.
Здравствуйте, ksandro, Вы писали:
K>Учитывая современные тенденции, ИМХО мне все-таки придется научиться решать задачи на скорость если я планирую еще поработать, потому, что скоро на такой метод собеседований перейдут вообще все. Проблема в том, что мне очень скучно просто так сидеть и прорешивать задачи уж лучше тестовые задания
Тоже пришлось немного порешать.
Скуку немного развеивают графики(на том же leetcode).
Когда сделаешь решение, они показывают в какой диапазон ты попал по скорости выполнения и памяти относительно других.
Я как-то выкатил решение. Немного опечатался, что где-то в середине. Потом, по-моему, удалил отладочные выводы и попал в топ 1% или около того. Чему порадовался. И хотелось дальше что-нибудь решать)
Есть советы как натаскиваться — к примеру 1 час в день уделять.
У меня так же как у тебя — смотрел, пробовал, уходил. Через время возвращался.
На хабре советовали — если за сколько-то минут не понятно, то смотреть решение и повторять.
Итог должен быть — чтобы ты их быстро щелкал за минут 20-30.
Здравствуйте, reversecode, Вы писали:
R>если вы не знаете как устроен asio и вообще не знаете как проектируются такого рода "реакторы" так сказать R>так понятно что вам и так сойдет
Откуда этот вывод был сделан. Я его использую с самого его появления, когда еще он не был в составе буста. Как он устроен я знаю, знаю его реализацию для линукса и для винды. Что значит и так сойдет? Он нагрузку держит хорошо очень, да и баги уже давно не встречались, по началу были. Ты уж раскрой свое "и так сойдет".
Здравствуйте, Gradiens, Вы писали:
G>Нет, ну если ты решаешь "для себя", в целях самообучения, тренировки и т.д -почему бы и нет. G>Но если ты решаешь только для того, чтобы тебя допустили до интервьювера — хм, это сомнительная инвестиция времени.
Есть и другие мотивы.
1. Тестовое задание всегда можно выложить к себе на Гитхаб, время от времени пригождается.
2. Тестовое задание отчасти показывает то, что придётся делать дальше. У меня было прекрасное собеседование с одной конторой по обработке видео. Взял делать тестовое — там оказался DirectShow, от которого меня тошнит. Не делал, сразу сказал, что не подхожу им.
3. Выполненное тестовое задание — это прекрасная тема для разговора. Лучше спрашивать на собеседовании не абстрактные задачки, а конкретную реализацию.
4. Если у нас цель — нанять программиста, который будет писать код и продумывать архитектуру в спокойной обстановке, то лучше проверить как он пишет код и продумывает архитектуру. Если цель — нанять программиста, который умеет красиво рассуждать, то лучше проверять его умение устно рассуждать.
5. Многие хорошие программисты отсеиваются на собеседовании из-за своих социальных качеств. Но если нам они не важны, тогда зачем валить его устно, а не предложить проявить себя с сильной стороны?
Здравствуйте, Pitirimov, Вы писали: P>Можешь попробовать открыть мою домашнюю страницу и оценить в деле насколько дорого выходит создание и уничтожение нового потока на каждый запрос пользователя.
Попробуй открыть мою домашнюю страницу — https://scf37.me держит тысячи запросов в секунду, и потоки на каждый запрос не создает.
Здравствуйте, scf, Вы писали:
scf>Попробуй открыть мою домашнюю страницу — https://scf37.me держит тысячи запросов в секунду, и потоки на каждый запрос не создает.
Здравствуйте, Shmj, Вы писали:
S>А подробнее можно? Самописный сервер? На C?
В 21 веке слегда подтюненное приложение на spring boot может выдать такие скорости на хорошем железе. Низкоуровневое Java приложение не уступит самописке на сях больше, чем в 2-3 раза. Я использую https://twitter.github.io/finagle/
Здравствуйте, Pitirimov, Вы писали:
P>все ядра процессора будут загружены работой из-за независимой, многопоточной обработки запросов и кэши каждого из ядер процессора не будут вымываться, потому что каждое ядро процессора будет обрабатывать свой поток с нужными только этому потоку данными.
Как гарантировать, что поток будет постоянно работать на одном и том же ядре? Руками выставлять thread affinity?
"For every complex problem, there is a solution that is simple, neat,
and wrong."
S>Домашнее задание, написать эффективный TCP-сервер с определенными требованиями. Код должен быть покрыт юнит-тестами. Раньше TCP-сервера писать не приходилось, потратил три дня почти full-time, отослал результат. Ответили что стилистически код понравился, но сервер недостаточно эффективен, в частности имеются лишние копирования данных. Оценил что на исправление замечаний может уйти еще N часов. Забил.
S>Что бы вы ответили на предложение "написать эффективный TCP-сервер" в качестве тестового? Звучит как бред.
Статья моя. Если что, вот код сервера, думаю никто особо не обидится что опубликовал, всё равно он неэффективный
Здравствуйте, scf, Вы писали:
scf>В 21 веке слегда подтюненное приложение на spring boot может выдать такие скорости на хорошем железе. Низкоуровневое Java приложение не уступит самописке на сях больше, чем в 2-3 раза. Я использую https://twitter.github.io/finagle/
Здравствуйте, scf, Вы писали:
scf>Здравствуйте, Shmj, Вы писали:
S>>А подробнее можно? Самописный сервер? На C?
scf>В 21 веке слегда подтюненное приложение на spring boot может выдать такие скорости на хорошем железе. Низкоуровневое Java приложение не уступит самописке на сях больше, чем в 2-3 раза. Я использую https://twitter.github.io/finagle/
А где хостите (vps?) и сколько выходит по деньгам?
Скорость впечатляет. Но, вероятно, за это приходится платить плохой поисковой индексацией?
Здравствуйте, Shmj, Вы писали:
S>Это вы так верите или делали реальные замеры? S>Как ваше приложение держит Slow DDoS Attack?
Замерял wrk. Приложение использует IO на селекторах, т.е. коннекты дешевые, несколько тысяч одновременных подключений не являются проблемой. Стоит лимит в 20 коннектов на IP, поведение при таком DDoS не проверял, но должно быть норм.
Здравствуйте, Михaил, Вы писали:
М>А где хостите (vps?) и сколько выходит по деньгам? М>Скорость впечатляет. Но, вероятно, за это приходится платить плохой поисковой индексацией?
Hetzner, VPS, недавно подняли цены с 24 до 36 евро. Стало дороговато, может буду искать альтернативу, а может и не буду — проблемы с хостингом возникают не чаще, чем раз в пару лет.
С поисковиками всё отлично, сайт не использует клиентский рендеринг. Приемы оптимизации я подсмотрел у старого вконтакта — секрет в небольшом размере ресурсов и правильной доставке их в браузер.
Здравствуйте, ArtDenis, Вы писали:
AD>Не заметил сразу, искал копирования )) Синхронная запись — это косяк значительно серьёзнее копирования данных в строку
Я потом все же избавился от лишних копирований и сделал асинхронно.
Но юнит-тесты уже не осилил, вернее не захотел осиливать, так как не мог позволить себе тратить на задание больше времени.
Послал им, авось оценят усердие и прокатит. Но нет.
Здравствуйте, dwebster, Вы писали:
S>>Ну и общее впечатление такое, что писал человек, у которого бэкграунда в Java или в C# больше, чем в C++.
D>Нет, с Java и C# опыта практически нет.
Странно. Судя по проектным решениям вы на C++ в стиле Java/C# программируете, нежели в C++ном.
Здравствуйте, Тёмчик, Вы писали:
Тё>Я даже не удивлён, что ты этого не заметил, а только докопался до копирования.
Я отвечал на комментарий, в котором говорилось про копирование. И показал, что копирование там не только в том месте, на которое указал ArtDenis.
Тё>Общее впечатление, что писал человек без понимания алго-сложности, типично для C++ бекграунда. Тё>https://github.com/w5346c/hash_server/blob/master/lib/request_responder_impl.cpp
Чтобы говорить про алго-сложность нужно знать точную постановку задачи. Я ее не знаю.
Судя по коду, автору нужно было разбить входной поток на отдельные строки и подсчитать хэш-код для каждой строки.
Если это так, то я бы сделал цикл разбора каждой прочитанной порции несколько иначе, используя find для '\n'. Что-то вроде (это набросок, который никак не проверялся и написан без оглядки на реальный API):
Но, по сути, это был бы тот же самый цикл от начала в конец входного буфера, как и у автора. Только с надеждой на то, что он будет несколько эффективнее, т.к. std::string::find может оптимизироваться до специфических инструкций CPU по обработке байтовых последовательностей. Хотя еще хрен знает во что современные оптимизирующие компиляторы развернут цикл, написанный в стиле:
for(std::size_t i = 0; i < len; ++i) {
if(s[i] != '\n') continue;
...
}
Еще меня лично сильно смущает то, что автор накапливает "хвост" из входного буфера в отдельном std::string, который может расти неограниченно долго, в зависимости от входных данных. Следовало бы взять такую реализацию подсчета хэша, которой фрагменты строки можно было бы скармливать частями перед получением итогового результата. Но автор тестового задания явно такими вещами не заморачивался судя по коду.
UPD. Если нужно только хэши для строк считать и все, то достаточно всего одного прохода по входному буферу из начала в конец с посимвольным скармливанием очередного символа вычислителю хэша (если очередной символ не '\n') и специальной обработкой символов '\n'. Тут даже не нужно отдельных подстрок выделять в каком-либо виде.
Но, есть у меня впечатление, что ты, Тёмчик, будучи Ъ-экспертом по алгоритмам, разобъешь эти мои соображения в пух и прах. Так что с большим интересом, любопытством и смирением готов выслушать объективную критику и конструктивные соображения с твоей стороны.
Здравствуйте, so5team, Вы писали:
S>Я отвечал на комментарий, в котором говорилось про копирование. И показал, что копирование там не только в том месте, на которое указал ArtDenis.
Ну я особо внимательно не смотрел. Спросил про первое попавшееся на глаза место в коде. Если глянуть больше, то да, видно что человек писал сразу как пришло в голову. Из-за большого количества аллокаций/перелокаций, копирований и деалокаций в строках эффективностью тут и не пахнет.
Хотя, требования к эффективности надо обговаривать изначально в ТЗ. Возможно если бы они были, человек написал бы по-другому.
Здравствуйте, reversecode, Вы писали:
R>так что я улыбнулся когда очередной чел опять помянул ее
Сколько пролилось интересного Не взяли? Меня, кстати, в свое время не взяли, сейчас у меня пара их сотрудников работает. Отличные ребята (один как раз вроде меня и отшил на собеседовании по плюсам), только оверинжинирят слегка.
Здравствуйте, so5team, Вы писали:
S>Чтобы говорить про алго-сложность нужно знать точную постановку задачи. Я ее не знаю.
Вот постановка.
Клиентское приложение устанавливает TCP-соединение и передает
строки, разделенные символом перевода строки “\n”. Сервер должен считать их хеш-суммы (тип
суммы — на выбор кандидата) и отправлять их обратно в HEX-виде, также завершая каждую сумму
символом перевода строки.
Клиентские запросы должны обрабатываться параллельно, в случае достаточного количества
параллельных соединений должны быть загружены все ядра CPU. Сервер должен работать
эффективно — не потреблять лишней памяти и отправлять хэш-суммы по мере их готовности. Входные
строки могут быть неограниченной длины.
Для реализации сетевой части сервера можно использовать любую удобную вам библиотеку из числа
стандартных пакетов репозитория Ubuntu 16. Сервер также должен собираться и работать на Ubuntu
16.
На модули приложения должны быть написаны unit-тесты.
Да, я бOльшую часть времени убил на разбирательство с boost asio и осознанием как это все покрыть юнит-тестами.
Первая версия получилась неэффективной, но покрытой.
Вторая более эффективной, но не покрытой — https://github.com/w5346c/hash_server2
Потом получил устраивающий меня оффер из другой компании и продолжать не стал.
Здравствуйте, dwebster, Вы писали:
D>Входные строки могут быть неограниченной длины.
Вы специально это требование проигнорировали в обоих реализациях?
D>Для реализации сетевой части сервера можно использовать любую удобную вам библиотеку из числа D>стандартных пакетов репозитория Ubuntu 16. Сервер также должен собираться и работать на Ubuntu D>16.
Здравствуйте, so5team, Вы писали:
D>>Входные строки могут быть неограниченной длины.
S>Вы специально это требование проигнорировали в обоих реализациях?
Строки такой длины, чтоб не влезали в память.. да ну, бред какой-то )
В реальном сервере я бы вставил проверку на максимальную длину.
Здравствуйте, dwebster, Вы писали:
D>Да, я бOльшую часть времени убил на разбирательство с boost asio и осознанием как это все покрыть юнит-тестами. D>Первая версия получилась неэффективной, но покрытой. D>Вторая более эффективной, но не покрытой — https://github.com/w5346c/hash_server2 D>Потом получил устраивающий меня оффер из другой компании и продолжать не стал.
Похоже, тут если `m_writeInProgress == true`, то подсчитанный hash просто не записывается. Я asio лет 5 уже не использовал, там вроде бы в случае, если идет асинхронная запись, принято добавлять данные в очередь исходящих, чтобы потом проверять ее в `OnWriteCompleted` и записывать оставшееся.
Ну и по традиции русского форума, добавлю что код написан в стиле C++98, что странно для 2021 года. Еще видно, что автор не имел опыта с asio, в чем он честно выше и признался.
Еще мне всегда было непонятно, как можно написать юнит тесты для сетевого кода. Это же взаимодействие с внешним миром. Все время получалось только end-to-end: со стороны клиента проверять ожидаемые ответы на определенные запросы.
Здравствуйте, dwebster, Вы писали:
S>>Вы специально это требование проигнорировали в обоих реализациях?
D>Строки такой длины, чтоб не влезали в память.. да ну, бред какой-то )
Складывается ощущение, что вы сейчас в более выигрышной ситуации, чем компания, которой вы сделали черный PR. Вы-то можете рассказать какое было хреновое тестовое и как вам вообще процесс общения с компанией не понравился. Тогда как компания не может сказать, что ей пришлось отшить неадекватного говнокодера-неумеху, хотя это чистая правда в данном случае.
Здравствуйте, so5team, Вы писали:
S>Вы-то можете рассказать какое было хреновое тестовое и как вам вообще процесс общения с компанией не понравился.
Вообще-то в статье я написал ровно наоборот — "В целом, общение с представителями компании оставило самые приятные впечатления".
И внес компанию в тройку компаний, собеседоваться в которые мне понравилось больше всего за карьеру.
Уверен, в NetworkOptix отлично работается и спецы там высококлассные. То что не добил тестовое — мое решение.
Я в это время параллельно проходил этапы собеседований в несколько компаний, и тратить много времени на одну не было ни возможности, ни желания.
Не так уж сильно хотелось работать именно там, чай не Гугл.
Здравствуйте, dwebster, Вы писали:
D>Клиентское приложение устанавливает TCP-соединение и передает D>строки, разделенные символом перевода строки “\n”. Сервер должен считать их хеш-суммы (тип D>суммы — на выбор кандидата) и отправлять их обратно в HEX-виде, также завершая каждую сумму D>символом перевода строки. D>Клиентские запросы должны обрабатываться параллельно, в случае достаточного количества D>параллельных соединений должны быть загружены все ядра CPU. Сервер должен работать D>эффективно — не потреблять лишней памяти и отправлять хэш-суммы по мере их готовности. Входные D>строки могут быть неограниченной длины.
Смущает момент с "должны быть загружены все ядра CPU". Это самое сложное здесь
Вот смотри: вначале строки, хэш=0. Каждый последующий символ, хэш считает на основе предыдущего значения хэша, кумулятивно (т.е. алгоритм занимает фиксированно 32bit или сколько там у тебя хэш). По прибытию перевода строки, форматируем в строковое представление и асинхронно кидаем на отправку, а кумулятивный хэш обнуляем.
Надеюсь, что буст асио из коробки использует пул потоков (чтоб загружать ядра), иначе борьба с синхронизацией, гонками, дедлоками и т.п. прелестями приаедет тебя в целый новый мир боли и мазохизма.
Здравствуйте, reversecode, Вы писали:
R>вы уже отправили пуш реквест в репу asio examples по поводу фиксов таких ляпов ?
Нет. И придерживаюсь мнения, что в примерах не нужно отвлекаться на такие тонкости.
R>то всякие школьники написавшие asio, налепят тупых примеров R>а другие потом учатся на них
Скажите, пожалуйста, а ваш апломб подтвержден какими-то публично-доступными результатами, которые могут использоваться другими людьми?
Здравствуйте, reversecode, Вы писали:
R>но считаю что вы его +-выполнили, остальное фигня
Ахринеть, дайте два!
В условии задачи было три принципиальных момента:
1. Параллельная обработка запросов. Тут условная галочка, хотя есть вопрос к формулировке "Клиентские запросы должны обрабатываться параллельно, в случае достаточного количества параллельных соединений должны быть загружены все ядра CPU." Еще можно интерпретировать и так, что задействовать очередное ядро CPU следует после того, как количество параллельных соединений превышает некий порог. Т.е., до 1000 соединений на одном ядре, до 2000 -- на двух и т.д.
2. Отсылка хэшей по мере их готовности (т.е. запись одновременно с чтением). Тут, опять же, условная галочка для варианта #2, но минус для варианта #1. Кроме того, для варианта #2 нужно посмотреть, почему в коде не используются strand-ы для операций чтения/записи, и насколько безопасно писать что-то в asio::streambuf пока этот самый streambuf задействуется в незавершившейся еще операции записи (хотя, подозреваю, под Linux-ом это безопасно).
3. Способность обрабатывать входящие строки неограниченной длины. Тут жирный минус по обоим вариантам. Это условие вообще самым тупым образом проигнорировано, а автор самым тупым образом прикидывается ветошью и пытается не отсвечивать.
Здравствуйте, dwebster, Вы писали:
D>Вообще-то в статье я написал ровно наоборот — "В целом, общение с представителями компании оставило самые приятные впечатления".
По факту вы оставили следующее впечатление о компании:
1. Они дают тестовое задание. Для многих, что видно даже по этому обсуждению, сие уже есть фу-фу-фу.
2. Они не дают вменяемой обратной связи по тестовому заданию. Вы пишите "Ответили что стилистически код понравился, но сервер недостаточно эффективен, в частности имеются лишние копирования данных", а не "ответили, что стилистически код понравился, но сервер недостаточно эффективен из-за лишнего копирования данных в таких-то и таких-то местах". Что есть еще одно фу-фу-фу уже для той части аудитории, для которой тестовое задание, в принципе, приемлемо.
D>И внес компанию в тройку компаний, собеседоваться в которые мне понравилось больше всего за карьеру.
Из этого не следует, что эта компания хорошая. Следует лишь то, что почти все другие еще хуже.
Здравствуйте, so5team, Вы писали:
S>Это условие вообще самым тупым образом проигнорировано, а автор самым тупым образом прикидывается ветошью и пытается не отсвечивать.
Again, я потратил за задание два дня, разбираясь с boost asio, который до этого в глаза не видел.
После этого дальше не имел возможности тратить время на одно задание одной компании. В которой к тому же после задания предстояло еще интервью на 4 часа оффлайн по темам, в которых я не силен, так что вряд ли бы прошел. Послал что есть, авось прокатит. Не прокатило, ок, никаких обид.
Потом еще потратил немного времени, зафиксал что смог быстро. Опять не прокатило, ок.
Здравствуйте, dwebster, Вы писали:
D>Again, я потратил за задание два дня, разбираясь с boost asio, который до этого в глаза не видел.
Давайте и я вам еще раз: вы позволили себе высказать свою точку зрения на происходящие события. И тем самым спровоцировали негативные отзывы в адрес компании (кому-то не понравился сам факт наличия тестового, какой-то анонимный экспертный эксперт объявил разработчиков из этой компании в непрофессионализме, а продукты компании в низком качестве). При этом вы убеждены, что высказались объективно.
При этом компания не может себе позволить высказаться объективно по вашему поводу, а именно: пришел человек без нужных знаний, потратил кучу времени на простое тестовое, сделал абы как, важное обязательное требование вообще проигнорировал.
Здравствуйте, so5team, Вы писали:
Тё>>Помнится, кое-кто хранит обьекты в хеш мапе, ибо в подсчет ссылок нишмогла.
S>Тёмчик, ты опять ничего не понял, но щеки надул и авторитетно пукнул в лужу.
Ну конечно же ничего не понял, это ж сумрачный гений состима не мог укуренный дизайн выдать.
Тё>>алгоритмы 3 Тё>>оформление 5 Тё>>многопоточка 4.
S>На C++ с Asio в многопотоке давно программировал, экспертный ты наш?
Немного трогал асинхронный io в прошлом. А также, работал вместе с автором asio в одном отделе и ходил на пятничный beer.
S>PS. А что тема с алго-сложностью
Здравствуйте, Тёмчик, Вы писали:
S>>Тёмчик, ты опять ничего не понял, но щеки надул и авторитетно пукнул в лужу. Тё>Ну конечно же ничего не понял, это ж сумрачный гений состима не мог укуренный дизайн выдать.
А какой не укуренный? Только давай предметно.
S>>На C++ с Asio в многопотоке давно программировал, экспертный ты наш? Тё>Немного трогал асинхронный io в прошлом.
Т.е. ни строчки.
Тё>А также, работал вместе с автором asio в одном отделе и ходил на пятничный beer.
Т.е. ты оценки расставляешь просто потому, что квасил с Крисом? Прэлестно.
S>>PS. А что тема с алго-сложностью
Здравствуйте, scf, Вы писали:
scf>и потоки на каждый запрос не создает.
Такой теоретический вопрос. Если все запросы в одном потоке — то что делать, когда клиент медленный и ответ не передается за 1 пакет. Т.е. вы передали 1 TCP-пакет, потом как бы ждете подтверждения вроде, передаете второй пакет. Не помню уже теорию — вроде можно замедлить однопоточные сервера такими медленными клиентами, причем даже спец. атака была такая.
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, reversecode, Вы писали:
R>>вы уже отправили пуш реквест в репу asio examples по поводу фиксов таких ляпов ?
S>Нет. И придерживаюсь мнения, что в примерах не нужно отвлекаться на такие тонкости.
и это ваше мнение масштабируется на все библиотеки ?
тот же boost в который входит asio, итд
Здравствуйте, reversecode, Вы писали:
R>>>вы уже отправили пуш реквест в репу asio examples по поводу фиксов таких ляпов ?
S>>Нет. И придерживаюсь мнения, что в примерах не нужно отвлекаться на такие тонкости.
R>и это ваше мнение масштабируется на все библиотеки ?
Мое мнение базируется на том, что код вида:
std::vector<std::thread> workers;
for(std::size_t i = 0; i != workers_count; ++i) {
workers.push_back(std::thread{ []{ do_something(); } });
}
...
for(auto & w : workers) {
w.join();
}
содержит грабли, не имеющие отношения ни к Asio, ни к какой-либо другой библиотеке. Соответственно, примеры, которые призваны демонстрировать особенности конкретных библиотек не обязаны содержать код для обхода этих граблей.
Надеюсь, что я ответил на ваш вопрос. И жду, что вы таки ответите на мой, который вы проигнорировали. Хотя понимаю, что шансов на вменяемый ответ в вашем случае небольшой.
Здравствуйте, Shmj, Вы писали:
S>Такой теоретический вопрос. Если все запросы в одном потоке — то что делать, когда клиент медленный и ответ не передается за 1 пакет. Т.е. вы передали 1 TCP-пакет, потом как бы ждете подтверждения вроде, передаете второй пакет. Не помню уже теорию — вроде можно замедлить однопоточные сервера такими медленными клиентами, причем даже спец. атака была такая.
Упрощая, там event loop. Когда из сети приходит пакет данных на конкретное соединение,в поток-обработчик отправляется событие ip/port/указатель на массив данных. Обработчик должен не блокировать поток, при необходимости делегировать работу в другой поток. Примерно как это сделано в UI.
не беспокойтесь, я думаю сотрудники компании рано или поздно прибегут
если там не постоянная текучка кадров
сейчас говорят очень распространен тренд игнорировать любые вак где есть тестовые задания
и по отзывам, кандидаты находят очень достойные и адекватные места работы
касательно ваших опенсорс
видел один из них пару лет назад в продуктах streamlabs
как по мне притянуто за уши как не нужный элемент
поэтому вопрос, это вы им навязали/сотрудничаете или это их мало проф подход втянул избыточный функционал ?
Здравствуйте, reversecode, Вы писали:
R>не беспокойтесь
Я не беспокоюсь, я объясняю тов.dwebster свою точку зрения.
R>сейчас говорят очень распространен тренд игнорировать любые вак где есть тестовые задания
ИМХО, на рынке каждый имеет право придерживаться собственной стратегии: работодатели имеют право предлагать тестовые задания, соискатели имеют право таких работодателей игнорировать (или не игнорировать). В конце-концов каждый находит то, что ищет.
Другое дело, когда чью-то стратегию начинают поливать известной субстанцией.
R>видел один из них пару лет назад в продуктах streamlabs
Первый раз о таких слышу.
R>как по мне притянуто за уши как не нужный элемент
Что хоть за опенсорс?
R>поэтому вопрос, это вы им навязали
Очень бы хотелось научиться навязывать кому-нибудь бесплатный опенсорс, но пока что таким навыком не обладаю.
Здравствуйте, so5team, Вы писали:
S>Вы специально это требование проигнорировали в обоих реализациях?
Вместо выплёскивания токсичности было бы неплохо показать свою реализацию ведь судя по тому, что вы говорите такой сервер пишется за 2-3 часа. Можно даже юнит-тесты не писать.
Здравствуйте, Kernan, Вы писали:
K>Вместо выплёскивания токсичности
Я задал dwebster два простых прямых вопроса. Один про игнорирование одного из трех ключевых условий тестового, второй по поводу версии Ubuntu. Ни на один из простых вопросов ответа не получил. И при этом я выплескиваю токсичность? ok.jpg.
K>было бы неплохо показать свою реализацию
У dwebster был понятный стимул тратить время на такую задачу. Какой стимул должен быть у меня?
K>ведь судя по тому, что вы говорите такой сервер пишется за 2-3 часа.
Давайте вы покажите где я такое говорил?
K>Можно даже юнит-тесты не писать.
Как раз на нормальные юнит-тесты для такой задачи запросто может уйти часа 4. А если в решении озадачиться еще и контролем тайм-аутов, то и раза в два больше.
Здравствуйте, so5team, Вы писали:
S>Я задал dwebster два простых прямых вопроса. Один про игнорирование одного из трех ключевых условий тестового, второй по поводу версии Ubuntu. Ни на один из простых вопросов ответа не получил. И при этом я выплескиваю токсичность? ok.jpg.
1. Как я несколько раз писал ранее — что успел сделать за время, которое готов потратить на одно тестовое задание одной компании, то и сделал.
2. Версия Убунту написана в условии, которое я цитировал, и которое вы судя по всему прочитали. Убунту 16, минорная версия не указана, значит неважна.
Спасибо за ответы. Хочу еще пару вопросов задать, без всякой задней мысли, просто для лучшего понимания.
D>1. Как я несколько раз писал ранее — что успел сделать за время, которое готов потратить на одно тестовое задание одной компании, то и сделал.
Т.е. вы стали делать задание не продумав заранее принцип обработки входящих данных? Выглядит это так, что сперва попытались сделать то, что понимаете, в расчете на то, что в оставшееся время доведете до ума.
D>2. Версия Убунту написана в условии, которое я цитировал, и которое вы судя по всему прочитали. Убунту 16, минорная версия не указана, значит неважна.
Тут непонятно, если в условии 16.04/10, то почему тогда в README упоминается 20.10? Все-таки там по дефолту gcc в Ubuntu 16 и 20 сильно разных версий, в старых gcc, вроде как нормальной поддержки C++17 не было (std::optional в C++17 в стандарт только вошел, а у вас он используется).
Здравствуйте, so5team, Вы писали:
S>Т.е. вы стали делать задание не продумав заранее принцип обработки входящих данных? Выглядит это так, что сперва попытались сделать то, что понимаете, в расчете на то, что в оставшееся время доведете до ума.
Всё так. Сначала сделал способом, наиболее понятным для себя и наиболее удобным для покрытия юнит-тестами. Без оптимизаций.
После чего понял что потратил неадекватно много времени и отослал, с некоторой надеждой что ответят что-то вроде — да, вы сделали не все что требовалось, но ладно уж, сойдет.
S>Тут непонятно, если в условии 16.04/10, то почему тогда в README упоминается 20.10? Все-таки там по дефолту gcc в Ubuntu 16 и 20 сильно разных версий, в старых gcc, вроде как нормальной поддержки C++17 не было (std::optional в C++17 в стандарт только вошел, а у вас он используется.
20.10 у меня стояла на компе. Сделал на ней, ожидая что на 16 всё так же взлетит без проблем.
Потом поставил 16 на виртуалку, увидел что не взлетело, но.. см. выше. В ответном письме написал, что сорри, 20.10 не устроит ли? Зачем под старый компилятор переделывать.
Здравствуйте, Shmj, Вы писали:
S>Такой теоретический вопрос. Если все запросы в одном потоке — то что делать, когда клиент медленный и ответ не передается за 1 пакет.
Автор тестового задания использовал асинхронное чтение из сокета. Там при получении каких-то данных, они попадают в некий буфер, и сигнал в мутекс. Пользовательский поток ждет мутекса в цикле. По срабатыванию мутекса, пользовательский код выгребает данные и идентификатор конекшена. Таким образом, на чтение/запись по всем соединениям используется 1 поток.
Здравствуйте, scf, Вы писали: scf>Попробуй открыть мою домашнюю страницу — https://scf37.me держит тысячи запросов в секунду, и потоки на каждый запрос не создает.
Раз уж мы начали соревноваться, то мой многопоточный вэб-сервер на чистом Си работает на такой аппаратуре: . Можно возразить, что зачем я выбрал устаревший одноядерный процессор на 180 МГц и всего 32 МБ ОЗУ? Свой вэб-сервер я смогу запустить на табло автомобиля, перерисовывая внешний вид экранов "на лету" по желанию пользователя в полноэкранном режиме Интернет-обозревателя. Никакая ГУЙ-рисовалка вроде "Кьюта" и прочих такое не сможет. Моё преимущество в независимой обработке данных чистым Си и гибкости отрисовки экранов Джаваскриптом во время работы устройства по желанию пользователя.
Здравствуйте, Pitirimov, Вы писали:
P>Раз уж мы начали соревноваться, то мой многопоточный вэб-сервер на чистом Си работает на такой аппаратуре: . Можно возразить, что зачем я выбрал устаревший одноядерный процессор на 180 МГц и всего 32 МБ ОЗУ? Свой вэб-сервер я смогу запустить на табло автомобиля, перерисовывая внешний вид экранов "на лету" по желанию пользователя в полноэкранном режиме Интернет-обозревателя. Никакая ГУЙ-рисовалка вроде "Кьюта" и прочих такое не сможет. Моё преимущество в независимой обработке данных чистым Си и гибкости отрисовки экранов Джаваскриптом во время работы устройства по желанию пользователя.
Сервера сравнивать бессмысленно, это другая лига по ресурсам и по функционалу. Расскажите лучше, какие браузерные движки работают в embedded?
Здравствуйте, scf, Вы писали: scf>Расскажите лучше, какие браузерные движки работают в embedded?
Я пока ещё выбираю Интернет-обозреватель для сборки из доступных: . Может быть, народ подскажет какой легковесный вэб-движок и обозреватель лучше выбрать с поддержкой HTML5 и Джаваскрипта.
Здравствуйте, ksandro, Вы писали:
K>А вот мне скорее нравится, когда тестовые задания дают на дом. По крайней мере у меня с ними обычно не возникает больших проблем.
Вот когда человеку 22-25 и нет никаких забот и увлекаешься только программированием, тогда да, это может приносить удовольствие, а как бонус еще и работу более лучшую найдешь
а когда при открытии резюме тебе за неделю прилетает 300-500 предложений, да еще есть семья с детьми и увлечения кроме программинга то тратить 3-4 вечера плотно сидя над одной задачей это уже непозволительная роскошь, слава богу времена когда на одно место претендовали 10 человек прошли и пока таких жертв чтобы заработать приносить не надо
Исключения конечно есть, если меня например будут звать на позицию с зп 1млн+ то наверно соглашусь, но такие конторы обычно такой ерундой не занимаются
а задачки когда желание есть можно порешать и так, без сроков и интервьеров над душой
Здравствуйте, a.v.v, Вы писали:
AVV>а когда при открытии резюме тебе за неделю прилетает 300-500 предложений, да еще есть семья с детьми и увлечения кроме программинга то тратить 3-4 вечера плотно сидя над одной задачей это уже непозволительная роскошь, слава богу времена когда на одно место претендовали 10 человек прошли и пока таких жертв чтобы заработать приносить не надо
Из этих "300-500 предложений" только 3-5 будут от известных компаний. Ну, тех компаний, наличие которых в резюме будет полезно в дальнейшем. В итоге весь поиск так или иначе сведётся к выбору из крайне небольшого количества вариантов и попыток туда попасть.
С сетями еще не очень плотно взаимодействовал. Недавно на select сделал сервер.
Там единственный сокет listener, который bind'ится и слушает. На него приходят подключения и с которого они accept'ятся.
Далее эти новые сокеты кладутся в набор, который кладём в select.
А здесь сразу создаются много сокетов. Все они listen и bind. Что это за подход такой? Объясните, пожалуйста.
Здравствуйте, AndrewJD, Вы писали:
AJD>Здравствуйте, Pitirimov, Вы писали:
P>>все ядра процессора будут загружены работой из-за независимой, многопоточной обработки запросов и кэши каждого из ядер процессора не будут вымываться, потому что каждое ядро процессора будет обрабатывать свой поток с нужными только этому потоку данными. AJD>Как гарантировать, что поток будет постоянно работать на одном и том же ядре? Руками выставлять thread affinity?
Плюс, если потоков > ядер, конечно же, будет постоянный context switch.
Здравствуйте, Pitirimov, Вы писали:
P>Образцовый сервер из книги писал лохопед и вот почему: если хотя бы в одном из входящих соединений со стороны пользователя начнут принимать данные очень медленно, скажем, по байту в секунду, то запросы других пользователей к серверу будут ждать обработки очень и очень долго.
poll выдал данному сокету, что пришли данные.
В цикле дошли до него. Вычитали сколько есть. Какое еще ожидание по 1му байту в секунду?
Пошли в цикле к другому сокету.
и т.д.
Затем снова в poll. https://www.ibm.com/docs/en/zos/2.4.0?topic=functions-read-read-from-file-socket Behavior for sockets: The read() call reads data on a socket with descriptor fs and stores it in a buffer. The read() all applies only to connected sockets. This call returns up to N bytes of data. If there are fewer bytes available than requested, the call returns the number currently available. If data is not available for the socket fs, and the socket is in blocking mode, the read() call blocks the caller until data arrives. If data is not available, and the socket is in nonblocking mode, read() returns a -1 and sets the error code to EWOULDBLOCK. See ioctl() — Control device or fcntl() — Control open file descriptors for a description of how to set nonblocking mode.
Здравствуйте, kaa.python, Вы писали:
KP>Из этих "300-500 предложений" только 3-5 будут от известных компаний. Ну, тех компаний, наличие которых в резюме будет полезно в дальнейшем. В итоге весь поиск так или иначе сведётся к выбору из крайне небольшого количества вариантов и попыток туда попасть.
я никогда не гонялся за строчками в резюме, и если под известными компаниями понимается FAANG, Яндекс и прочее такого же рода, то не надо
есть целая куча достаточно интересных проектов и без этих фабрик и зп более менее адекватные, так что выбор намного шире
Здравствуйте, avovana, Вы писали: A>poll выдал данному сокету, что пришли данные. A>В цикле дошли до него. Вычитали сколько есть. Какое еще ожидание по 1му байту в секунду? A>Пошли в цикле к другому сокету. A>и т.д. A>Затем снова в poll.
Даже если входящие данные быстро вычитали, то затем с этими данными что делать? Быстро выкинуть прочитанные данные и идти к следующим? Время обработки вычитанных данных одного пользователя будет задерживать обработку данных других пользователей. В многопоточном сервере каждый пользователь обрабатывается независимо в своём потоке, поэтому время обработки данных каждого пользователя будет меньше даже на одном процессорном ядре.
Здравствуйте, Pitirimov, Вы писали:
P>Даже если входящие данные быстро вычитали, то затем с этими данными что делать? Быстро выкинуть прочитанные данные и идти к следующим? Время обработки вычитанных данных одного пользователя будет задерживать обработку данных других пользователей. В многопоточном сервере каждый пользователь обрабатывается независимо в своём потоке, поэтому время обработки данных каждого пользователя будет меньше даже на одном процессорном ядре.
Здравствуйте, Pitirimov, Вы писали:
P>Даже если входящие данные быстро вычитали, то затем с этими данными что делать? Быстро выкинуть прочитанные данные и идти к следующим? Время обработки вычитанных данных одного пользователя будет задерживать обработку данных других пользователей. В многопоточном сервере каждый пользователь обрабатывается независимо в своём потоке, поэтому время обработки данных каждого пользователя будет меньше даже на одном процессорном ядре.
Здравствуйте, Pitirimov, Вы писали:
P>Даже если входящие данные быстро вычитали, то затем с этими данными что делать? Быстро выкинуть прочитанные данные и идти к следующим?
В исходной задаче нужно возвращать hash строки. Так что да, вычитали и выбросили. Усложнение с многопоточкой чревато потерями на синхронизации. Нужно замерять скорость, так с теории "будет быстрее"- неочевидно.
Здравствуйте, Тёмчик, Вы писали: Тё>В исходной задаче нужно возвращать hash строки. Так что да, вычитали и выбросили. Усложнение с многопоточкой чревато потерями на синхронизации. Нужно замерять скорость, так с теории "будет быстрее"- неочевидно.
Я исходил из предположения, что обработка входящих данных пользовательских запросов рано или поздно потребует медленного ввода-вывода с жёсткого диска или сети. А раз так, то во время ожидания ввода-вывода при обработке данных одного пользователя многопоточный код обрабатывает данные других пользователей, поэтому многопоточный сервер уверенно должен обогнать по времени обработки данных однопоточный, который будет тупо обрабатывать пользователей одного за одним. Замеров времени обработки данных я не проводил, так как мне всё ясно и без них.
Здравствуйте, Pitirimov, Вы писали:
P>Даже если входящие данные быстро вычитали, то затем с этими данными что делать? Быстро выкинуть прочитанные данные и идти к следующим? Время обработки вычитанных данных одного пользователя будет задерживать обработку данных других пользователей. В многопоточном сервере каждый пользователь обрабатывается независимо в своём потоке, поэтому время обработки данных каждого пользователя будет меньше даже на одном процессорном ядре.
Вот то что я выделил почти всегда плохая идея. Пул потоков — да, опция и часто хорошая, но вот по потоку на пользователя это вообще ни в какие ворота.
