for i := 0; i < 5; i++ { if key != "NULL" { go send_(users[i].key) } } fmt.Println("я здесь а функции send может еще работают")

Есть такой принт. Суть не меняется

ничего не прояснило

мб у вас httpclient синхронный? откуда я знаю

мб у вас httpclient синхронный? откуда я знаю

WebSocket

Есть такой принт. Суть не меняется

в смысле не меняется? принт появляется после 10ти секунд?

как все sendы отработали?

он должен появится мгновенно и никто никого ждать не должен

а почему 10 секунд работают ваши запросы - надо смотреть _send. может у тебя там time.Sleep( 10 * time.Second) написано

короче, спойлер в го нет способа без waitgroup дождаться конца рутины (или мб черз каналы, но сути не меняет)

в смысле не меняется? принт появляется после 10ти секунд?

Такой принт выход сразу, т.е. он ставит сразу 5 send() на выполнение, меньше чем за секунду.

ну, все правильно, а чего говоришь что синхронно-то работает?

а почему 10 секунд работают ваши запросы - надо смотреть _send. может у тебя там time.Sleep( 10 * time.Second) написано

В коде нет никаких слипов

ну, все правильно, а чего говоришь что синхронно-то работает?

Да, ве верно. НО. Все же в логах отправки запросов приходит все поочередно до 10 секунд

так покажи нам send_, что там написано? как сказал человек выше, наверняка лочат друг друга

короче, спойлер 2: замени send_() на println, если не так же долго, значит проблема в send и мы занимается гаданием на кофе

так очевидно проблема в send_ :)

ну а чего мы хренью страдаем

— "покажи send()" — "send написан правильно" — ...

Да походу понятно, в чем дело. Сервер не может с одного ип одновременно всех авторизовать и отправить запрос и скорее всего не дает авторизовать следущего, пока первый не разлогиниться...

Наверное поэтому он то 2 пользователя авторизирует, то 4.

ну, например. многопоточность тут никак тебе не поможет

раз он не дает одновременно авторизоваться

ну, например. многопоточность тут никак тебе не поможет

Это понятно. Искал в коде загвоздку, а походу дело в сервере.

for i := 0; i < 5; i++ { if key != "NULL" { go send_(users[i].key) } } Запустит функцию send() пять раз, т.е. он должен сразу 5 функций запустить. Что может тормозить функцию и заставлять ее ждать заврешение пердыдщуего вызова функции?

я возможно уже поздно, но go запускает горутины при определенных условиях, не сразу после вызова ключевого слова`go`. чтобы форсирвоать запуск горутин можно сделать переход в другой вызов, либо вызвать специальный метод runtime.GoSched()

GOPROCS=1 случайно не стоит?

for i := 0; i < 5; i++ { if key != "NULL" { go send_(users[i].key) } } fmt.Println("я здесь а функции send может еще работают")

https://play.golang.org/p/7WbNMbva9Sq

и на что ты намекаешь?)

1.5 секунды выполняется вся программа

в каждой рутине задержка 1 секунда

верно, потому что ты ж time.Sleep на это поставил

я возможно уже поздно, но go запускает горутины при определенных условиях, не сразу после вызова ключевого слова`go`. чтобы форсирвоать запуск горутин можно сделать переход в другой вызов, либо вызвать специальный метод runtime.GoSched()

https://play.golang.org/p/rIOl02RC1wJ

Какой итог на данный момент: Все 5 горутин запускаються меньше чем за секунды, на каждую го рутину создаеться свой WebSocket клиент. Но почему то за раз сервер не может авторизовать сразу 5 человек в секунду, а делает это со скростью 1-2 пользователя в секунду.

Aliaksandr привет) а подскажи пожалуйста, я ошибаюсь, или в новой версии fasthttp QueryArgs стало возвращаться urldecoded а раньше не было? Мне кажется, раньше в значениях GET параметров + в %20 не превращался. Ну или меня подглючивает) А то тут сломалось у меня чутка

последний коммит в мастере был в декабре, когда ты последний раз делал go get -u? или ты был завендорен на версии 2016 года?

Функция send() проста: Открываем сокет, Посылаем авторизацию, Читаем ответ, Посылаем запрос, Выводим лог с секундами. Итог: заняло 10 секунд что бы это все провернуть. Почему не атворизовывает кажого в своей го рутине со скоростью 1 пользователь в секунду. Итого хотя бы 5 выходило. (ааа ладно)

последний коммит в мастере был в декабре, когда ты последний раз делал go get -u? или ты был завендорен на версии 2016 года?

Вроде бы простой вопрос, но затрудняюсь сказать. Скорее всего не был завендорен на 2016 как мне кажется. Но вроде именно после dep ensure -update это вылезло. У меня base64 в гет параметре, до этого работало.

есть base64 url compat

можешь не париться и заюзать его)

Ммм. гляну, попробую. Но вопрос тогда получается остается)

не остается - https://github.com/valyala/fasthttp/blob/master/args.go#L456-L484

https://github.com/toby3d/telegram

А есть какие нибудь примеры?

А есть какие нибудь примеры?

https://github.com/toby3d/MyPackBot

https://github.com/toby3d/MyPackBot

?

не остается - https://github.com/valyala/fasthttp/blob/master/args.go#L456-L484

Хм, то есть, этот код там давно получается. Тогда странно прям.

Хм, то есть, этот код там давно получается. Тогда странно прям.

бывает, что base64 не ломается в урле

но тут уж я не могу помочь - у меня слишком мало информации о вашем кейсе

Ну да, если плюсов нет, то не поломается. Может действительно совпадение было, что плюсов не было. Спасибо в общем

Aliaksandr я вот что давно спросить хотел - вот есть в fhttp кеш .gz, как вы в компании варите этот кеш? или просто при загрузке новых версий файлов .gz от них трёте?

Ну да, если плюсов нет, то не поломается. Может действительно совпадение было, что плюсов не было. Спасибо в общем

да не за что

Aliaksandr привет) а подскажи пожалуйста, я ошибаюсь, или в новой версии fasthttp QueryArgs стало возвращаться urldecoded а раньше не было? Мне кажется, раньше в значениях GET параметров + в %20 не превращался. Ну или меня подглючивает) А то тут сломалось у меня чутка

значения в QueryArgs должны быть без urlencode'а. См. TestArgsParse в https://github.com/valyala/fasthttp/blob/master/args_test.go#L399 . Скорее всего, на вход приходят дважды закодированные значения

кто не видел - https://github.com/golang/go/issues/24301 приехали, коллеги, proposal accepted

кто не видел - https://github.com/golang/go/issues/24301 приехали, коллеги, proposal accepted

А в двух словах поясни

на тему этого - что же дальше: https://research.swtch.com/vgo-accepted

На вход у меня просто приходит base64 со знаком +, который превращается в пробел. Просто показалось, что раньше значения QueryArgs не преобразовывались

но в целом понятно, спасиб

А в двух словах поясни

dep мертв, в go изобретают новый package.json, названный go.mod, а это всё в целом называют vgo

Понял

но в итоге скачивание может стать пошустрее. чтобы скачать cockroachdb в zip формате, как сможет делать vgo, нужно около 10 секунд, но потребуется около 3-4 минут, чтобы сделать git clone

Aliaksandr я вот что давно спросить хотел - вот есть в fhttp кеш .gz, как вы в компании варите этот кеш? или просто при загрузке новых версий файлов .gz от них трёте?

мы не используем fasthttp для отдачи статики. А так да - при обновлении файлов нужно удалить соответствующие *.gz файлы, чтобы они пересоздались снова. Хотя лучше в имени файла хранить его версию и не обновлять уже существующие файлы, чтобы не ломать кэширование ни на сервере, ни у клиентов

мы не используем fasthttp для отдачи статики. А так да - при обновлении файлов нужно удалить соответствующие *.gz файлы, чтобы они пересоздались снова. Хотя лучше в имени файла хранить его версию и не обновлять уже существующие файлы, чтобы не ломать кэширование ни на сервере, ни у клиентов

а подобную автоматику, видимо, актуально пихать только в форк или обертку?

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

да. Но лучше все-таки либо добавлять версию файла в его название либо использовать хэш от содержимого файла в качестве его названия, как это рекомендует фейсбук с мозиллой. https://hacks.mozilla.org/2017/01/using-immutable-caching-to-speed-up-the-web/

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

хотя было бы удобно иметь подобную опцию в fasthttp.FS

но мой PR в ридми у тебя висит с 15 февраля :)))

типа периодически проверять время модификации файла и пересоздавать gz файл, если его время создания меньше времени модификации оригинального файла?

типа периодически проверять время модификации файла и пересоздавать gz файл, если его время создания меньше времени модификации оригинального файла?

можно так, можно по-разному это реализовать - вариантов много

ERROR: S client not available

хз. Лучше в форке это сделать и убедиться, что оно будет работать как надо. Потом можно замержить в fasthttp, если доберусь до него

Может, кому-нибудь пригодится, чтобы меньше обновляли статические файлы в вебе: > It is considered a best practice for websites to use "long caching" for serving images, _javascript_ and CSS. In long cacing if a website has a resource X.js which might change from time to time, rather than referencing X.js and giving the endpoint a short expiration date, they reference X-v1.js with a nearly infinite expiration date. When X.js changes, the website uploads X-v2.js and changes any references to use the new version. This has the benefit that the browser never needs to revalidate resources and that it sees changes instantly https://www.ietf.org/mail-archive/web/httpbisa/current/msg25463.html

ну - gramework 2.0 по планам будет на новом движке, а для gramework 1.0 иногда хочется и завендорить с патчами, если разрешениие дашь на это %)

конечно - лицензия же BSD - разрешает делать, что хочешь )

Может, кому-нибудь пригодится, чтобы меньше обновляли статические файлы в вебе: > It is considered a best practice for websites to use "long caching" for serving images, _javascript_ and CSS. In long cacing if a website has a resource X.js which might change from time to time, rather than referencing X.js and giving the endpoint a short expiration date, they reference X-v1.js with a nearly infinite expiration date. When X.js changes, the website uploads X-v2.js and changes any references to use the new version. This has the benefit that the browser never needs to revalidate resources and that it sees changes instantly https://www.ietf.org/mail-archive/web/httpbisa/current/msg25463.html

это, де-факто, стандарт)

конечно - лицензия же BSD - разрешает делать, что хочешь )

лицензия MIT, бро)

одно и то же

я не юрист, но вроде различий почти нет

есть)

какие?

2-clause bsd требует от тебя приведения списка изменеий и соответствующий дисклеймер, а также бинари из 2-clause bsd кода обязаны (RFC 2119 пункт 1) повторять указанный в лицензии копирайт, список условий и соответствующий дисклеймер в документации или в материалах в поставке. 3-clause bsd требует сверху то, что ни имя организации, ни имена контрибьюторов, должны не использоваться (от слова RFC 2119 пункт 2) в маркетинговых целях без письменного на то разрешения 4-clause bsd требует, чтобы абсолютно все рекламные материалы, связанные с фичами или использованием лицензируемого софта должен иметь нотайс - This product includes software developed by the [org name]

Aliaksandr, ты о какой из версий?

юристы любят все запутать

я не юрист, но над греймом потрудилась довольно большая команда юристов

пришлось разбираться

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

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

MIT и BSD вроде обязывают упоминать источник кода с оригинальной лицензией

я, кстати, небольшой кусок кода взял из fasthttp, но мне там нужно было заменить используемые типы. по твоей лицензии достаточно было дописать вот это https://github.com/gramework/gramework/blob/dev/adaptor.go#L38-L43

и, естественно, https://github.com/gramework/gramework/blob/dev/third_party_licenses/fasthttp

MIT и BSD вроде обязывают упоминать источник кода с оригинальной лицензией

всё так, нотайс обязателен

Вот я читаю по диагонали драму по vgo и не могу понять как он будет работать

С dep всё понимание было экстремально сжатым: всё кладётся в вендор, ненужные куски кода можно оттуда снести, обновление вендора - по требованию. Содержание коммитится вместе с живым кодом, всё рядом. Больше ничего

Имея на руках vgo я не имею ни малейшего представления как это должно работать, что я хочу получить

почти та же история

но уже без toml/lock файлов в том виде, как мы привыкли с dep

Вроде меня уверяют, что создавать версионные ветки не надо, особо больших изменений производить не надо. А что делать-то мне, как разработчику пакета/приложения если я что-то делаю с нуля и хочу версионировать как теперешний goway?

Как работать с зависимостями, если они сохранены через dep? Вдруг мне опасно применять тактику "ну хрен с ним, снесу нынешнюю заморозку и качну новый через vgo"

go.mod сделать надо будет, а там вписать нужные версии зависимостей. это в теории.

А как проверить, закрыт канал или нет перед записью в него, не читая из него ничего?

ты пробовал гуглить вообще?

go.mod сделать надо будет, а там вписать нужные версии зависимостей. это в теории.

Звучит отвратительно