Comments 23
И второй вопрос, просто по стилистике, а почему был сделан выбор в пользу генерации закоментированнх методов, а не, к примеру пустых методов или методов с panic(«not implemented»)?
Скажу сразу — не экспериментировал. Но, по логике, он сможет снизить время, только если в хипе значительное количество мусора. А если бОльшая часть памяти используется и мусора мало, то особой разницы быть не должно.
> И второй вопрос, просто по стилистике, а почему был сделан выбор в пользу генерации закоментированнх методов, а не, к примеру пустых методов или методов с panic(«not implemented»)?
Там в сигнатурах есть подстановки с $$, т. е. код в любом случае получится невалидный. Поэтому генерируем в закомментированном виде. Ну и, конечно, исторически сложилось :)
>Там в сигнатурах есть подстановки с $$, т. е. код в любом случае получится невалидный. Поэтому генерируем в закомментированном виде. Ну и, конечно, исторически сложилось :)
Ага, спасибо, просто у себя, обычно, предпочитаю генерировать код валидный и с паниками, но против исторически сложившихся фактов ничего не имею ;)
И, ещё бы хотелось полюбопытствовать в чём у вас пишут код =)
В принципе нам ничто не мешает стандартизировать и подстановки, но так как новые сервисы появляются не чаще раза в месяц в этом пока не было необходимости.
If the line ends with "(forced)", this GC was forced by a
runtime.GC() call and all phases are STW.
https://golang.org/pkg/runtime/
Раз в минуту PHP-клиент-сборщик статистики подключается к демону, запрашивает значения и сохраняет их в time-series-хранилище. На основе этих данных мы строим такие графики:
Какая причина(ы) использовать PHP для сбора статистики, а не писать в TS хранилище прямо из демона, или же другим Go демоном собирать ее вместо PHP? Просто любопытно.
LSD можно использовать в качестве примера демона, реализованного под нашу инфраструктуру. В нём используется большая часть того, что я описываю в статье.
Если сделать синтакс прото3, то надо в proto много чего поправить (убрать все optional, required, все enum начинаются с 0, нет дефолтных значений) и получается без указателей, действительно.
Но я в апи не вижу как понять задано поле или нет. Только сравнивать с нулевым значением?
Если PHP обслуживает все клиентские endpoint, значит общение клиентов с ним только по HTTP? Или для других протоколов, например websocket, демоны на PHP? Или же есть демоны для клиентов без PHP?
Эти демоны написаны очень давно на C. Go'шных, работающих напрямую с клиентами, — нет. По крайней мере пока :)
А мне вот как раз интересен вопрос на чём писать таких демонов в SOA-системе в целом написанной на PHP. Основных варианта три: PHP, Node.js и Go. В пользу PHP прежде всего консистентность стэка, но есть опасения по надежности. Для Go — компилируемость и статичность как причины низкого потребления ресурсов, деплой одним бинарником — бесплатный бонус, для Node — более простой переход с PHP (субъективно все пхпешнки джс худо-бедно знают). При том, что поддержка после первоначального написания таких демонов будет лишь дополнительной задачей для пхп-разработчиков, в обозримой перспективе даже одного разработчика только на демонов искать нет экономического смысла.
Вы рассматривали Node как альтернативу Go для демонов в системе, где упор на PHP? Если да, то только ли более низкое ресурсопотребление (по крайней мере в теории) сыграло решающее роль? Вопрос о том, демоны на каком из языков проще начать писать "стандартному" пехепешнику был важным при выборе?
99% кода на Go в Баду пишется в отделе C-разработки и задачи выбрать язык который был бы проще в изучении PHPшникам не стояло. Была цель выбрать язык который был бы достаточно эффективен (ближе к C чем к PHP), но при этом бы на нём было быстрее писать (основное, насколько я понимаю, чтобы был GC). Так что Node.js не подошёл нам по многим параметрам.
P.S. Моё личное мнение насчет Node.js — на нём даже проще написать плохо работающий код, чем на PHP.
Сервисы на Go: как мы их пишем и поддерживаем