Pull to refresh

Comments 23

Спасибо за статью, было интересно. Подскажите, а принудительный вызов runtime.GC() перед вызовом runtime.ReadMemStat() не снижает время StopTheWorld?
И второй вопрос, просто по стилистике, а почему был сделан выбор в пользу генерации закоментированнх методов, а не, к примеру пустых методов или методов с panic(«not implemented»)?
> Спасибо за статью, было интересно. Подскажите, а принудительный вызов runtime.GC() перед вызовом runtime.ReadMemStat() не снижает время StopTheWorld?
Скажу сразу — не экспериментировал. Но, по логике, он сможет снизить время, только если в хипе значительное количество мусора. А если бОльшая часть памяти используется и мусора мало, то особой разницы быть не должно.

> И второй вопрос, просто по стилистике, а почему был сделан выбор в пользу генерации закоментированнх методов, а не, к примеру пустых методов или методов с panic(«not implemented»)?
Там в сигнатурах есть подстановки с $$, т. е. код в любом случае получится невалидный. Поэтому генерируем в закомментированном виде. Ну и, конечно, исторически сложилось :)
При большом потреблении памяти мусор всё равно будет, так что, в теории, должно тогда дать прирость, но вызов GC, насколько я помню, тоже вызывает stopTheWorld. Именно в этом моменте было интересно, будет ли в сумме две таких остановки мира быстрее, чем одна из-за runtime.ReadMemStat, по логике — да
>Там в сигнатурах есть подстановки с $$, т. е. код в любом случае получится невалидный. Поэтому генерируем в закомментированном виде. Ну и, конечно, исторически сложилось :)
Ага, спасибо, просто у себя, обычно, предпочитаю генерировать код валидный и с паниками, но против исторически сложившихся фактов ничего не имею ;)

И, ещё бы хотелось полюбопытствовать в чём у вас пишут код =)

В принципе нам ничто не мешает стандартизировать и подстановки, но так как новые сервисы появляются не чаще раза в месяц в этом пока не было необходимости.

Я писал всегда и все в Vim. Некоторое время пробовал VS Code. Он мне нравится, но там нет просмотра тегов. В остальном он классный. Ну и последний месяц я активно пробую Gogland. Gogland мощный и вкусный, но я пока не привык к таким монструозным IDE и учусь новым вещам очень медленно. Скорее всего я так и продолжу использовать Vim и Gogland.
Я пользуюсь плагином для IDE от jetBrains.
Его можно поставить, например, на phpStorm и будет удобно править одновременно Go- и PHP-код. Тоже самое можно сделать с другими IDE от jetBrainds — по ссылке написано, что он поддерживает.
Вызов runtime.GC() вызывает сборку мусора, которая целиком STW :-(
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? Просто любопытно.
Как я писал выше в статье, многие подходы мы изначально позаимствовали из того, что у нас уже было до Go. Это — как раз хороший пример.
Вероятно в будущем мы придём к схеме, когда не будет сборщика и демоны будут этим заниматься сами. Как это, например, уже сделано для отправки PINBA-статистики.
UFO just landed and posted this here
Он есть в open-source, например, как часть ранее нами открытого для сообщества LSD, исходный код которого есть на GitHub.
LSD можно использовать в качестве примера демона, реализованного под нашу инфраструктуру. В нём используется большая часть того, что я описываю в статье.
Стандартная реализация протобуферов 3 версии сохраняет поля без указателей.
Это очень интересно. Надо посмотреть как они понимают задано поле или нет. Там теоретически вариантов несколько. Например, использовать has_ поля булевые, как в protobuf-c или битовые поля.
Я попробовал собрать один из наших proto стандартным компилятором. Если собрать не указывая proto3, то ничего не поменялось. Указатели.

Если сделать синтакс прото3, то надо в proto много чего поправить (убрать все optional, required, все enum начинаются с 0, нет дефолтных значений) и получается без указателей, действительно.

Но я в апи не вижу как понять задано поле или нет. Только сравнивать с нулевым значением?
> Только сравнивать с нулевым значением?
Да, другого выхода нет. Приходится избегать ситуаций, когда int может быть задан 0, или не задан вообще.
Классная диаграмма. Мне одному показалось, что суслик и слоник не ровно дышат по отношению друг к другу? :)

Если PHP обслуживает все клиентские endpoint, значит общение клиентов с ним только по HTTP? Или для других протоколов, например websocket, демоны на PHP? Или же есть демоны для клиентов без PHP?

Вы всё верно подметили, именно о таких исключениях я и имел в виду в статье: у нас есть 2 демона, которые обслуживают длинные соединения от браузеров и нативных клиентов, позволяя отправлять им пуши.
Эти демоны написаны очень давно на 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.

Привет, я вот начал активно использовать Crystal, где возможно :)

На схеме php выглядит как узкое горлышко в бутылке. Так ли оно на самом деле не берусь судить конечно.

Если рисовать пропорционально все площадки и подкластера инфраструктуры Баду — на экран не влезет :-)

Sign up to leave a comment.

Articles