Sito web Arcade Database

[motoschifo]

Ho pubblicato un aggiornamento che mi ha impegnato le ultime due settimane, sperando di risolvere in parte il problema scraping ed alleggerire il carico del server.
Si tratta di un sistema di cache dei dati ottenuti dalle chiamate api.
All'apparenza semplice, l'algoritmo si complica quando ci sono in gioco tante variabili e possibilità.
La generazione di questa cache dura diverse ore, quindi valuterò quando farlo in base agli aggiornamenti che applicherò ai dati.

Spero di non aver introdotto errori, nel caso fatemelo sapere.

[motoschifo]

L'aggiornamento ha risolto in parte i problemi di performance, nel senso che l'elaborazione server (api) è sostanzialmente stata azzerata (ci sono ancora margini di miglioramento ma il grosso è stato fatto).
La rigenerazione di questa cache richiede purtroppo alcune ore, oltre ad utilizzare 250 mila file temporanei sul server e circa 1GB di disco. Ma non sipuò avere tutto.

In aprile continuerò con la sostituzione del sorgente di alcune routine pesanti, sempre in ambito api, mentre da giugno riprenderò i lavori di rifacimento del sito.
Mi sembrava di aver concluso la nuova gestione filtri (almeno dal punto di vista tecnico) ma in realtà non mi soddisfa del tutto e quindi dovrò lavorarci ancora... ci vorrà tanto tempo, ma prima o poi spero di chiudere qualcosa (fine anno è molto vicino, probabilmente si andrà al prossimo).

Dai grafici vedo che gli accessi sono aumentati e le api incidono solo un 10% rispetto al 90% di prima. In effetti il sito è molto più scarico e consultabile anche dall'utente.
Il picco è di 1.6 milioni di richieste giornaliere, con una media del mese di 1 milione/giorno. Per avere un paragone, lo scorso anno eravamo sui 500 mila/giorno.
La strada è ancora lunga, quando ci sono numeri così alti la normale ottimizzazione dei processi non basta, serve qualcosa di più e richiede ovviamente più tempo per la realizzazione (soprattutto per i test). Probabilmente in futuro dovrò fare in modo di usare il meno possibile la parte database/cpu e lavorare solo su file in cache, anche parziali, e quindi concentrare gli aggiornamenti di tutti i file in un solo momento per rigenerare una sola volta al mese tutte queste cache sparse nel sito. Una volta raggiunto questo risultato, la rigenerazione potrebbe in realtà avvenire su un altro pc (es. quello di casa) e potrei poi caricare tutte le modifiche senza alcun problema di performance.
La strada è ancora lunga, comunque sono tutte questioni molto tecniche che interessano poco l'utente finale...

[Gothrek]

l'utente finale no, ma se lato api porti cambiamenti mi interessano particolarmente.

finalmente gotscraper comincia ad essere scaricato (ancora lentamente ma va).

Lato mio al momento è ancora poco, storicamente ad adb gotscraper ha fatto circa 700K chiamate.

Sogno sempre con l'avere a disposizione via api tutta una serie di info che al momento sono costretto a consultare one by one da sito.

grazie moto.

[motoschifo]

Dato che in questi giorni ho ricevuto parecchie segnalazioni di sito down, ho controllato la situazione e non ho visto errori.
Credo sia dovuto all'eccessivo carico del server.

Spulciando tra i log ho visto che le api, dopo la mia modifica di un mesetto fa, sono messe molto bene. Certo ora il problema potrebbe essere la banda totale a disposizione, ma lato cpu la macchina è quasi completamente scarica (almeno per le api).

L'altro grande tema che impegna cpu e disco è quello delle esportazioni.
Oggi per esempio qualcuno ha ritentato la stessa esportazione, circa 10 mila giochi, per ben 9 volte per un totale di 4 ore cpu circa.
Voglio sperare che sia stato un bot o un programma a farlo, perchè ritentare dopo 30 minuti la stessa operazione per tutta la giornata sarebbe davvero un grande spreco di tempo.
A parte ciò che posso pensare su questa cosa, prima o poi dovrò intervenire anche sugli export e disaccoppiare il processo in modo da renderlo più flessibile.
Potrei inoltre tenere il conto e procedere solo se il server è in grado di supportare il carico, per esempio 20 export contemporanei e gli altri in coda o qualcosa del genere.

Intanto vedo se riesco a bloccare qualcosa per dargli un pochino di respiro.

[motoschifo]

Ho chiuso tutto per un minuto in modo da capire se ci fossero problemi tecnici, il sito da quel momento è tornato online senza intoppi.
Ci sono molte richieste (scraper) e dai log vedo che sono per la maggior parte anche richieste inutili, perchè i giochi chiaramente non sono del Mame (c'è pure l'estensione .NES nel nome della rom) quindi non saranno mai presenti all'interno del database.
Secondo me qualcuno ha confuso il servizio con un altro, forse credeva che buttando a caso l'elenco di file di una cartella si riuscisse magicamente a scoprire l'immagine del gioco.

Non vedendo anomalie, ma solo tanto traffico, direi che il sito ha raggiunto il suo limite. Rispetto allo scorso ottobre, dove il vincolo era rappresentato dall'elaborazione per caricare i dati e dove poteva servire al massimo 800 mila richieste di risorse al giorno, oggi vedo che ci sono picchi del doppio e quindi direi che siamo arrivati a saturare il server.

Terrò controllata la situazione, poi deciderò come intervenire per poter rendere il sito fruibile senza i ritardi che ci sono ora.

[Gothrek]

nei miei deliri mi piacerebbe pensare che per fare scraping da adb ci si debba regisrare, cosi da permettere a tutti di godere della propria fetta di scraping

[motoschifo]

Anche se potrebbe sembrare una soluzione, non durerebbe a lungo.
Registrarsi è molto semplice, anzi esiste anche una funzione per fare la prova di una settimana senza inserire nemmeno un dato, quindi nemmeno la mail.
E comunque sia, anche se tutti gli utenti di oggi fossero registrati, sarebbero comunque troppi.
Devo ragionarci sopra ma limiterò le chiamate api giornaliere per indirizzo ip e troverò il modo di rendere questo limite dinamico/automatico come già fatto per altri aspetti, in modo da intervenire solo nel caso in cui ci sia davvero mancanza di risorse.

Infatti mentre le api vengono spesso lanciate e "dimenticate", quindi possono anche ore, l'utente che cerca i suoi 10 giochi e magari salva la lista personale riceverà un timeout e quindi non potrà fare proprio nulla.
Io stesso ricevo avvisi di sito down e poi up quando succedono queste cose, e sono tutti falsi allarmi in quanto il server gode di ottima salute (nel senso che non ci sono errori tecnici, è solo troppo piccolo per poter servire tutti).

La priorità deve andare agli utenti perchè sono davanti al monitor ad aspettare la risposta, non a servizi batch che sta spulciando un intero hard disk di 500 mila file e di cui magari solo 10 mila del Mame.
Ad esempio le esportazioni con molti giochi saranno un processo disaccoppiato, si riceverà l'avviso che il job è in lavorazione e fino alla conclusione non sarà possibile sottomettere altre esportazioni.
Come vedo fare a quasi tutti i siti ad alto traffico (es. discogs).

Sicuramente con il nuovo sito avremo meno impegno lato cpu, ma la banda viene impiegata principalmente per scaricare le risorse quindi le cose non potranno risolversi da sole. Basta mettersi in coda e c'è posto per tutti.

Limiterò le chiamate giornaliere totali e per chi fa troppi errori, quindi se arrivano 100 chiamate di romset non trovati, stai usando male un servizio che qualcuno invece potrebbe usare meglio.
Stessa cosa se chiami continuamente nella stessa settimana, o qualcosa del genere.
Ovviamente queste chiamate saranno rifiutate nei momenti con picchi di carico come succede in questi giorni.

La strada è questa, non ho ancora i dettagli perchè devo trovare il modo di avere i minor impatto lato server (anche contare le richieste sbagliate ha un costo, che andrà a sommarsi al carico totale, quindi devo dosare molto bene questi controlli).
Se riesco faccio qualcosa prima della fine del mese, se vedo che non ce la faccio limiterò il totale api giornaliero e poi man mano aggiusterò il tiro.

[motoschifo]

Per adesso chi chiama le api di scraping con nomi non corretti (in pratica tutto ciò che non è numeri, lettere, underscore, trattino) o con nome del gioco superiore a 50 caratteri, riceve un errore 400 bad request e non va oltre.
Questo dovrebbe tamponare un attimo le richieste inutili, vedo che ce ne sono davvero tante.

[Gothrek]

Per adesso chi chiama le api di scraping con nomi non corretti (in pratica tutto ciò che non è numeri, lettere, underscore, trattino) o con nome del gioco superiore a 50 caratteri, riceve un errore 400 bad request e non va oltre.
Questo dovrebbe tamponare un attimo le richieste inutili, vedo che ce ne sono davvero tante.

ok 400, sarebbe bello avere (non mi ricordo se l'avevi pubblicata già), una tabellina con le risposte cosi da gestirle correttamente.

latomio potrei evitare di passare qualuqneu cosa non sia:
zip 7z? corretto?
max 50 chars?

prima circa la registrazione mi riferivo ad integrazione con arcadeitalia dove la mail è registrata e convalidata, e magari anche numero min di post?

[motoschifo]

Non credo ci sia la tabellina degli errori, non ricordo, comunque sono sempre risposte standard html:
https://developer.mozilla.org/en-US/doc ... TTP/Status

Per i file, se non è un nome di romset compatibile andrebbe ignorato in partenza, mi riferisco a file con spazi, simboli o superiori a 50 caratteri. Questo perchè nessuna risposta potrà mai arrivare da quei file, quindi è sbagliato insistere a chiamare un servizio quando sai che non arriverà mai un contenuto.
Ovviamente questo si applica alla funzione query_mame, magari altre in futuro potranno accettare caratteri diversi.

In caso di richiesta multipla, anche un solo nome sbagliato invalida tutto, perchè vuol dire che non stai facendo controlli sulla chiamata e quindi è una pratica da disincentivare.
Nel dettaglio abbiamo errori per:
- lunghezza romset oltre 50 caratteri
- contenenti spazio
- contenenti slash, backslash o punteggiatura

In pratica tutto ciò che è diverso da A-Z, 0-9, underscore.
Il trattino non viene considerato valido, ricordavo male io.

Per l'integrazione con l'account del forum non abbiamo mai portato avanti il discorso, diciamo che andrebbe validato e che dovrei gestire un'abilitazione speciale ma per tutti quelli che non parlano l'italiano sarebbe uno step inutile e controproducente. Infatti avere 2 mila utenti in più nel forum non attivi non porterebbe a dei vantaggi pratici.

[motoschifo]

Sto spulciando le modalità di accesso al sito web, ed ho scoperto che ciclicamente (tutti i giorni) ci sono accessi continui alle pagine di dettaglio del Mame.
I parametri che vedo sono troppi particolari per essere fatti da una persona, sono temporizzati ogni 1-2 secondi e in alcuni giorni anche 20 volte di seguito.
Potrebbe trattarsi del crawler di Google o di uno spider, anche se probabilmente Google utilizza uno user agent diverso e nessuna connessione casalinga con ip dinamico.
Ad ogni modo meglio poter vedere il sito che averlo indicizzato, anche perchè se ricordo bene le indicizzazioni sono molto più discrete e smettono subito se vedono un tempo di accesso lungo.

Ho imposto un limite a 200 schede richieste al giorno, oltre il quale non si può far altro se non attendere il giorno dopo.
Gli scraper non hanno subito modifiche.

Raccolgo qualche statistica e vedo cosa succede, specialmente per capire se è questo che fa rallentare eccessivamente il sito oppure se il problema è altrove.
La pagina è una delle più complesse e "costose", non ha alcun senso per un programma caricare quella quando c'è a disposizione uno scraper fatto appositamente per quello scopo.

[motoschifo]

Intanto che preparavo il messaggio ho controllato e in meno di 1 ora dalla modifica abbiamo ben 25 mila accessi oltre la soglia, quindi non si tratta di certo di utenti.
Sul versante api, le chiamate ignorate (quindi romset con spazi, simboli, ecc.) sono circa 100 mila.

[motoschifo]

Ormai è passato un giorno e vedo che il sito è tornato funzionante.
Le pagine non servite per errori (nomi sbagliati in input) sono 350 mila circa, segno che qualche programma o qualche utente sbaglia a prendere i file.
Le pagine invece non servite per limiti di banda sono 1.300.000. Fino ad oggi il picco di carico è stato di 3 milioni di richieste totali (scraper e pagine) a cui andrebbero sommate questo milione e spiccioli che non considero visite ovviamente.
Probabilmente abbiamo capito il motivo del rallentamento degli ultimi mesi, cercherò di capire come rimuovere il limite sugli utenti e inasprire quello sui programmi che chiedono pagine.

Ovviamente l'elaborazione di queste richieste ha un costo, tutt'altro che trascurabile, ma se lo paragoniamo al dispendio di risorse per completare l'operazione è molto piccolo.

Tra una settimana ricontrollo.

[Gothrek]

@motoschifo
non so coem funzionano gli scraper dei vari frontend, ma cosi all'apparenza sembrerebbe che una volta selezionato un sito, lo utilizzi per tutte le rom di tutti i sistemi, questo potrebbe essere la causa della mole di richieste "inutili"

lato gotscraper, a parte le modifiche che apporterò grazie alle tue indicazioni ad oggi, adb viene configurato come primo scraper su mame e sistemi vari arcade, per demandare a screenscraper l'onere e l'onore degli altri.

tra le varie speranze/fantasie legate alla registrazione, potrebbe esserci anche l'info del "residuo" (sistema permettendo), cosi da poter dar contezza all'utilizzatore. Tra l'altro una volta fatto scraping, salvo tutto in locale, pertanto se il file suo (o di tutti i suoi cloni) esiste già in locale, non chiamo proprio adb

[motoschifo]

Le chiamate api in genere non hanno molte regole, si possono usare i metodi get o post in base al tipo e alla mole di dati da leggere o scrivere, si può usare un token per l'autenticazione e per crearsi un profilo sul server, ecc.
Si può fare insomma tutto, ma per ora ADB supporta esclusivamente il MAME e non credo che la situazione possa migliorare nel prossimo futuro. Eventualmente aggiungerò tutta la parte ex-MESS, ma in quel caso potrebbe diventare problematico trovare il sistema esatto e magari servono ricerche più aperte.
Ad ogni modo se chiamo per avere un gioco non valido, ricevo un errore anzichè una risposta valida quindi non ci sono ban o divieti e posso subito dopo tentare con altre rom.

Le chiamate api non sono un problema, anzi sono un ottimo modo per snellire il processo perchè fanno parlare i due programmi (client e server) e non ci sono strati inutili come un render html che deve essere rappresentato su uno schermo per un utente (e che poi invece legge un programma). La pagina di dettaglio Mame è la più complessa e completa, ma proprio perchè si tratta di dati che deve leggere un utente.

In futuro dovrò per forza aggiungere nuove chiamate e magari più complesse/particolari, in modo da poter avere un sistema meglio tarato per il software. Ad esempio si potrebbe fare un login iniziale, preparare un setup custom (campi da ottenere in output) e fare poi tutte le chiamate senza dare ogni volta parametri in input a parte il romset.

Invece, cosa intendi per residuo?

[motoschifo]

lato gotscraper, a parte le modifiche che apporterò grazie alle tue indicazioni ad oggi, adb viene configurato come primo scraper su mame e sistemi vari arcade, per demandare a screenscraper l'onere e l'onore degli altri.

Tutti i programmi, dal più inutile al più perfetto, devono per forza di cose utilizzare cache e metodi per evitare chiamate verso internet o anche verso altri computer in lan.
Dato che le risorse locali sono enormi, anche su sistemi come i Raspberry, è uno spreco di risorse chiedere sempre ad altre macchine di fare le cose che hai fatto pochi minuti prima.
Il server ora ha un sistema di cache estremo per le api, che consumano risorse (cpu, hard disk, programmazione mia php) ma che si rende fondamentale perchè la gente "se ne frega".

Ovviamente non è una critica nei tuoi confronti, anzi sei uno dei pochi che ha chiesto info prima di distribuire a tutti script male ottimizzati, solo che spesso non ci si ferma a riflettere abbastanza su questi aspetti.
Se io che scrivo uno scraper ho poco tempo e lo faccio "male", rischio di danneggiare tutti gli utenti perchè il server sarà bersagliato inutilmente e quindi paradossalmente potrei distruggere il servizio per il quale scrivo lo script.
Sono sicuro che tutte le mie elucubrazioni sul capire chi/come/cosa fanno gli utenti, tenere traccia tramite log messi manualmente (tutt'altro che semplici e rapidi da controllare) e confronti come questo, siano l'eccezione e non la regola. Spesso per risolvere basta chiudere i rubinetti, mettere un canone al servizio e con i soldi che si ottengono aggiungi hardware.

[Gothrek]

lato gotscraper, a parte le modifiche che apporterò grazie alle tue indicazioni ad oggi, adb viene configurato come primo scraper su mame e sistemi vari arcade, per demandare a screenscraper l'onere e l'onore degli altri.

Tutti i programmi, dal più inutile al più perfetto, devono per forza di cose utilizzare cache e metodi per evitare chiamate verso internet o anche verso altri computer in lan.
Dato che le risorse locali sono enormi, anche su sistemi come i Raspberry, è uno spreco di risorse chiedere sempre ad altre macchine di fare le cose che hai fatto pochi minuti prima.
Il server ora ha un sistema di cache estremo per le api, che consumano risorse (cpu, hard disk, programmazione mia php) ma che si rende fondamentale perchè la gente "se ne frega".

Ovviamente non è una critica nei tuoi confronti, anzi sei uno dei pochi che ha chiesto info prima di distribuire a tutti script male ottimizzati, solo che spesso non ci si ferma a riflettere abbastanza su questi aspetti.
Se io che scrivo uno scraper ho poco tempo e lo faccio "male", rischio di danneggiare tutti gli utenti perchè il server sarà bersagliato inutilmente e quindi paradossalmente potrei distruggere il servizio per il quale scrivo lo script.
Sono sicuro che tutte le mie elucubrazioni sul capire chi/come/cosa fanno gli utenti, tenere traccia tramite log messi manualmente (tutt'altro che semplici e rapidi da controllare) e confronti come questo, siano l'eccezione e non la regola. Spesso per risolvere basta chiudere i rubinetti, mettere un canone al servizio e con i soldi che si ottengono aggiungi hardware.

ogni info sulle api dello scraper sono sempre interessanti, cosi come le aggiunte che hai fatto nel corso del tempo, è interesse di tutti quando si crea qualcosa farlo funzionare al meglio.

sul mettere un canone al servizio per aggiungere hw, era sempre nell'elenco di tempo fa quando si parlava del tema.
un sistema che in parte tuteli tutti, dall'altra dia la possibilità di monitorare e di utilizzare i ricavi del servizio per migliroare il servizio stesso sono vie assolutamente condivisibili.

[idro]

Io da questo progetto non smetto mai di scoprire funzionalità.
Ho visto che nel tab "Altro" dei filtri aggiuntivi, c'è la possibilità di scegliere solo quei cloni che prevedono 4 giocatori (quindi cloni il cui parent/gioco originale era stato concepito per averne uno solo immagino).
Ho applicato questo filtro e ho visto da controlli a campione che in realtà questi cloni ne prevedono FINO a 4 di giocatori, ovvero giocatore singolo, 2 e 4 giocatori.
Ora non so se sono tutti così, ma se lo fosse posso umilmente consigliare di aggiungere quella parola nel filtro, altrimenti sembra che si tratti di cloni con SOLO 4 giocatori.

Poi dimmi tu che il progetto l'hai sviluppato e lo saprai meglio di me.

Altra osservazione: sarebbe interessante ampliare la scelta di filtri di questo tipo sui cloni, mi viene da pensare alla lingua.
Faccio un esempio: c'è un gioco fighissimo, un parent, con cui non posso fare a meno di giocare ma ahimé è scritto in giapponese. Sarebbe utile avere un clone in italiano oppure in inglese (se esistono ovviamente) o entrambi, così alcune cose le capisco di più.
PS: ovvio che ho preso le due lingue alternative al giapponese per noi italiani che usiamo ADB :DDD

[cybermat]

Faccio un esempio: c'è un gioco fighissimo, un parent, con cui non posso fare a meno di giocare ma ahimé è scritto in giapponese.

Impari il GIapponese se non puoi farne a meno

Questa cosa dei filtri ulteriori interessa anche a me.

[motoschifo]

Ho visto che nel tab "Altro" dei filtri aggiuntivi, c'è la possibilità di scegliere solo quei cloni che prevedono 4 giocatori (quindi cloni il cui parent/gioco originale era stato concepito per averne uno solo immagino).
Ho applicato questo filtro e ho visto da controlli a campione che in realtà questi cloni ne prevedono FINO a 4 di giocatori, ovvero giocatore singolo, 2 e 4 giocatori.
Ora non so se sono tutti così, ma se lo fosse posso umilmente consigliare di aggiungere quella parola nel filtro, altrimenti sembra che si tratti di cloni con SOLO 4 giocatori.

Il filtro fa ciò che dice, ovvero controlla se il romset supporta 4 giocatori simultanei. Poi, se gestisce anche 1, 2, 8 non cambia le cose, ma dovrebbero essere garantiti i 4 in contemporanea.
Il file nplayers.ini, da cui sono presi questi dati, è da un po' che non viene aggiornato comunque in caso di errori potete contattare direttamente l'autore oppure scrivere a me che giro la segnalazione a lui.
Le ultime mail che gli ho scritto non hanno mai ricevuto risposta, spero che quel file non venga abbandonato.
https://nplayers.arcadebelgium.be/

La dicitura che trovi nella scheda indica una parte riassuntiva ed una più completa, entrambe comunque sono create a partire da tutte le combinazioni possibili del numero di giocatori. Il Mame non da queste informazioni, senza il file ini di altri non avresti nemmeno queste possibilità di filtro.
Es: "Fino a 4 giocatori (singolo, 2-4 contemporanei)" ha una prima parte che riassume genericamente che si può giocare fino a 4 persone, la seconda invece specifica singolo oppure da 2 a 4 giocatori insieme (quindi anche in 3, che viene contratto in 2-4). In questo caso non potrai giocarci in 2, 3 o 4 persone a rotazione (quando muore uno tocca all'altro).

Altra osservazione: sarebbe interessante ampliare la scelta di filtri di questo tipo sui cloni, mi viene da pensare alla lingua.
Faccio un esempio: c'è un gioco fighissimo, un parent, con cui non posso fare a meno di giocare ma ahimé è scritto in giapponese. Sarebbe utile avere un clone in italiano oppure in inglese (se esistono ovviamente) o entrambi, così alcune cose le capisco di più.

Al momento non posso aggiungere più filtri alle pagine, è complesso gestirli senza appesantire ancora di più il sito.
Nella nuova versione, oltre ad un ampliamento "esagerato" di tutti i filtri, potremo anche gestire casi più speciali come quello che hai indicato. Certo non sarà semplice farlo ma se lo aggiungo almeno non penalizzo tutti ma solo chi usa quella ricerca.