标签：#orm

While contributing to Grafana, I picked up a memory issue in the Time Comparison feature — a follow-up to earlier performance work I had done in the same area. A comparison panel was consuming significantly more memory than expected. The interesting part: the extra memory wasn't coming from real data. This post covers how I traced it to the root cause and fixed it. Background Time Comparison overlays an earlier period onto the current one — for example, this week vs. last week. The comparison data is fetched from the earlier window and shifted forward before rendering: Query → DataFrame → Prepare frame → Shift → Render │ └─ Gap filling The important detail: gap filling ran before the comparison frame was shifted. The Problem I reproduced the issue with: Parameter Value Series 500 Window 6h Interval 20s Compare offset 24h A single-period panel contained roughly 540,000 points , so a comparison panel should be about 2× the baseline . Instead, the compare frame contained 3,240,500 points — ~6× the baseline — and consumed 76.4 MB . The question was: where did the extra points come from? Investigation I first verified the baseline to rule out the query returning unexpected data. It was correct. Then I used a reproducible browser harness and a heap snapshot to inspect the extra memory. Most of it was null rows introduced during gap filling — not real samples, not copies. Following the frame through the preparation pipeline revealed why. When gap filling ran, the compare frame still represented data 24 hours in the past , but the gap-filler was using the current time range as its reference: Compare frame Current range [===== 6h =====] [===== 6h =====] └─────────────── 24h ───────────────┘ gap-filler reads this offset as one gap At a 20-second interval, 24 hours is: 24 × 60 × 60 / 20 = 4,320 intervals So up to 4,320 null positions per series were introduced purely because the frame hadn't been shifted yet. The frame was then shifted forward, leaving most of that padding out

In today's digital world, businesses face the challenge of developing, deploying, and scaling applications faster and more efficiently. One of the key technologies supporting this transformation is container technology. What are Containers and Why Are They Important? Containers allow applications to be packaged into lightweight, self-contained, and portable units that can run consistently in any environment—from a local development machine to a cloud platform. This reduces dependencies and significantly simplifies application deployment and scalability. Unlike virtual machines (VMs), containers share the operating system kernel, making them more resource-efficient. This leads to higher efficiency and allows businesses to run more applications on the same infrastructure. Introduction to Kubernetes: Orchestration of Containers While containers represent a revolutionary approach to developing and running applications, it’s not enough to simply have containers. Once applications consist of dozens or hundreds of containers, managing, orchestrating, and scaling them becomes critical. This is where Kubernetes comes in. Kubernetes is the world’s most widely used container orchestration platform. It enables the automatic deployment, scaling, and management of containerized applications in clusters. With Kubernetes, companies can ensure their applications are always available, automatically recover from failures, and roll out new versions without downtime. Azure Kubernetes Services (AKS): Kubernetes in the Cloud Azure Kubernetes Services (AKS) is Microsoft’s fully managed Kubernetes solution. With AKS, businesses benefit from simplified Kubernetes deployment by offloading infrastructure management to Microsoft. This means you can focus on developing and scaling your applications while AKS simplifies the management and maintenance of Kubernetes clusters. Benefits of AKS: Fully managed: AKS takes care of the management and patching of Kubernetes, allowing businesses to focus on

Uno Platform 6.6 introduces Native AOT publishing across five target platforms, an optional Vulkan rendering backend, and automatic registration for the framework’s Model Context Protocol servers. The release also reduces XAML boilerplate, expands cross-platform WinUI API coverage, and improves accessibility and multilingual text handling. By Edin Kapić

No need annotation,No need check null, No need inherit,No need scan,Based on JOOQ 1.Quer User Paramater public class UserParam { String name ; LocalDate beginBirthday ; LocalDate endBirthday ; int offset ; int limit ; ... } 2. User Bean public class User { private Integer id ; private String name ; private LocalDate birthday ; private String nickName ; private Gender gender ; private String avatarAddress ; ... } 3.UserService @Service public class UserService { @Autowired private JooqTemplate jt ; public int insertUser ( User user ) { //Bean to camel map Map values = JooqMaps . toCamelCase ( user ); //Add additional data values . put ( "create_time" , LocalDateTime . now ()); // Insert record return jt . insertReturningv ( "user_table" , values , "id" ). get ( "id" , Integer . class ); } public void updateUser ( User user ) { Map values = JooqMaps . toSnakeCase ( user ); //Regardless of whether it is null or not, update in Map. Update statement does not include in Map values . remove ( "id" ); values . remove ( "name" ); //jt.updatev("some_table",values,"column1",param1,"column2",param2...); //Variable parameter condition update UPDATE user_table SET ... WHERE id=? jt . updatev ( "user_table" , values , "id" , user . getId ()); } public void deleteUser ( int id ) { //jt.deletev("some_table","column1",param1,"column2",param2...); //DELETE FROM user_table WHERE id=? jt . deletev ( "user_table" , "id" , id ); } public User loadUser ( int id ) { //1 Variable parameter condition loading SELECT * FROM user_table WHERE id=? LIMIT 1 return jt . loadv ( "user_table" , User . class , "id" , id ); } public List < User > selectUser ( UserParam param ) { //Automatically ignore null parameters //SELECT * FROM user_table WHERE name LIKE '%?%' AND birthday BETWEEN ? AND ? ORDER BY name ASC,birthday desc; return jt . queryv ( "user_table" , User . class , "name%" , param . getName (), "birthday:between" , param . getBeginBirthday (), param . getEndBirthday (), "name:asc" , "birthday

My Terraform drift pipeline could detect a manual EC2 tag change, classify it as LOW, and run Terraform to remove it. Then the pipeline moved on. The evidence existed, but it was spread across CodeBuild output, Lambda logs, and an SNS message. If I wanted to know what changed, how it was classified, and whether remediation started, I had to reconstruct the event from multiple AWS services. The pipeline could act on drift. It could not remember drift. Phase 4 added that memory: a durable DynamoDB record, a read only API, and a small dashboard that turns the event history into something I can inspect without opening three AWS consoles. The Stack Terraform drift event ↓ SNS ↓ Severity Lambda ├── classifies HIGH / MEDIUM / LOW ├── starts remediation for eligible LOW drift └── writes the audit event to DynamoDB ↓ API Gateway HTTP API ↓ Read only Lambda ↓ DynamoDB Query ↓ CloudFront → static dashboard ↑ private S3 bucket The browser receives static HTML, CSS, and JavaScript from CloudFront. JavaScript calls API Gateway, the API Lambda queries DynamoDB, and the returned JSON becomes the live dashboard. There is no EC2 web server and no application process running continuously. Step 1: Store Every Classified Event I created a DynamoDB table with a composite key: resource "aws_dynamodb_table" "drift_events" { name = "terraform-drift-events" billing_mode = "PAY_PER_REQUEST" hash_key = "project" range_key = "timestamp" attribute { name = "project" type = "S" } attribute { name = "timestamp" type = "S" } } project groups the history for one Terraform project. The ISO 8601 timestamp orders its events. DynamoDB only requires attribute definitions for keys and indexes. Fields such as high_count , changes , and status still belong in each item, but they do not belong in the table schema block. I passed the table name into the existing severity Lambda instead of putting it directly in the code: environment { variables = { DRIFT_EVENTS_TABLE = aws_dynamodb_table . drift_events . name

Before you start: This picks up where Part 1 left off. From part 1, you would've learned how to setup a Bedrock Knowledge Base in the console. In addition to that, you should have a general understanding of how the ingestion and query pipeline works. Introduction & Motivation I started this project with a singular goal: to build a comprehensive Terraform module that allows developers to deploy the entire infrastructure for a "Chat with PDF" application faster. When Amazon Bedrock was first unveiled in April 2023 , I jumped in immediately. Like many of you, I built several proof-of-concepts (PoCs) through the AWS Console. The UI is amazing for building quick pocs, but once I moved into experimentation, I realized it would be best to quickly setup and tear down the infra. An example use case was testing if there were any cost savings in using S3 Vectors vs OpenSearch and how much cost savings exactly. None of the Terraform modules I found on GitHub ( at the time ) seemed to cover the end-to-end pipeline I was looking for, so I decided to build mine. I'm also big on learning so why not. What Are We Building? A couple of terraform modules to automate everything we clicked through manually in Part 1. One terraform apply brings up the full stack: S3 Bucket : your document store. Encrypted at rest, versioning on, zero public access. OpenSearch Serverless : the vector database. Stores the embeddings Bedrock generates during ingestion. Bedrock Knowledge Base : orchestrates the chunking, embedding, and storage of documents, and retrieval at query time. Ingestion Lambda : triggered automatically when you upload a file to S3. Starts a Bedrock ingestion job so documents are chunked, embedded, and indexed without ClickOps. Query Lambda : accepts a natural language question, calls RetrieveAndGenerate , and returns an answer with source citations. Full source code + ReadMe: Bedrock Project . If you run into issues or want to extend the module, feel free to open an issue. Architectu

Dumanshu Goyal discusses optimizing data layers for low-latency workloads like AI feature stores. Drawing lessons from NASA's Space Shuttle, he explains how proxy architectures introduce hidden CPU costs, elevated tail latencies, and blast-radius risks. He demonstrates how direct-access Valkey architectures achieve microsecond latency, improve resilience, and slash infrastructure costs. By Dumanshu Goyal

I maintain Fulmine , a drop-in replacement for Express 5 that runs on µWebSockets.js instead of node:http . One line changes: const express = require ( " fulmine.js " ); // instead of require("express") Your middleware keeps working: helmet , cors , passport , morgan , multer , express-session and the rest. The numbers are not mine Benchmarks published by a project about itself deserve suspicion, so let me use somebody else's. HttpArena runs every framework on the same 64-core machine, in containers, under the same rules, and publishes the results. Express and Fastify are on that board too. Requests per second, from their published runs: Profile Fulmine Express Fastify Baseline (query parsing) 1,220,308 607,777 711,263 JSON (dataset + serialization) 1,111,187 395,361 522,201 Short-lived connections 1,026,789 278,163 298,779 Pipelined 7,259,814 1,009,543 1,671,338 Mixed API workload, 16 CPUs 126,282 67,724 75,633 Async Postgres 222,701 169,687 179,169 Upload (20 MB body) 2,154 2,104 1,902 That is 2.0x Express on the baseline, 2.8x on JSON, 3.7x on short-lived connections, 7.2x pipelined , and 1.9x on the mixed API profile. Against Fastify, on the same board, it is 1.7x on the baseline and 2.1x on JSON. Now the honest parts, which matter as much as the table. Look at the upload row: 1.02x. A 20 MB body is memory bandwidth and syscalls, not framework code. Everywhere the cost belongs to a library both servers call, the difference disappears: JSON.parse , zlib, OpenSSL. Speed comes from the framework only where the framework is doing the work. My entry runs in the arena's "tuned" mode, Express's and Fastify's run in "standard". On two profiles I left out of the table, static files and compressed JSON, that difference is decisive, because tuned mode allows hand-written compression and negotiation. Those rows would show 23x and 8x, and they would be measuring my entry's tuning, not the framework. I would rather not quote them. Where the speed comes from Not from one trick

As streamers compete with social media giants for viewer attention, Disney+ is partnering with TikTok to bring creator content to its app.

Microsoft and Uno Platform have released the first stable versions in the SkiaSharp 4 series, beginning with SkiaSharp 4.148.0 and followed shortly afterward by 4.150.0. A 4.151.0 prerelease line is also available, demonstrating the project’s new approach of aligning package versions and release cadence with upstream Skia milestones. By Edin Kapić

A slow AI feature does not feel smart. It feels broken. That is the uncomfortable truth many AI SaaS builders hit after the demo works. The prototype answers well, the agent can call tools, and the RAG pipeline looks impressive. Then real users arrive. Prompts get longer. Queues form. Streaming starts late. One tenant uploads huge documents. Another runs bulk jobs at noon. Suddenly the same workflow that felt magical in testing feels like a spinner with an invoice attached. The fix is not simply “use a faster model.” You need an LLM latency budget : a small set of rules that says how fast each AI workflow must feel, how many tokens it can spend, when to stream, when to cache, when to route to another model, and when to stop before cost and latency drift together. This guide is for solo SaaS developers, micro SaaS builders, and AI SaaS teams shipping production features with LLM APIs, RAG, agents, or self-hosted models. Why latency budgets matter now AI platform news points in the same direction: builders are moving from chat demos to production workflows. Agent tools, web context APIs, voice agents, coding assistants, and RAG platforms are all getting more capable. At the same time, inference cost and reliability are under pressure. Latency is now a product metric. Inference efficiency is becoming a business metric. Yet many articles stop at TTFT, TPOT, quantization, batching, or model serving. Fewer show how a SaaS builder turns those ideas into a product-level budget with code, dashboards, fallbacks, and customer-safe limits. The simple model: TTFT, TPOT, and total time You do not need a PhD in serving systems to start. Track three numbers. Time to First Token Time to First Token (TTFT) is the delay between the user action and the first streamed token. It includes network time, queue time, provider overhead, tool setup, retrieval, and the model’s prefill phase. High TTFT is why a chat box feels dead. Time Per Output Token Time Per Output Token (TPOT) is the averag

Looking for Contributors to Build Zentrail IDE — An AI-Native Open Source Desktop IDE Hello everyone! 👋 I'm building Zentrail IDE , an open-source, AI-native desktop IDE designed for the next generation of software development. The goal isn't to build another code editor. The goal is to create an IDE where multiple AI agents can collaborate with developers in a single workspace to plan, write, review, test, and manage code. We're still in the early architecture and planning phase, and I'm looking for developers, designers, and AI enthusiasts who want to help build it from the ground up. 🎯 Project Vision Create an AI-first development environment that combines: 🧠 Multi-Agent Collaboration 💻 Native Desktop Performance 🤖 AI CLI Integration 📦 Plugin & Skill Ecosystem 🌍 Open Source Community ⚡ Modern Developer Experience ✨ Planned Features Workspace System Multi-project workspaces Workspace memory Persistent sessions Task management AI Workspace Agents Multiple AI agents running simultaneously Shared workspace memory Parallel task execution Intelligent task orchestration AI CLI Support Claude Code Gemini CLI OpenAI-compatible providers Local AI models Custom AI CLIs Git Automation AI-assisted commits Pull requests Code reviews Branch management Repository insights Skill System Install reusable AI workflows with a single command. Examples: Security Review Code Refactoring API Generator Documentation Writer Test Generator Plugin SDK A modular extension system for adding custom functionality without modifying the core IDE. 🛠 Tech Stack Frontend TypeScript React Tauri v2 Monaco Editor Tailwind CSS Backend Go gRPC WebSocket AI Runtime Python MCP LangGraph Database SQLite 🤝 We're Looking For We're looking for contributors interested in: Frontend React TypeScript UI/UX Monaco Editor Backend Go gRPC WebSocket Performance optimization AI Python MCP Agent orchestration Prompt engineering Desktop Tauri Windows development Cross-platform architecture Design UI/UX Design Icons Develo

Platform engineering maturity is emerging as an important factor in determining whether organizations can turn AI adoption into sustainable operational value, according to Perforce Software's 2026 Platform Engineering Report. By Craig Risi

Chris Richardson discusses leveraging Team Topologies and internal platforms to accelerate microservices delivery. He explains six key platform patterns - from security and observability to build and deployment - and shares strategies for minimizing cognitive load on stream-aligned teams while avoiding common platform engineering pitfalls. By Chris Richardson

An algorithmic trading platform doesn't operate in isolation it responds to the changing conditions of the financial markets. One of the biggest factors affecting automated trading performance is the market session. Liquidity, volatility, trading volume, and price movements can vary significantly throughout the trading day, influencing how an algorithmic trading platform executes trades. Understanding how different market sessions impact automated trading can help traders choose the right strategies, manage risk more effectively, and improve overall trading performance. What Are Market Sessions? A market session refers to a specific period during which a stock exchange is open for trading. In India, the National Stock Exchange (NSE) and Bombay Stock Exchange (BSE) follow a structured trading schedule that includes the pre-open session, regular trading hours, and post-closing session. Each session has unique market characteristics, making it important for traders to understand how their automated strategies may behave during these periods. Why Market Sessions Matter in Algorithmic Trading An algorithmic trading platform follows predefined rules, but the market environment changes throughout the day. A strategy that performs well during high-volume periods may struggle when trading activity is low. Market sessions influence several key factors, including: Trading volume Market liquidity Price volatility Bid-ask spreads Order execution quality Recognizing these differences allows traders to build strategies that are better suited to specific market conditions. Pre-Open Session The pre-open session is used to determine the opening price of securities before regular trading begins. During this period: Orders are collected but not executed immediately. Prices may fluctuate as the market discovers the opening level. Liquidity can be limited. Large overnight news events may influence price movements. Most intraday automated strategies are designed to become active only afte

When you open a long page — a news feed, an admin table, a documentation article — the browser lays...

It was 2 AM, and the on-call chat was on fire again: the order service was healthy on every dashboard, but throughput had flatlined at ~800 req/s while P99 climbed past 4 seconds. The usual suspect? A thread pool sized by guesswork during a late-night deploy, six months earlier. We'd hand-tuned maxThreads to "something that felt right," and it wasn't right anymore. That's the moment I started appreciating a different default: in Solon, all of those knobs ship as 0 — meaning auto , derived from your machine's actual CPU cores at runtime. You can go months without thinking about a single thread-pool property. This post walks through the five knobs that exist, how the auto-tuning math works, and the three failure modes that tell you it's time to touch them. The five knobs under the hood Solon exposes these on app.yml (all values are the documented defaults): # Minimum threads for the http server (0 = auto; also accepts fixed values like 2, or core multiples like x2) server.http.coreThreads : 0 # Maximum threads for the http server (0 = auto; also accepts fixed values like 32, or core multiples like x32) server.http.maxThreads : 0 # Idle thread timeout in ms (0 = auto) # supported since v1.10.13 server.http.idleTimeout : 0 # Is this an IO-bound service? (default true) # supported since v1.12.2 server.http.ioBound : true # Enable the virtual thread pool (default false) # supported since v2.7.3 solon.threads.virtual.enabled : false Notice what's missing: no hard-coded defaults for coreThreads or maxThreads . 0 means "figure it out from the hardware." That single decision removes a whole class of "copy-pasted tuning values" problems — the ones that were right for someone else's 32-core box and wrong for your 2-core container. CPU-bound or IO-bound: the one question that matters The auto-tuner only needs you to answer one question: is your workload CPU-bound or IO-bound? CPU-bound : the work happens entirely in CPU and memory — think a "hello world" handler that returns a s

Cuando llevamos modelos de lenguaje o IA a producción, la latencia es nuestro principal enemigo. Evaluar un modelo únicamente por su precisión ignora un factor crítico: el rendimiento computacional. En este post analizamos por qué la velocidad (medida en tokens por segundo) se ha convertido en una métrica clave de arquitectura y cómo puedes empezar a medirla. ¿Por qué importa la velocidad? Reducción de Latencia: Aplicaciones críticas (finanzas, salud, automatizaciones) no pueden esperar segundos por una respuesta. Eficiencia de Recursos: Optimizar el rendimiento disminuye el uso prolongado de GPUs, reduciendo directamente la factura cloud. Técnicas Clave: El uso de arquitecturas ligeras, cuantización y batch processing permite mantener la precisión mientras se incrementa el rendimiento. Ejemplo Práctico: Midiendo el rendimiento en Python Un enfoque inicial para medir la tasa de procesamiento de datos/tokens en tus pruebas de rendimiento: import time def medir_velocidad ( modelo , datos ): inicio = time . time () # Procesamiento del conjunto de datos o tokens respuesta = modelo . procesar ( datos ) fin = time . time () tiempo_total = fin - inicio tokens_procesados = len ( datos ) # O conteo exacto de tokens generados/procesados velocidad = tokens_procesados / tiempo_total print ( f " Tiempo total: { tiempo_total : . 2 f } s " ) print ( f " Rendimiento: { velocidad : . 2 f } tokens/segundo " ) return velocidad Tip de Arquitectura: Un objetivo de ~100 tokens/seg es una excelente referencia para sistemas que requieren interacción humana en tiempo real. Pasos sugeridos para optimizar: Benchmark inicial: Establece tu baseline de tokens/seg. Batch Processing: Agrupa solicitudes para maximizar el paralelismo. Modelos Destilados/Cuantizados: Evalúa si un modelo más pequeño satisface el caso de uso con una fracción de la latencia. 💬 Comunidad Pivelcode: ¿Qué herramientas o librerías utilizas para hacer profiling y benchmarking de tus modelos de IA? ¡Déjalo en los comentarios!

A practical calculator for turning an upload limit into a video bitrate, with enough margin for audio and container overhead. “Make this video smaller” is an open-ended request. “Make this three-minute video fit under 10 MB” is an engineering constraint. The second version sounds more precise, but a quality slider alone cannot solve it. A quality setting tells an encoder how aggressively to preserve detail. It does not directly tell us how many bytes the final file may contain. If the destination has a hard upload limit, the useful starting point is a bit budget. This article builds that calculation in TypeScript, then looks at the assumptions that make the answer less exact than the formula first appears. File Size Is Bitrate Multiplied by Time A video file contains several streams plus a container. For a simple MP4, the largest pieces are usually: the video stream; the audio stream; container metadata and indexing overhead. If we ignore overhead for a moment, the relationship is straightforward: file size in bits = total bitrate in bits per second × duration in seconds Rearranging it gives us the total bitrate available for a target size: total bitrate = target size in bits / duration in seconds That total must cover both video and audio. The approximate video budget is therefore: video bitrate = total bitrate - audio bitrate - overhead allowance The result is not a promise. It is a budget that an encoder can aim at. Be Explicit About MB and MiB Before writing code, decide what “10 MB” means. Storage vendors and many web services use decimal megabytes: 1 MB = 1,000,000 bytes Operating systems and developer tools often display binary mebibytes: 1 MiB = 1,048,576 bytes The difference is about 4.9%. That is large enough to turn a file that looks safe locally into a rejected upload. For a hard external limit, I prefer to calculate with decimal MB and keep an additional safety margin. For an internal tool where the unit is clearly MiB, I make that choice explicit in th

One thing Microsoft is not good at is naming things, and sadly it's happened again. But let's go back to the beginning: what are Skills? Skills are targeted prompts/context that are modular, so they are not always included in the LLM session. They are Markdown files with selected metadata in YAML, all in a file normally named skill.md (the parent folder and YAML metadata identify it). They were created by Anthropic (Claude) and were designed for both the user to add in a prompt ( /Skill ), or for the LLM to decide. Similar to Skills are Plug-ins. These can (and often do) include skill.md files, but can also have scripts, MCP servers, and other tools. So back to Microsoft naming things badly. Copilot Studio (Azure Bot Framework version) had skills, but they were not skills. The new Copilot Studio has Skills, but they are not Skills, they are actually Plug-ins. Plug-ins include Skills, so why does it matter? Well, it doesn't really, but I like to moan, and it means sometimes cool functionality can be left on the table because we presume Microsoft names things accurately. Anyway I digress (I like to do that), now we understand what Skills/Plug-ins are I wanted to dive into them within Copilot Studio and cover: Why Are They Cool Building Powerful Skills Adding Scripts/Templates Using Skills 1. Why Are They Cool I often go on about skills being cool, but why? There are a few reasons. Context Management Before skills, the standard approach was to give the LLM everything and let it figure out what it needed. The problem with this is twofold. First, more context equals more tokens, which equals more cost. Second—and more importantly—too much unrelated context can have a detrimental impact on the LLM response. LLMs work by using input tokens to predict the next token, so polluted input tokens can make the LLM predict the wrong next token (this is a huge simplification, but you get what I mean). Transferable As skills are simple Markdown files, they can easily be transferred