Vai al contenuto
BigTree108

Servizi di test di performance e di carico

Servizi di test di performance e di carico: test di carico, stress, spike e soak in k6, JMeter, Gatling e Locust, capacity planning prima di lanci e picchi di vendita, analisi dei colli di bottiglia in codice, database e infrastruttura, performance del front end e Core Web Vitals, e test di performance nella CI, con performance engineer dedicati al Suo team o progetti di test di performance realizzati end to end.

I test di performance che eseguiamo

  • Test di carico

    Il traffico atteso, modellato a partire dai log di produzione e dalle analytics come percorsi utente con tempi di attesa e dati realistici, eseguito finché tempi di risposta, tassi di errore e uso delle risorse mostrano a che punto si trova il sistema rispetto agli obiettivi.

  • Test di stress e di spike

    Carico portato oltre il picco atteso per trovare il punto di rottura e ciò che cede per primo, e improvvisi aumenti come l’invio di una e-mail di marketing o l’apertura della vendita di biglietti, per vedere se l’autoscaling reagisce in tempo e se il sistema si riprende da solo.

  • Test di soak e di durata

    Carico costante mantenuto per ore o giorni per trovare perdite di memoria, pool di connessioni esauriti, code che crescono e dischi che si riempiono di log, i problemi che un test breve non raggiunge mai.

  • Script k6, JMeter, Gatling e Locust

    Grafana k6 in JavaScript, Apache JMeter per piani di test esistenti e per protocolli diversi da HTTP, Gatling in Java o TypeScript e Locust in Python, con gli script conservati nel repository accanto al codice che testano.

  • Analisi dei colli di bottiglia

    Risultati letti insieme a trace, metriche e profili in Grafana, Datadog, New Relic o Application Insights, così che una risposta lenta venga ricondotta alla query, al lock, al thread pool o alla chiamata esterna che la causa, e ogni correzione venga ritestata con lo stesso carico.

  • Capacity planning per lanci e picchi

    Test di carico dimensionati per un lancio, un picco di vendite o una campagna, con numero di istanze e limiti di autoscaling che reggono quel carico messi per iscritto e il costo di funzionamento al picco stimato prima del giorno in questione.

  • Performance del front end e Core Web Vitals

    Largest Contentful Paint, Interaction to Next Paint e Cumulative Layout Shift monitorati dai dati sul campo degli utenti reali, con Lighthouse e WebPageTest in laboratorio per individuare la causa, e poi migliorati con interventi su immagini, script, font e caching.

  • Test di performance nella CI

    Brevi test di carico con soglie di superamento e di fallimento a ogni release in GitHub Actions, GitLab CI o Azure Pipelines, esecuzioni più ampie in Grafana Cloud k6, Azure Load Testing o BlazeMeter, e ogni esecuzione confrontata con la build precedente, così che una regressione venga intercettata prima che gli utenti la percepiscano.

  • Test di resilienza e di failover

    Istanze, zone e dipendenze messe fuori servizio sotto carico con AWS Fault Injection Service, Azure Chaos Studio o Chaos Mesh, per verificare che failover, tentativi ripetuti e circuit breaker funzionino e che il ripristino rispetti l’obiettivo.

Ingaggiare performance engineer

  • performance engineer dedicati

    Performance engineer che entrano a tempo pieno nel Suo team, lavorano con i Suoi strumenti e il Suo processo e rispondono al Suo responsabile. Li intervista Lei; noi ci occupiamo del contratto ucraino, delle buste paga, della fatturazione e delle ferie.

  • Progetti di Test di performance

    Un’attività di test di performance ben definita, con un perimetro, un piano fisso e un responsabile nominato da parte nostra che risponde del risultato e riferisce sull’avanzamento nei Suoi canali.

  • test di performance su base continuativa

    Test di performance come servizio continuativo: le stesse persone ogni mese, un backlog di cui Lei stabilisce le priorità e ore che può vedere nel nostro portale e in fattura.

La pagina sul team dedicato spiega come gli specialisti entrano nel Suo team, e la pagina sull’outsourcing tratta la realizzazione di progetti, le prese in carico e il modo in cui fatturiamo.

Chi si occupa di test di performance per Lei

  • Performance engineer

    Modelli di carico, script e analisi

  • Site reliability engineer

    Monitoraggio, autoscaling e capacità

  • Sviluppatori backend

    Correzioni in codice, query e caching

  • Amministratori di database

    Piani di esecuzione, indici e limiti di connessione

  • Sviluppatori front end

    Miglioramenti dei Core Web Vitals

Come eseguiamo i test di performance

Ogni test parte da un obiettivo scritto: il numero di utenti o di richieste, il tempo di risposta al 95º o al 99º percentile, il tasso di errore accettabile e il costo. Il carico è modellato sul traffico di produzione, i dati di test sono generati con volumi di produzione e il test gira su un ambiente dimensionato come la produzione, oppure sulla produzione stessa in una finestra concordata.

I risultati arrivano con una spiegazione, non solo con un grafico: quale componente ha raggiunto il limite, perché e quale modifica lo sposta, con ogni correzione confermata da una nuova esecuzione con lo stesso carico. Script, generatori di dati e soglie restano nel Suo repository, così il Suo team può eseguire gli stessi test prima di ogni release.

Altri servizi di software testing

Panoramica: Software testing e QA

Domande sui test di performance e di carico

In quali settori lavorano i vostri performance engineer?

Soprattutto e-commerce e retail, prima di picchi di vendita e campagne; fintech e banche, dove i sistemi di pagamento e di trading hanno obiettivi di latenza; prodotti SaaS enterprise che acquisiscono clienti più grandi; servizi media e di streaming il cui traffico arriva tutto insieme; e operatori di telecomunicazioni, cloud e hosting che dimensionano le proprie piattaforme.

Potete eseguire test di carico in produzione?

Sì, quando lo staging non può riprodurre il sistema reale. Il test si svolge in una finestra concordata a basso traffico, aumenta il carico per gradi con condizioni di arresto su tasso di errore e latenza, usa account e dati di test che vengono rimossi al termine e ha un referente indicato per nome da ciascuna parte che lo segue.

k6, JMeter o Gatling?

k6 per la maggior parte dei nuovi lavori: i test si scrivono in JavaScript, si eseguono da riga di comando e si adattano a una pipeline. JMeter dove esistono già piani di test o il protocollo non è HTTP, come JDBC, JMS o TCP puro. Gatling per i team che lavorano in Java o TypeScript e Locust per i team Python. Lavoriamo anche con lo strumento che il Suo team usa già.

Con quale rapidità possono iniziare performance engineer?

Quando è disponibile il profilo giusto per il ruolo di performance engineer, l’avvio dipende soltanto dal Suo colloquio e dalla firma dell’NDA e della cessione della proprietà intellettuale. Altrimenti avviamo una ricerca, che di norma produce profili di candidati entro due o tre settimane, e nessuno inizia finché Lei non ha detto di sì.

Come ingaggiare performance engineer tramite BigTree108?

Ci indichi il lavoro, il livello di seniority e l’impegno orario necessario. Le proponiamo una o due persone con i rispettivi profili, Lei le intervista come farebbe con una Sua assunzione e firma un unico contratto con BIG TREE 108 LLC, ricevendo una sola fattura al mese.

A chi appartiene il lavoro che producono?

A Lei. Ogni specialista ha un contratto firmato con BigTree108 che cede all’azienda tutto il lavoro prodotto, e il nostro accordo con Lei lo cede a sua volta. Codice, design e documenti vengono consegnati nei Suoi repository e strumenti, non conservati dove solo noi possiamo modificarli.

Si aspetta più traffico?

Ci indichi che cosa fa il sistema, quanto traffico riceve oggi e quanto ne prevede. Riceverà una risposta entro un giorno lavorativo: un piano di test con gli obiettivi, profili di candidati o il perimetro di un primo test di carico.

Scrivere a hello@bigtree108.comCome rispondiamo