Крайне желательно раз в несколько месяцев делать руками полный цикл изменения кода. Обычно это выглядит так:
Взять в спринте маленькую задачу на час-другой работы...
Вы не могли бы привести пример использования такого подхода, в котором были выявлены и идентифицированы пробелы в дизайне?
Этот пункт был выведен эмпирическим путем, когда мы поняли, что инсталляция Kafka больше, чем на 12 Тб на единицу кластера драматически рушит производительность.
ISO 81346-12:2018 — Part 12: Construction works and building services
Из этого стандарта я выше привел цитату. Цитата ссылается на 81346‑1:2009 и по смыслу соответствует отечественной верии. Т.е. на 2018 год ничего не изменилось.
Хотя есть четкие стандарты (например ISO 81346) которые определяют их. Если вы будете гуглить, то зачастую схема компонентов может называться схема модулей, а схема модулей — схемой компонентов.
Поискав, я обнаружил отечественный ГОСТ Р 58908.1-2020, который видимо, аналог IEC 81346-1:2009. Там пишут так:
3.6 продукт (product): Предполагаемый или достигнутый результат труда, естественного или искусственного процесса.
3.7 компонент (component): Продукт (изделие), используемый в качестве составной части собранного продукта (изделия), системы или установки.
WASM-модули относительно легко контролировать по использованию CPU и памяти, чего не скажешь про Java. Варианты есть, но они, будем так говорить, не для всех и experimental.
НО разработчики используют TinyGo, в котором сборщик мусора попроще и запускается когда недостаточно места в куче. Если между вызовом proxy_on_memory_allocate и моментом возврата владения в Go нет выделения памяти, то это условно безопасно.
Можно пример, как конкретно выглядит опасный сценарий при использовании go-pointer?
Не уловил, каким образом proxy_on_memory_allocate "превращается" для AssemblyScript
в:
/// Allow host to allocate memory.
export function malloc(size: i32): usize {
let buffer = new ArrayBuffer(size);
let ptr = changetype<usize>(buffer);
return __pin(ptr);
}
?
PS: Видимо, так:
На стороне хоста выполняется поиск malloc, если нет, то ищется proxy_on_memory_allocate
> Примерно 75 тыс. самокатов отправляют сообщения на сервер в среднем раз в минуту. Во время движения частота обращений составляет один раз в 1–5 секунд.
Интересно было бы послушать про «железо», которое стоит за этим — сколько и каких серверов и т.д. Расскажите, по возможности :)
Татьяна, а можно поподробнее узнать про параметры нагрузки системы — соотношение запросов чтение/запись, типичное время ответа, производительность (rps)?
Спасибо за статью, поучительно. А как API описывается, например, вот это?
Тоже через Hugo?
Вы не могли бы привести пример использования такого подхода, в котором были выявлены и идентифицированы пробелы в дизайне?
Да, Вы правы
В условиях первой задачи вместо "только один вопрос только одному из них" следовало бы написать «только по одному вопросу каждому из них»
А какое "железо" используется, на котором "реляционные БД" и Rabbit не способны обеспечить 15 тысяч RPS?
Можно пояснить, что такое "единица кластера"?
Из этого стандарта я выше привел цитату. Цитата ссылается на 81346‑1:2009 и по смыслу соответствует отечественной верии. Т.е. на 2018 год ничего не изменилось.
Хорошо, вот на "языке оригинала":
Интересная статья, спасибо. Вот такой момент:
Поискав, я обнаружил отечественный ГОСТ Р 58908.1-2020, который видимо, аналог IEC 81346-1:2009. Там пишут так:
WASM-модули относительно легко контролировать по использованию CPU и памяти, чего не скажешь про Java. Варианты есть, но они, будем так говорить, не для всех и experimental.
Можно пример, как конкретно выглядит опасный сценарий при использовании go-pointer?
Не уловил, каким образом
proxy_on_memory_allocate"превращается" для AssemblyScriptв:
?
PS: Видимо, так:
Интересно было бы послушать про «железо», которое стоит за этим — сколько и каких серверов и т.д. Расскажите, по возможности :)
Да, есть такой момент — если надо из программы на Go «выжать» максимум, то надо много читать.
2431 ops - как-то маловато. Да ещё и latency 9.8, странно. А каков общий размер записи, примерно?
Татьяна, а можно поподробнее узнать про параметры нагрузки системы — соотношение запросов чтение/запись, типичное время ответа, производительность (rps)?
Интересный вариант. Попробовал так:
go run -gcflags="-l=4 -m -m" concgo.go s > o 2>&1oпишут:is_convergentне во "вложенности", а в "сложности"?-l=4можно использовать "в бою"?В таких вопросах очень полезны базовые познания как в ассемблере так и в технологиях получения этого ассемблера из исходников.
Сибираюсь "черкнуть" пару статей про обобщенные типы в Go, там этот вопрос будет рассматриваться.
Добавил разделители для удобства. Хотя это уже "подделка данных".
Интересно, а почему не использовать терминологию Microsoft?