boltdb - известный тормоз, особенно на запись

Зато на чтение - нитро.

boltdb - известный тормоз, особенно на запись

В моём проде записи довольно редко случаются

и все данные в память влезли, небойсь

тогда да, будет быстро

Быстро, конечно, но задолбаешься конвертировать данные в байты и обратно

обвязки всякие есть, для улучшайзинга и удобства. еще форк какой-то был, с новыми фичами

Кто-нибудь собирается на 2018.codefest.ru ?

https://2018.codefest.ru/

и все данные в память влезли, небойсь

Даже если не влезли, btree пока-что самый быстрый способ искать данные на диске, и все lsm адепты это признают. (Ок, может и есть более лучшие способы, но они гораздо менее популярны чем btree и lsm). Правда, при определенных условиях итерация по lsm может быть быстрее, это правда.

если не влезли - будет как у всех

и дженерики

round же дали в 1.10 по просьбам трудящихся, глядишь и дж..в подкинут

boltdb же

sqlite же если не хочешь в постгрес

то ли я тупой, то ли гвозди, но с boltdb почему то всегда всё, кроме самого простого, получается на много хуже, чем с любым SQL - и тормозит, и говнокода много

это не болт, это KV такие

да, конечно

Кстати интересно, а что если бы автор той статьи попробовал azul с профилем оптимизации

у автора статьи цель другая была

boltdb - известный тормоз, особенно на запись

А кто не тормоз?

А кто не тормоз?

газ?

Хито?

А кто не тормоз?

/dev/null. Я сам офигел - скорость записи упирается в скорость чтения из любого источника!

у автора статьи цель другая была

это был наброс за бесовский Го против православной Скалы. ни кто в этом не сомневается

А кто не тормоз?

badgerdb

Я просто токен oauth2 сервер сделал. И он на boltdb. Но пока не пробовал в проде

для твоих целей оно ок

ipfs годная штука, мы как раз сейчас ее интегрируем в наш проект

Как интегрируете?

Всем привет. 2 Вопроса тем, кто использует vscode. Использую тэги в го "-tags". 1. Как сделать так чтобы отладчик запускался с определёнными тэгами? С компиляцией проблем нет. таски настроил. Что надо пропистаь в launch.json? Мне надо дебаггером по тесту пройтись. { "version": "0.2.0", "configurations": [ { "name": "Launch", "type": "go", "request": "launch", "mode": "test", "remotePath": "", "port": 2345, "host": "127.0.0.1", "program": "${workspaceRoot}", "env": {}, "args": [], "showLog": true } ] } 2. Как сделать чтобы линтер теги видел?

Как интегрируете?

форкаем и используем только нужное

стартуем ноду без http апи и тд

коллеги, есть несколько воркеров, получающих задания из продьюсера, который кидает задания в канал. Внутри воркера получаю задания вот таким манером: for { select { case task := <-crawler.tasks: // chan *Task log.Printf("Task: %v", task) crawler.handleTask(task) case <-crawler.workersStop: return } } сейчас наблюдаю как из канала приходит сначала нормальный Task, а в другом воркере nil, причем продьюсер отправил в канал только первый таск. Это какая-то гонка?

коллеги, есть несколько воркеров, получающих задания из продьюсера, который кидает задания в канал. Внутри воркера получаю задания вот таким манером: for { select { case task := <-crawler.tasks: // chan *Task log.Printf("Task: %v", task) crawler.handleTask(task) case <-crawler.workersStop: return } } сейчас наблюдаю как из канала приходит сначала нормальный Task, а в другом воркере nil, причем продьюсер отправил в канал только первый таск. Это какая-то гонка?

каналы потокобезопасны, ищите ошибку в коде отправки сообщения

badgerdb

Пока багнутый. Ну и, честно подразумевает, что у вас ssd. В том смысле, что значения больше порога не хранятся в lsm, а значит, скорее всего, итерация обернётся рандом-ридом. Тот же boltdb кладёт значения in-place, и итерация будет быстрее. Но вот мне потребовалось перелопатить 800GB данных, взял амазоновский инстанс с быстрым nvme, отключил fsync, и job done. Thank you, badgerdb.

каналы потокобезопасны, ищите ошибку в коде отправки сообщения

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

Пока багнутый. Ну и, честно подразумевает, что у вас ssd. В том смысле, что значения больше порога не хранятся в lsm, а значит, скорее всего, итерация обернётся рандом-ридом. Тот же boltdb кладёт значения in-place, и итерация будет быстрее. Но вот мне потребовалось перелопатить 800GB данных, взял амазоновский инстанс с быстрым nvme, отключил fsync, и job done. Thank you, badgerdb.

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

task.Status = taskStatusInProcess crawler.tasks <- task причем такой код исключает что в канал попадет nil.

task.Status = taskStatusInProcess crawler.tasks <- task причем такой код исключает что в канал попадет nil.

и как такой код что то может исключать?

и как такой код что то может исключать?

там кстати, вот так лучше go crawler.handleTask(task)

task.Status = taskStatusInProcess crawler.tasks <- task причем такой код исключает что в канал попадет nil.

Может быть закрыли канал? Скиньте в плэйграунд.

там кстати, вот так лучше go crawler.handleTask(task)

он уже внутри отдельной горутины получает задачу, зачем еще одну плодить?

и как такой код что то может исключать?

обращение к task.Status - запаникует ели там nil (но на самом деле чуть выше task явно создается)

там кстати, вот так лучше go crawler.handleTask(task)

это у меня уже внутри отдельной горутины-воркера

потому что этот task crawler.handleTask(task) заблокирует цикл а если там сотня сразу свалится запросов?

обращение к task.Status - запаникует ели там nil (но на самом деле чуть выше task явно создается)

скиньте ключевые участки в goplayground, пока что это гадание на гуще

потому что этот task crawler.handleTask(task) заблокирует цикл а если там сотня сразу свалится запросов?

прежде чем давать советы следует хотя бы прочитать предыдущие сообщения...

Может быть закрыли канал? Скиньте в плэйграунд.

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

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

да, будет nil

потому что этот task crawler.handleTask(task) заблокирует цикл а если там сотня сразу свалится запросов?

это продьюсер разруливает.

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

можно проверять закрыт ли канал через конструкцию case task, ok := <-crawler.tasks: // chan *Task

если ok == false, то канал уже был закрыт

если ok == false, то канал уже был закрыт

точно, канал закрыт. спасибо. дальше разберусь

это у меня уже внутри отдельной горутины-воркера

всё равно лучше запускать handleTask в отдельной горутине, чтобы цикл for перешёл к следующей итерации по возможности быстрее

всё равно лучше запускать handleTask в отдельной горутине, чтобы цикл for перешёл к следующей итерации по возможности быстрее

Но мне это как раз не нужно. У меня n воркеров выполняют n заданий. Выполнил - приступил к следующему.

а

а канал с какой целью закрываете?

Клевый канал, лучший в телеграмме по Go, не надо закрывать

ор

Хех

Кто-нибудь поедет на codefest?

а канал с какой целью закрываете?

Канал закрываю после закрытия воркеров при шатдауне приложения. Видимо почему то канал закрывается раньше чем тушится воркер. Переделаю этот момент

Канал закрываю после закрытия воркеров при шатдауне приложения. Видимо почему то канал закрывается раньше чем тушится воркер. Переделаю этот момент

я к тому, что канал же не файл, его закрывать не обзательно, утечек ресурсов это не создаст, тем более при закрытии приложения. Наксколько я понял из tour of go, канал закрывают исключительно для того, чтобы послать своеобразный сигнал о прекращении работы внутрь for { select {...}} , но у вас для этого специалльный стоп-канал есть

я к тому, что канал же не файл, его закрывать не обзательно, утечек ресурсов это не создаст, тем более при закрытии приложения. Наксколько я понял из tour of go, канал закрывают исключительно для того, чтобы послать своеобразный сигнал о прекращении работы внутрь for { select {...}} , но у вас для этого специалльный стоп-канал есть

да, логично. вероятно излишне.

Всем привет, пишу api сервер для мобильного приложения, уперся в вопрос аутентификации пользователя, читал много всего, мнения розняться, так что лучше для этого использовать? Какую то свою реализацию(выдавать пользователю рефреш и acess токены и хранить их в redis) или использовать что то готовое, как я понима в oauth2 смысла никакого нет, так это не публичное api, напривьте кто шарит, что лучше или куда смотреть.

2-legged oauth2 - это вот прямо то, что нужно

> выдавать пользователю рефреш и acess токены и хранить их в redis В общем-то это почти oauth2 и есть, в простом варианте

https://jwt.io/introduction/

Понял, почитаю и про то и про то, спасибо)

Подскажите пож как реализовать подобное. Мне необходимо на один endpoint повесить несколько экшенов, ко мне приходит GET-request по адрессу /requests/ /requests/123123 /requests/abcdefg И для каждого из них мне необходимо вызывать различные хэндлеры как можно реализовать такое ? разница между вторым и третьем лишь в том, что во втором будет uint, а в третьем string

проверять req.Path, в зависимости от пути подсовывать разные хэндлеры

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

либо используйте маршрутизатор с регэкспами, например, chi: r := chi.NewRouter() r.Route("/requests", func(r chi.Router) { r.Get("/", ...) // GET /requests r.Get("/{[0-9]+}", ...) // GET /requests/123123 r.Get("/{[A-Za-z]+}", ...) // GET /requests/abcdefg })

либо используйте маршрутизатор с регэкспами, например, chi: r := chi.NewRouter() r.Route("/requests", func(r chi.Router) { r.Get("/", ...) // GET /requests r.Get("/{[0-9]+}", ...) // GET /requests/123123 r.Get("/{[A-Za-z]+}", ...) // GET /requests/abcdefg })

Вот это мой случай, спасибо )

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

и? вешаешь хэндлер на requests. Проверяешь Path. В зависимости от условий, подсовываешь другой хэндлер.

пересказал второй раз, что первый раз написал

хттп, тсп, юдп хттп сервер наверно самый тяжелый из них, а тсп юдп относительно друг друга как? в го

В смысле тяжёлый?

по использования ресурсов, рам цп

а часто вы в го _реализуете_ tcp?

а часто вы в го _реализуете_ tcp?

приходилось один раз как-то

приходилось один раз как-то

я не тебя спрашивал (:

ничего кроме хттп не использовал но сейчас возникла задача, что бы на одной локальной машине держалось n сервисов и общалось между собой, хотелось выбрать наименее затраный в плане ресурсов вариант

ты-то понятно реализовывал