Эффективность веб-серверов на Go?

Question

[Dima Zherebko]

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

Comments

[un1t]

Ты бы потрудился сформулировать вопрос. А с такой формулировкой ничего внятного тебе не ответят.

Answer 1

[abcyu]

Хорошая. Мне нравится.
Извините, что без цифр. Каков вопрос таков ответ.

Comments

[Dima Zherebko]

Спасибо )) цифры не помешалибы)))0

[abcyu]

G_tost:
5
Помогло?

А о чем вообще был вопрос - эффективность чего?
Создания, эксплуатации?
По сравнению с чем?
На каких проектах? Мелких, больших?
При какой квалификации разработчика? Начинающие, опытные?

[abcyu]

G_tost:
Для microservices вообще кайф

[Oleksiy Chechel]

G_tost а какие цифры нужны? Мой опыт - 2 дня изучения, 7 микросервисов за неделю, на go + gin-gonic + mgo. О небольшой нагрузке судить не могу, два сервиса нагружены до 7K запросов/сек. Много это или мало - вопрос относительный.

Answer 2

[Дмитрий Беляев]

Примерно на одном уровне с ngnix, а иногда даже быстрее, за счет отсутствия проксирования на бэкенд, так как у Вас в одном приложении и сервер и логика
Другой вопрос в том, на сколько оптимально Вы напишите Ваш код и умеете пользоваться Go, ибо даже на асме можно сделать тормоза, что php3+apache будет быстрее ползать

Comments

[un1t]

А как там решается проблема медленных клиентов?

[abcyu]

un1t: ставишь nginx спереди.

[un1t]

abcyu: А про что тогда комментарий об остуствии проксирования?

[abcyu]

un1t: проблема медленных клиентов решается только одним из двух методов - прокси (внешний или внутренний, я бы выбрал внешний, зачем писать велосивед) и раздувание количества открытых соединений (каждый web-запрос обрабатывается в своей параллельной или псевдопараллельной go-routine, ничего для этого делать не нужно).
go держит тысячи go-routine без заморочек. Но это затраты памяти.

[Дмитрий Беляев]

abcyu: стандартный пакет http и так создает горутину на каждый запрос, горутины работают ассинхронно и изменить это в отличии от js к счастью нельзя, тут принцип другой, при любом ассинхронном вызове горутина блокируется, но в это время на том же потоке могут выполняться другие горутины.
un1t: Любая программа выполняющаяся более чем в одной горутине будет ассинхронной, и, следовательно, наличие медленных клиентов как-то всеравно, каждый http запрос у нас в отдельной горутине из коробки

[abcyu]

Дмитрий Беляев: я описал именно стандартный метод. в go прекрасно из коробки работает. об этом и речь.

[un1t]

Дмитрий Беляев: спасибо, за разъяснения. Можеш за одно подсказать, какой менеджер зависимостей принятто использовать в Go?

[Дмитрий Беляев]

un1t: у Go в одной утилите и компилятор и пакет-менеджер и юнит тесты и много чего еще
зависимости прописываются непосредственно в исходниках в операторе import
если хотите распространять свое приложение в исходниках - пишите make файл для сборки
если распространяете пакеты, то go get вполне подтягивает зависимости самостоятельно

[un1t]

Дмитрий Беляев: Из коробки там какой-то геморой с пакетами, нельзя указывать версии пакетов и нужно прописывать GOPATH для каждого проекта. Мне понравился gb, но я не знаю насколько он общепринятый, может имеет смысл посмотреть на другой.

[abcyu]

un1t:
встроенный менеджер - качает всегда последние версии
я использую gb, просто и удобно и фиксировано.
начиная с 1.5 встроили какой-то функционал "vendor", еще не разбирался.

[abcyu]

un1t:
GOPATH она одна, а не для каждого пакета.
GOPATH указывает каталог где лежат исходники, и там же рядом будут лежать бинарники.
GOPATH может быть один на каждый отдельный проект, а может быть вообще одним на все твое рабочее место (ну тогда, вестимо, библиотеки будут все вместе лежать для всех проектов).
gb настолько помню сам эмулирует GOPATH, ничего делать не нужно.

[abcyu]

un1t:
насколько общепринят gb....
удобен, поэтому принят или не принят - неважно. если не требует чего-то специфического можно gb использовать

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

у тех. лида ни одного вопроса по компиляции проекта.

вопросы были только по функционалу.

все приняли, проверили и запустили в продакшн.
никаких проблем с использованием gb

[Oleg Shevelev]

По медленным соединениям вроде была тулза которая их генерирует и проверяет веб-сервер на прочность. Можно провести тесты nginx vs golang
По поводу gb, жаль что не пошли по пути git.
go init создавал бы каталог .golang и от него бы уже всё плесалось....