The Ugly Org - una DB para mi amigo George Hotz y comma.ai en Rust

El algoritmo de hashing nuevo lo voy a dejar, ya no tengo interés en mantener interoperabilidad total. Ya he arreglado bastantes cosas igualmente.

https://github.com/vrnvu/rust-minikeyvalue/pull/17

Esta bastante bien xq inicializamos el ring con los volumenes que tenemos disponibles y como sabéis en esta arquitectura hay que parar el master si hay que rebalancear o hacer cualquier cosa...

Tambien he estado usando esta herramienta: https://tokio.rs/tokio/topics/tracing-next-steps

No vale para mucho la verdad...

Donde este un buen flaemgraph de cpu y de memoria que se quite. El problema es que los flamegraph con codigo tan async/io no estan bien optimizados y no te dan datos relevantes.. Intentare mejorar el análisis y el tooring de eso un poco.

Migrado de Warp a Axum, mismos benchmarks...

https://github.com/vrnvu/rust-minikeyvalue/pull/18/files

Pero bueno, este framework es mas bajo nivel asi que creo que me gusta mas, fijaros en algunos cambios lo meme que son... porque rust no tiene una buena stdlib...

Y asi unos cuantos, todas las librerías y frameworks tienen decenas de cosas que son lo mismo pero con otro nombre y copy pasteado porque no esta en la stdlib estable!

Estoy un poco atascado con el profiling.

Tenemos un codigo un 35% mas rapido y eficiente pero no escala :/

Voy a hacer un comentario hoy sobre diseño de APIs y una cosa que no me gusta sobre las recomendaciones del DDD y similares. La gente que diseña estas librerías lo hace para jugar el rato o montar sobre-enginieria, pocas veces lo hace gente para trabajar (go). Y esto se nota mucho en que siguen ideas como MODELAR EL DOMINIO en lugar de diseñar cosas UTILES.

Una manera muy fácil de ver si una librerías la ha escrito alguien que sabe lo que hace es ver si la ha escrito para los usuarios. Y aqui es importante hacer hincapié en un detalle sutil que se convierte en critico con los años. La documentación NO debe ser necesaria. La documentación es una AYUDA para visualizar la API/Libreria, los métodos las interfaces el sistema de tipado. Pero no debo necesitar estar constantemente re-buscando en los ejemplos porque no entiendo que cosas van con que. Y ahi esta el problema de Rust. Es una torre de naipes de sistemas de traits construido para la masturbacion de sus autores en su gran mayoria.

Asi pues, como se detecta si algo esta escrito para los usuarios? Las cosas son obvias donde van. Solo hay 1 manera de hacer las cosas. Los modulos indican intención y porque, no DOMINIO. Es decir, todo lo contrario que te enseñan en la universidad y todo lo que se ha hecho en unix/gpl y demas escuelas de open source toda la vida. Por ejemplo:

En Axum tenemos el concepto de extractors. Son las cosas que nos "extraen" información de las Request como el body,headers,paths params,query params... y ademas sirve para pasar el estado. La idea conceptual es request => extractors => handler => response.

Pues bien, fijémonos en la MIERDA que es AXUM. AXUM y la gran mayoria de software que tocas: https://docs.rs/axum/latest/axum/extract/index.html#common-extractors

use axum::{
    extract::{Request, Json, Path, Extension, Query},
    routing::post,
    http::header::HeaderMap,
    body::{Bytes, Body},
    Router,
};
use serde_json::Value;
use std::collections::HashMap;

// `Path` gives you the path parameters and deserializes them. See its docs for
// more details
async fn path(Path(user_id): Path<u32>) {}

// `Query` gives you the query parameters and deserializes them.
async fn query(Query(params): Query<HashMap<String, String>>) {}

// `HeaderMap` gives you all the headers
async fn headers(headers: HeaderMap) {}

// `String` consumes the request body and ensures it is valid utf-8
async fn string(body: String) {}

// `Bytes` gives you the raw request body
async fn bytes(body: Bytes) {}

// We've already seen `Json` for parsing the request body as json
async fn json(Json(payload): Json<Value>) {}

// `Request` gives you the whole request for maximum control
async fn request(request: Request) {}

// `Extension` extracts data from "request extensions"
// This is commonly used to share state with handlers
async fn extension(Extension(state): Extension<State>) {}

No os voy a decir el problema, os voy a dar la solución para terminar el post, pensad en ello vosotros mismos, veréis que es muy obvio. De nada.

use axum::{
    extract::{Request, Json, String, Path, Extension, Query, header::HeaderMap, body::Bytes, body::Body},
    routing::post,
    Router,
};
use serde_json::Value;
use std::collections::HashMap;

// `Path` gives you the path parameters and deserializes them. See its docs for
// more details
async fn path(Path(user_id): Path<u32>) {}

// `Query` gives you the query parameters and deserializes them.
async fn query(Query(params): Query<HashMap<String, String>>) {}

// `HeaderMap` gives you all the headers
async fn headers(headers: HeaderMap) {}

// `String` consumes the request body and ensures it is valid utf-8
async fn string(body: String) {}

// `Bytes` gives you the raw request body
async fn bytes(body: Bytes) {}

// We've already seen `Json` for parsing the request body as json
async fn json(Json(payload): Json<Value>) {}

// `Request` gives you the whole request for maximum control
async fn request(request: Request) {}

// `Extension` extracts data from "request extensions"
// This is commonly used to share state with handlers
async fn extension(Extension(state): Extension<State>) {}

Venga, para fperos:

use axum::{
    routing::post,
    Router,
};
use serde_json::Value;
use std::collections::HashMap;

// `Path` gives you the path parameters and deserializes them. See its docs for
// more details
async fn path(extract::Path(user_id): extract::Path<u32>) {}

// `Query` gives you the query parameters and deserializes them.
async fn query(extract::Query(params): extract::Query<HashMap<String, String>>) {}

// `HeaderMap` gives you all the headers
async fn headers(headers: extract::HeaderMap) {}

// `String` consumes the request body and ensures it is valid utf-8
async fn string(body: extract::String) {}

// `Bytes` gives you the raw request body
async fn bytes(body: extract::Bytes) {}

// We've already seen `Json` for parsing the request body as json
async fn json(extract::Json(payload): Json<extract::Value>) {}

// `Request` gives you the whole request for maximum control
async fn request(request: extract::Request) {}

// `Extension` extracts data from "request extensions"
// This is commonly used to share state with handlers
async fn extension(extract::Extension(state): extract::Extension<State>) {}

Imaginate que quiero sacar un header concreto, ahora mismo NO puedo, he tenido que pasar todos los headers, entre comillas ya me entendéis. Pero podria tener un custom T que implementase extract::ExtractFromRequest y fuera. Asi de fácil.

Marie Kondo: Rule 4: Tidy by Category, Not by Location

Otra decision because potato.

En lugar de construir errores estaba pensando en devolver un enum de error e implementar e trait IntoResponse. Hasta aqui bien. La verdad, tansolo es una guía de estilo y no tiene mucha importancia. Yo prefiero devolver siempre las response builder porque es lo mas flexible, cómodo y claro de que esta pasando. Pero por probar que no se diga... pues bien, lo he probado.

El codigo es bastante simple, la gran ventaja de esto es que si tienes una api con diez mil endpoints pues unifica todo en un sitio y evita que un fpero recién salido de la universidad te envié un status code que no de deba sin testear... y yo que se, por algun motivo eso pase la code review y termine en prod...

Y nos permite escribir codigo usando ?:

Que discutiblemente, según estilos y gustos, pros/cons variados, podemos decir que se lee mas claro. Como veis no hay mucha diferencia. Pues bien, el problema:

Si quiero usar los helpers para headers típicos como Content-Length y Location debo meterle un to_string(). porque la api que han diseñado, no permite que yo le pase un String y me lo convierta a su tipo de header, porque lo han hecho a propósito que nadie pueda implementarlo sino cumple las restricciones que se han inventado...

Lo mas simple.. meterlo en el struct ya no vale. Sorpresa! Me dice que puedo pasarlo por parámetro... ósea que si ahora creo una función, para crear mi struct/enum de error, poder hacer lo que no puedo hacer si primero creo el struct e implemento el error! Osea esta del puto reves jajajajaja xq si yo ahora hago esto:

para que cojones quiero un struct de error??? si le estoy pasando a la función todos los parámetros en el formato que necesito para hacer una response builder, pues hago una response builder que es lo que tenia!

Osea que esto es lo que tengo, y si quiero puedo wrappearlo en un Err(AppError) que implementa IntoResposne para que en otra llamada se cree lo que ya tenia escrito! jajajajaja

Es flipante chavales, flipante.

#42 joder macho que profesional sueno y que bien hablan de mi

el contenido tiene algún fallo de contenido, pero esta muy guapo si

#44 para mejorar los resultados debería tirar benchmarks de funciones mas granulares, porque los flamegraph de mis thrasher.go que usamos de benchmark duran tanto y tienen tanta traza del runtime de tokio (async event loop) que no se ve nada.

se un par de sitio cosas que podria cambiar como lo hago a ciegas y probar, y he probado otros tantos como calcular con un spawn_blocking los hashes y hacer que el codigo en general bloquee menos el eventloop, pero no he visto mejoras.

asi que debería tirar un profiler de cpu y de memoria de mis funciones y ver ahi si hay algo mal. pero no lo he hecho.

Mi intuición me dice q el problema es como uso el runtime. Porque la performance de cada petición es rapidísima pero no estoy escalando. Por ejemplo en el put copio mucho el buffer del body. Nse. Debería mirarlo como digo.