Ilya
А само поле хранить другой таблицей?
Vitaly
Тут надо уже на саму задачу смотреть
Alexander
у тебя много инстансов приложения или они часто дохнут?
Ilya
у тебя много инстансов приложения или они часто дохнут?
Один, дохнуть не будут, но результат я просто записываю в файл и поэтому сам кеш не нужен.
Alexander
тогда sync.Map
🅞leksiy
Alexander
я вангую привычка из питона или пхп
🅞leksiy
я вангую привычка из питона или пхп
Та да, я как на ноду с php перешёл, просто тащился от того, что можно временные данные просто в переменной хранить, а не в мемкеше или редисе. Как давно это было... 😂
Ilya
тогда sync.Map
Да, спасибо, прочитал, точно подходит.
Ilya
И как второй вариант, если они удалённые?
Ilya
Я думаю мне нужно время, чтобы задать правильный вопрос ___ Всем спасибо за участие.
Vitaly
Есть такая штука с исходниками: https://habr.com/ru/post/359078/
Эта штука подходит, если данные должны ограничиваться по lifetime
Alexander
А что делать если много инстансов?
тогда имеет смысл о едином кэше задуматься
Anonymous
если на хх ру резюме посмотрели, но не ответили
Anonymous
каковы шансы, что меня не взяли
Emil
Сотка?
Emil
Просто Довольно странное поведение в обратном случае А может ещё не успели ответить
Anonymous
обидно
Anonymous
да
Herman
Главное их запомни
Herman
И через пару лет игнорь рекрутера
Herman
Когда они уже будут заинтересованы в тебе
Сергей
если на хх ру резюме посмотрели, но не ответили
В день шли резюме в 2-3 компании. В разные. Когда наконец-то возьмут, резюме не удаляй, а только дописывай навыки, которые приобрёл. Без привираний, но ярко. Через примерно год, первые тебе позвонят с предложением и тут уже козыри у тебя. А сейчас да, они просто просто тебя случайным образом отсеяли. Если после тридцатого раза никто не ответит, меняй резюме на более лояльное-агрессивное. Как змея охотится на добычу. Но главное никогда не привирай! Всегда есть куча работодателей, которые делают ставки на молодых. Ну и дополнительно: никогда никого не игнорь, потому что только так сможешь увидеть их слабость и получить прививку от встречи с подобными
Anonymous
спасибо всем за советы ;)
Anonymous
но я и вправду не понимаю в чем проблема просто ответить)))
Anonymous
почему я должен сидеть и обновлять пейдж в надежде, что они ответят)))
Herman
почему я должен сидеть и обновлять пейдж в надежде, что они ответят)))
Иногда (редко) бывает, что рекрутер не может принять решение сам, отбирает подходящие по ключевым словам, показывает кому-то ещё, потом уже отвечает
Herman
А иногда (часто) просто насрать
Anonymous
ни больше, ни меньше
Anonymous
да, я это понимаю
Anonymous
мне пох
Anonymous
не взяли и не взяли
Anonymous
по пивку и спать
Anonymous
:)
Сергей
но я и вправду не понимаю в чем проблема просто ответить)))
Либо стыдно, либо нет желания и времени. Никто никогда не извиняется перед раздавленным муравьём. (очень грубо)
Сергей
по пивку и спать
Пиво отбрось. Когда есть хоть малая проблема, никакого пива. Поверь старому алкоголику... 🤣🤣🤣
Anonymous
не пью
Anonymous
только кофе или чай
Emil
Энергетики и кофеин из аптеки
Anonymous
раздавленный муравей
Сергей
только кофе или чай
С утра встал, посмотрел на резюме глазами Джима Керри, переписал и так и эдак, разослал всем и пофиг. Главное не врать даже в мелочах! Можно только приукрашивать! Если хочешь, в понедельник я прочитаю твоё резюме и скажу почему не посмотрели на хх его. Без смеха и строго по пунктам!
Anonymous
нет опыта работы(год)
Anonymous
я был бы не против услышать критику, спасибо
Сергей
нет опыта работы(год)
Вот это самая последняя отмазка
Олег
Добрый вечер. Пытаюсь разобраться в следующем поведении: есть http handler, он читает тело запроса, стартует goroutine(не дожидается ее завершения) и возвращает 200. И вот тут начинается следующее поведение: чем больше работы делает горутина (зависит от объема тела запроса), тем меньше RPS держит сервер. В случае небольшого тела запроса - 5к rps, в случае с большим телом запроса - 400 rps. При этом нагрузка на цп выше при большем RPS при малых запросах. По какой причине горутины оказывают такое влияние на RPS? (мое предположение заключается в том более долгая работа горутин дольше держит контекст без переключения, тем самым блокируя возможности на прием новых соединений, однако это не помогает понять как эту ситуацию решить чтобы получить похожую производительность в обоих кейсах)
Alexander
Добрый вечер. Пытаюсь разобраться в следующем поведении: есть http handler, он читает тело запроса, стартует goroutine(не дожидается ее завершения) и возвращает 200. И вот тут начинается следующее поведение: чем больше работы делает горутина (зависит от объема тела запроса), тем меньше RPS держит сервер. В случае небольшого тела запроса - 5к rps, в случае с большим телом запроса - 400 rps. При этом нагрузка на цп выше при большем RPS при малых запросах. По какой причине горутины оказывают такое влияние на RPS? (мое предположение заключается в том более долгая работа горутин дольше держит контекст без переключения, тем самым блокируя возможности на прием новых соединений, однако это не помогает понять как эту ситуацию решить чтобы получить похожую производительность в обоих кейсах)
что делают горутины? математику считают? если все-таки есть ввод вывод, каналы, то переключение контекста происходит
Alexander
должно происходить
Alexander
запрофилируй
Alexander
https://pkg.go.dev/net/http/pprof
Alexander
там в основе математика.
есть какая-то штука вроде "дай время другой горутине"
Олег
точнее не так, отличие между мелким запросом и большим в математике, дальнеиший ввод/вывод отдинаково отрабатывает для этих объемов
Alexander
но опять же, если ты будешь принимать запросы раньше, чем можешь решить вычисления, то просто оперативку всю выжрешь
Alexander
я бы лучше разнес такое: система очередей (да хоть в СУБД обычной) и воркеры отдельными процессам/и
Олег
я бы лучше разнес такое: система очередей (да хоть в СУБД обычной) и воркеры отдельными процессам/и
там вся "математика" - это преобразование x-www-form-urlencoded запрос во вложенные map[string]interface{} (там куча аллокаций) чтобы потом это перегнать в json. Можно конечно это через очереди делать (класть тело post запроса туда), но пока хотелось бы попробовать порешать менее радикально.
Alexander
https://pkg.go.dev/net/http/pprof
но это в первую очередь. без понимания что творится внутри нет смысла что-то гадать
Олег
https://go.dev/pkg/runtime/?m=old#Gosched
Gosched я пробовал) Но это выглядит как-то совсем костылем. да и не дало хорошего эффекта.
Alexander
вообще непонятно выглядит: если оно не успевает принимать из-за того, что проца не хватает, то значит он должен быть забит процессингом. а процессингом он не забит. хэндлер пишет в базу? процессинг пишет в базу?
Олег
по памяти не изучал, но там явно не что-то колоссальное)
Alexander
ну или проще: много мелких 90% проца, мало больших 85% проца
Alexander
чем кстати бомбишь?
Олег
чем кстати бомбишь?
не понял вопроса...
Олег
ну или проще: много мелких 90% проца, мало больших 85% проца
много мелких съедают значительно больше проца, раза в 2 больше
Alexander
ну приложение какое используешь или сам написал, если так, то какую либу
Alexander
с какого компа обстрел происходит
Олег
с какого компа обстрел происходит
все локально. не чисто конечно. Но не думаю что в этом проблема.
Олег
для нагрузки использую plow
Alexander
а сколько в секунду передается примерно данных в случае больших боди?
Alexander
что если попробовать биндится на несколько айпишников(127.0.0.1-255) или портов?
Alexander
есесна обстреливать их равномерно