Pull to refresh

Comments 6

Спасибо, познавательно. Хотелось бы еще узнать, какое место автор отводит функциональности arena из go 1.20, казалось бы идеальный вариант для приложений со сложным и непредсказуемым использованием памяти. Или это все еще считается go разработчиками экспериментальным и неблагонадёжным функционалом?

Arena интересная фишка. Мы в своих сервисах уже перешли на 1.20, но пока Arena не трогали. У нас есть договоренность не использовать фичу ради фичи. Но если будет такая задача, где без Arena не обойтись (ну или докажем, что это целесообразно), то возьмем попробовать :) Тем более очень интересно поработать в реальных условиях.

А как стать голанг девелопером? С питона начать пойдёт? Изучаю питон, но там завис в теме с гринлетами, gevent, eventlets, stackless python, корутины. Нагляной картинки нет нигде, где бы описание было. Стэковерфлоу зачитал уже, то на perl какая-то лекция попалась с библиотекой coro. Везде по крупицам всё. Термины тоже везде свои и сбивают с толку. Прихожу к выводу, что в Си и pthreads надо вникать. Литературу бы какую, а её тоже тонны всякой разной.

Я считаю, что лучше способ изучить язык - это реализовать какой-то пет-проект :)

Я начинала с телеграмм бота, который сообщал мне о том, когда будет прилив или отлив на том или ином пляже (я тогда как раз жила у моря, когда начала изучать язык). Кстати, до этого тоже писала на питоне.

Столкнулся с такой проблемой, go изучал самостоятельно и, возможно, что-то упустил.
Есть высоконагруженный сервис, раньше работал в качестве источника данных с Redis, но начались просадки на общении с базой. Была сделана доработка in memory DB внутри сервиса, 30 гигов в оперативке. Скорость стала приемлемой, но есть пики, которые возникают в момент работы GC. Можно ли как-то решить данную проблему, сомневаюсь, что у меня получится уменьшить количество данных в куче, ну если извернусь, то процентов на 5-10 не больше. Может можно как-то выделить пару ядер на GC) Или данная задача в принципе не решается на данном стеке.

Working mode Requests per sec 100 Working time sec 300
Requests sent 30000 Requests loss 0 loss in percent 0.00%

Histogram map[100:29895 200:100 300:5]
Request Avg Answer Duration 3.703623ms
Request Min Answer Duration 1.18272ms
Request Max Answer Duration 207.433021ms

Sign up to leave a comment.

Articles