тогда обломись или пиши дурацкие констрэйнты

Я про эти констрейнты, синтаксис не помню

Т.е. по факту отдаешь статику

Контент это же и будет json, который я сохраню, а как я весь запрос с хедерами одной строкой отдам? Надо тогда свой middleware писать в обход giraffe получается?

Я про эти констрейнты, синтаксис не помню

Потому что он ужасный. type Foobar() = member this.Hello s = printfn "Hello %s" s let inline hello (a: ^T) s = (^T : (member Hello : string -> unit) a, s) let baz = Foobar() hello baz "World"

Контент это же и будет json, который я сохраню, а как я весь запрос с хедерами одной строкой отдам? Надо тогда свой middleware писать в обход giraffe получается?

Надо глянуть,шо жирафа умеет в этом плане

Потому что он ужасный. type Foobar() = member this.Hello s = printfn "Hello %s" s let inline hello (a: ^T) s = (^T : (member Hello : string -> unit) a, s) let baz = Foobar() hello baz "World"

Наше спасение в RFC. https://github.com/fsharp/fslang-design/blob/master/RFCs/FS-1024-simplify-call-syntax-for-statically-resolved-member-constraints.md

Народ поясните, это можно это в F# написать что бы НЕ ставить явно тип a? let test a = a.helloworld()

Да наверное как-то так let inline test (a: ^T) = (^T : (member helloworld : unit -> 'R) a)

Да наверное как-то так let inline test (a: ^T) = (^T : (member helloworld : unit -> 'R) a)

Плохо, что F# не умеет сам выводить такие штуки.

Да наверное как-то так let inline test (a: ^T) = (^T : (member helloworld : unit -> 'R) a)

Не работает для record'ов вроде

Можно прям в тип принимаемой переменной констрейнт загнать (есть мнение, что так читаемее)

Можно прям в тип принимаемой переменной констрейнт загнать (есть мнение, что так читаемее)

Для вот этих inline штук нельзя.

VSCode кстати обновился и Ionide (может и netstandard 2.0 пофиксили, но врядли)

Логи на telegrammy почему-то уже давно не обновляются.

Добавил отдачу предсериализованных запросов, теперь доживаем до 1500 RPS =) Но это все еще 35% фейлов

Надо дальше смотреть

Могу только сказать что сериализация не сильно мешала, вот сравнение http://clip2net.com/s/3N049BG http://clip2net.com/s/3N04bsA

т.е. разница между отдачей чистых строк и поиск с подсчетом среднего и сериализацией разнятся на 30-50% всего

А тут надо раз в 5 производительность улучшать)

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

ну еще может как-то можно kestrel потюнить, но пока не знаю как)

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

т.е. разница между отдачей чистых строк и поиск с подсчетом среднего и сериализацией разнятся на 30-50% всего

Ну всё равно неплохо, сделай так 5 раз, и будет хорошо)

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

а как .net core запрофайлить? я таким не занимался никогда, буду рад советам) правда плюс надо будет написать клиента который будет запросы делать

Ну всё равно неплохо, сделай так 5 раз, и будет хорошо)

ну это максимум из того что можно сделать уже) поиск в словаре строки по айдишке и отдача этой строки

ну разве что еще ConcurrentDictionary на Dictionary заменить, ну собственно и на этом все будет)

а как .net core запрофайлить? я таким не занимался никогда, буду рад советам) правда плюс надо будет написать клиента который будет запросы делать

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

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

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

а как сам профайлинг делать?

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

студия пока не поддерживает .net core c фшарпом)

судя по min response time 400ms, там что-то очень нетак:)

это микросекунды

а как сам профайлинг делать?

Как минимум бенчмарки локальные написать.

ms = миллисекунды, нет?

микросекунд у тебя не будет)

не, тогда бы все было совсем плохо

там такие цифры появляются потом 1641247037 ms

это в сумме, а один ответ 45080695ms

ну, я не знаю, я человек простой. если написано s - я понимаю как секунда. если ms - миллисекунда.

Как минимум бенчмарки локальные написать.

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

на самом деле даже еще меньше

и я бы скорее поверил что все плохо, чем то что ты с юзер-спейс вебсервера в докере на какой-то виртуалке отдаешь ответ за <1 ms

не, спрашивали уже в чате соревнования, это микросекунды)

нету сети просто

запросы с этой же машины идут

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

мне посути надо дожить до 2к в секунду

это значит что все запросы должны быть в среднем меньше 500мкс

а, ну если без сети - то возможно)

https://github.com/aspnet/IISIntegration/issues/220 - вот тут у людей похожие цифры, на windows правда, и, кстати RPS ~ 10k

ну мне от этого бенчмарка не легче)

там создают сначала 1 поток, а если не успевает отвечать скажем до 500мкс на запрос, то врубают 400 потоков

а не 10 как в примере)

и сразу же после этого переключения все загибается

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

нет, только косвенно можно посмотреть по общему графику времени ответов на запрос

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

голый смысла думаю нет, он сможет до 500мкс всегда отвечать

и 400 потоков они не врубят

поставь задержку)

можно)

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

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

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

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

причем там же еще прослойка в виде giraffe, тоже может влиять)

так что можно 3 случая: чисто кестрел, кестрел + жираф, и полное приложение

2 запуска в день только можно)

Надо еще внимательно на валидацию смотреть

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

сча. Валидация сейчас эксепшны кидает если параметры гет-запроса невалидные

Эксепшны дорогие довольно

https://github.com/Lanayx/PerformanceTest

ну тогда надо писать валидатор полей вручную

через chiron

Консольный вывод отруби еще

чего, он не влияет почти, раз в 1000 запросов только работает

Это в каунтере

а больше нигде и не пишет)

Короче

Идем дальше

В целом идея этого соревнования,похоже,повторить event sourcing

Поэтому есть смысл по максимуму отказаться от сериализации/десериализации

так уже)

При добавлении/обновлении данных не надо сразу валидировать,по идее

нельзя, надо же невалидные данные отбрасывать

с 400 ошибкой

На получении?

Или на добавлении?

на добавлении

на получении тоже

Значит,надо ускорять десериализацию

Точнее не так

Надо в процессе десериализации валидировать данные

=) не понял)

В json.net можно написать конвертер по идее

не, не понял смысл идеи)

Идея в том, что если при десериализации попалось невалидное поле,то дальше можно не ходить

ну, сейчас так и работает