есесна обстреливать их равномерно

не уловил мысль, чем это может помочь?

Предположение, что может быть дело в какой-то пропускной способности. Но 8мб это немного

Что если не запускать процессинг получается?

Если не запускать, то там порядка 250MB/s

Мне больше нравится такая схема: стартуем n воркеров, 1 сохраняльщик. Хэндлер отправляет в буферизованный канал, воркеры парсят передают сохраняльщику через канал или мьютекс + слайс, сохраняльщик сбрасывает в базу раз m секунд или когда набралось k записей. Таким образом нет лишних переключений контекста, естественный троллинг: и со стороны ЦПУ, и когда в базу всё упирается

Грейсфул шатдаун опять же наладить легче будет

Мне больше нравится такая схема: стартуем n воркеров, 1 сохраняльщик. Хэндлер отправляет в буферизованный канал, воркеры парсят передают сохраняльщику через канал или мьютекс + слайс, сохраняльщик сбрасывает в базу раз m секунд или когда набралось k записей. Таким образом нет лишних переключений контекста, естественный троллинг: и со стороны ЦПУ, и когда в базу всё упирается

Ну и запись в базу пачками быстрее гораздо

А разве в такой схеме узким местом не станет кол-во обраьотчиков разгребающих канал? Нагрузка входящего трафика сильно влияет на необходимое кол-во обработчиков.

Но их же всё равно сильно больше кол-ва тредов нет смысла держать

В целом да, согласен.

Спасибо.

Добрый вечер. Пытаюсь разобраться в следующем поведении: есть http handler, он читает тело запроса, стартует goroutine(не дожидается ее завершения) и возвращает 200. И вот тут начинается следующее поведение: чем больше работы делает горутина (зависит от объема тела запроса), тем меньше RPS держит сервер. В случае небольшого тела запроса - 5к rps, в случае с большим телом запроса - 400 rps. При этом нагрузка на цп выше при большем RPS при малых запросах. По какой причине горутины оказывают такое влияние на RPS? (мое предположение заключается в том более долгая работа горутин дольше держит контекст без переключения, тем самым блокируя возможности на прием новых соединений, однако это не помогает понять как эту ситуацию решить чтобы получить похожую производительность в обоих кейсах)

Ничего не понятно, но очень интересно(c). А метод обработчика сразу же завершается после ответа 200? Какие ресурсы вообще доступны приложению? Если вместо рассчетов/сохранения в базу time.Sleep() впихнуть, ситуация меняется? Если проблема решилась, то что было?

А мне интересно, как происходит понимание по ограничению rps? Перестает отдавать 200? Отдает с задержкой?

скорее всего есть определенный максимальный лимит по запросам

но я не уверен

А мне интересно, как происходит понимание по ограничению rps? Перестает отдавать 200? Отдает с задержкой?

Возвращает 429 (Too many requests) Upd: Не читал вопрос особо и ветку, понял что ответ не в тему.

может кто помочь? пишу рест апи. Все было норм до тех пор, пока не начал юзать бд Запускаю сервак -> (https://go.dev/play/p/brQdmUcYx0s -- тут подключение к бд, хендлеры, запуск сервака). Все норм к бд коннектится. Вот сам рест -> (https://go.dev/play/p/sb-J_Sbnv5Y). Повторюсь, игрался со слайсами все было прекрасно. Гет, пост, пут, делете методы работали отлично. Сейчас же когда запускаю бд (коннект происходит), но почему-то не могу взять данные из бд. Сперва подумал, что все дело в бд(была postgresql) свичнул на sqlite3, но не помогло Вот что принтит: http: panic serving 127.0.0.1:47678: runtime error: invalid memory address or nil pointer dereference <- (ошибка на стороне сервера) curl: (52) Empty reply from server <- когда делаю гет запрос. Мне кажется, что rows - пустые. Если кто сталкивался помогите пж

http: panic serving 127.0.0.1:47678: runtime error: invalid memory address or nil pointer dereference <- (ошибка на стороне сервера) строчка какая?

это вроде не в моем файле даже

это вроде не в моем файле даже

сейчас уже не скажу, но это точно

Как создать приложение на Go с gRPC https://nuancesprog.ru/p/14627/ @Golang_google

http: panic serving 127.0.0.1:47678: runtime error: invalid memory address or nil pointer dereference <- (ошибка на стороне сервера) строчка какая?

r не аллоцированна в цикле rows.next. поэтому и null. Только тип указан, но память не выделенна. Сделай r = Result{}

r *http.Request => r Result = r redeclared in this block

Привычка делать короткие нечитабельные имена переменных она такая...

Привычка делать короткие нечитабельные имена переменных она такая...

Тоже раздражает такой подход, экономия на буквах, как будто зашёл почитать сишный код ядра линукса

Так принято в языке

Тоже раздражает такой подход, экономия на буквах, как будто зашёл почитать сишный код ядра линукса

objective c - пример обратной крайности. [obj letMeDoSmthStrangeWithThisObjectAndWaitAndSmth]

Так принято в языке

То что так написана стандартная библиотека вовсе не означает, что нужно повторять этот подход. Есть очевидные разумные кейсы, когда однобуквенная переменная допустима, но не стоит этим злоупотреблять. Тем более что многих типов данных есть свои устоявшиеся и понятные сокращения не из одной буквы: req, resp, arr, str , err и т.д. Для своих же типов стоит делать чуть более длинные (двухсловные), но более осмысленные имена. И, естественно, не нужно впадать в обратную крайность слишком длинных именований переменных, которые только усложняют чтение.

А мне интересно, как происходит понимание по ограничению rps? Перестает отдавать 200? Отдает с задержкой?

тут все просто, я просто гоняю нагрузку и смотрю сколько rps показывает утилита.

тут все просто, я просто гоняю нагрузку и смотрю сколько rps показывает утилита.

Нагрузка запускается на той же машине?

Ничего не понятно, но очень интересно(c). А метод обработчика сразу же завершается после ответа 200? Какие ресурсы вообще доступны приложению? Если вместо рассчетов/сохранения в базу time.Sleep() впихнуть, ситуация меняется? Если проблема решилась, то что было?

метод обработчика завершается сразу. вопрос про ресурсы не понятен. Пока ресурсы моей локальной машины.

Нагрузка запускается на той же машине?

как писал вчера в треде - да, я понимаю что это не чисто. Но не думаю что это дает большой эффект в этом случае.

как писал вчера в треде - да, я понимаю что это не чисто. Но не думаю что это дает большой эффект в этом случае.

Мне кажется, если разница в заголовках, то проблема именно в том, что систему тормозит именно утилита тестирования.

Я же правильно понимаю, запускается это на "самой дешевой виртуалке".

Мне кажется, если разница в заголовках, то проблема именно в том, что систему тормозит именно утилита тестирования.

разница не заголовках, а в объеме тела post запроса. Еще раз опишу, есть хэндлер, он принимает запрос, вычитывает тело запроса (x-www-form-urlencoded форма) и потом запускает горутину которая перегоняет тело запроса в json, сохраняет результат в базу ну и еще плюет в кролик. Сразу после запуска горутины хэндлер отдает 200 и завершается.

Я же правильно понимаю, запускается это на "самой дешевой виртуалке".

запускается это на самом обычном macbook pro на i9 ) но я не думаю что это на что-то влияет. так как тест при малом и большом тело запроса запускается на одной машине в равных условиях

запускается это на самом обычном macbook pro на i9 ) но я не думаю что это на что-то влияет. так как тест при малом и большом тело запроса запускается на одной машине в равных условиях

Меня смущает i9 и 200 rps

Меня смущает i9 и 200 rps

я не писал ничего про 200 rps, при малом теле запроса там порядка 6к rps, при болшом 500 rps. Но разница очевидна.

Меня смущает i9 и 200 rps

Да, там было 400, но не важно.

Объём записи в бд одинаковый (и он тоже на этой же машине)

одного вредителя этого процесса я вычислил (я использую gorm. он писал в лог запросы на вставку которые гонял, чем больше данных - тем больше вывод в консоль), стало получше. теперь 2к rps при большом теле. + улучшил ситуацию с лишними аллокациями памяти.

одного вредителя этого процесса я вычислил (я использую gorm. он писал в лог запросы на вставку которые гонял, чем больше данных - тем больше вывод в консоль), стало получше. теперь 2к rps при большом теле. + улучшил ситуацию с лишними аллокациями памяти.

вывод в консоль тормозит еще как

r не аллоцированна в цикле rows.next. поэтому и null. Только тип указан, но память не выделенна. Сделай r = Result{}

эм, а как? r(http.req) reuslt(структура) как я могу r присвоить result?

эм, а как? r(http.req) reuslt(структура) как я могу r присвоить result?

Не, выше написали про наименование. Дамп ошибки пришлите.

так я уже кидал сверху

самое забавное, гет запрос добирается до ф-ции которая ему нужна и дальше все

дебагать надо или что?

????

так я же объявляю переменные

ААААААААААААААААААААААААААА

ну я колбаса

точнякккк

неплохо

не используй статические переменные

что называется

да че вы мужики((((((

я думал, что так будет лучше

спас себя от дубликата кода

а в итоге сам себя запутал

а для чего это?

type Handler interface { ServeHTTP(ResponseWriter, *Request) }

так типо?

все заработало

день тупа в монитор втыкал))

спасибо

я не умею

подожди, то есть ты умеешь grpc, но любишь глобальные переменные и не умеешь дебажить? не в обиду. но прям слом мозга

да

получается hr'ы смотрящие на ключевики ошибаются на 146% процентов

а есть годное про дебаг?

не поздно же научиться

я дебажил только на си, юзая gdb

Всегда с пренебрежением смотрел на эти ваши встроенные дебаги, принтлн наше все

как в го это делается понятия не имею

ну вот да

я через принтлн делал

лол, дебагнул через delve брейкнул файл с конектом, просто писал continue, пока не дошел до коннекта к бд и там была ошибка

прикольно

а как? расширение установить?

мне понравилось