Sito web Arcade Database

[AntoPISA]

GIà che stai facendo tutti questi lavori al sito (che apprezzo moltissimo) mi manderesti l'elenco delle macchine prive di immagini (escluso le SL)? Avrei intenzione di colmare le llacune, onde evitare che una ricerca effettuata su ADB mostri niente come risultato.
Inoltre vorrei sapere se in futuro tali ricerche più complesse saranno estese alle liste software.

[Gothrek]

@motoschifo @AntoPISA

che coppia ragazzi!!!

[motoschifo]

GIà che stai facendo tutti questi lavori al sito (che apprezzo moltissimo) mi manderesti l'elenco delle macchine prive di immagini (escluso le SL)? Avrei intenzione di colmare le llacune, onde evitare che una ricerca effettuata su ADB mostri niente come risultato.
Inoltre vorrei sapere se in futuro tali ricerche più complesse saranno estese alle liste software.

Puoi cercarle usando i filtri avanzati (Extra / Immagini) e scegliere quale delle immagini considerare tra tutte quelle supportate:
Senza immagine del gioco
Senza immagine del titolo
Ovviamente puoi aggiungere tutti i filtri che vuoi, l'importante è togliere quelli che potrebbero dare fastidio (tipo ultima release e solo mamecab).

Prima di un eventuale aggiornamento dovrò rivedere ogni pagina del sito, è cambiata la struttura interna quindi anche la ricerca software list dovrà usare quel tipo di condizioni.

[AntoPISA]

Grazie per i link alle ricerche (che probabilmente tempo fa mi avevi già dato), appena ho un po' di tempo controllo.

[motoschifo]

Sono sempre più vicino al risultato, nello specifico ho potuto pensare ad una gestione migliore usando dei blocchi per inserire le condizioni in AND (quindi condizioni tutte valide tra di loro) e in OR (almeno una valida).
Per esempio qualcosa del genere:

Screenshot from 2023-01-15 09-46-55.png

Screenshot from 2023-01-15 09-49-39.png

Non sono ancora ad un punto finale perchè questo tipo di gestione "rompe" completamente gli schemi di oggi, ossia sono costretto a non usare più i parametri che usavo prima e così dovrò in qualche modo gestire ugualmente la compatibilità con il passato e la gestione lato browser.
In pratica gestire link del tipo /mame-search?game_year=1980&genre=100

In realtà non potranno essere composti in quel modo perchè non riuscirei a gestire tutte le casistiche, e la rottura sta proprio qui.
Per spiegarla a chi non è tecnico, diciamo che quando viene servita una pagina web esiste la lista dei parametri in ingresso (es. 'game_year' con valore '1980' e 'genre' con valore '100') ed oggi da quella lista genero una ricerca sul database. Il problema sta proprio nel fatto che la lista nel mio caso potrebbe avere più valori uguali e per ciascun valore potrebbe avere una diversa operazione sul dato (uguale, maggiore, ecc).
Fino a questo momento ho gestito la cosa cambiando il nome, nella maniera standard in cui fanno tutti i siti, ovvero gestire fino a 10 nomi diversi per ciascun parametro (game_year_maggiore, game_year_maggiore_uguale, game_year_diverso, genre_diverso, ecc.)
Questo però porta alla moltiplicazione di tutti i filtri (150 oggi, 200 domani) per le 10 operazioni, ovvero 2000 variabili diverse. Troppe da gestire senza incontrare problemi.
La strada che sto percorrendo ora è che la lista dei parametri viene processata da una routine che la trasforma nei nuovi, passati poi al client (quindi la pagina è vuota) che a sua volta richiama il server con i parametri corretti per poter effettuare la ricerca (contenuto dinamico).
Così facendo avrei una pagina di ricerca molto pulita e leggera a prescindere dal numero di filtri (poche migliaia di byte rispetto al quasi milione di byte di oggi), un preprocessore che si occupa di trattare i dati e trasformarli in parametri corretti (solo la prima volta che la pagina viene aperta) ed una richiesta dati che potrebbe mettere in cache la composizione finale.
In altre parole, la richiesta delle pagine 2 e 3 non andrebbe a riprocessare tutti i parametri (lavoro inutile se sono uguali a prima) e avrei una risposta molto più rapida (come succede oggi che ho milioni di richieste).

Sono entrato nel tecnico ma si rende necessario per capire e spiegare le varie scelte che sto effettuando.

La grafica non mi piace ancora comunque, sto cercando di gestire il multivalore in maniera più chiara.
Se questo tipo di rappresentazione funziona bene, potrei gestire per qualsiasi filtri supportato un elenco di operazioni e valori multipli senza alcuno sforzo aggiuntivo rispetto alla gestione singola, e tutto ciò consentirebbe in pratica di farsi le proprie ricerche con la massima libertà possibile.
Che poi è lo scopo primario di questa riscrittura, quello secondario è ridurre il carico sul server che già oggi fa fatica a rispondere a tutti.

[AntoPISA]

Sto effettuando delle ricerche (semplici) su ADB e la risposta del sito è lentissima. E' normale Michele?

[motoschifo]

Gli accessi sono aumentati, il server è sempre pieno di richieste e ci sono momenti in cui non risponde proprio.
La revisione che sto facendo dovrebbe alleggerire anche il carico complessivo, nel frattempo non ho soluzioni immediate quindi l'unica è riprovare.
Se vedo che non si stabilizza posso interrompere gli scraper ma preferirei non arrivare a tanto.

[motoschifo]

Oggi ho visto che il server si è "seduto" per le tante richieste, unite anche alle elaborazioni pesanti che sto cercando di migliorare riscrivendo tutto il sito. Ma questo arriverà più avanti.

Ho quindi fatto qualche indagine per capirne la causa ed ho visto che il recupero info da programmi esterni (scraping) non è gestito bene.
In poche ore di attività ho visto 300 mila richieste di giochi diversi (a volte lo stesso gioco dallo stesso ip, forse un errore di programmazione di qualcuno o un programma lanciato più volte).
Io ho scritto dappertutto che è consigliato, quando possibile, unire le richieste e magari ottenere dati su più giochi insieme e limitare il numero di connessioni totali allo stretto necessario, ma vedo che in pratica nessuno lo fa.
Così ho deciso in futuro di chiudere dei pezzi e limitare l'accesso ad un massimo giornaliero per indirizzo ip.

Oggi sto solo raccogliendo dati, ma il prossimo aggiornamento introdurrà questo tetto massimo di richieste per giornata.
Potrei impostarlo inizialmente a 30 mila e ridurlo poi man mano fino a 5 mila.
Ad esempio un set completo del Mame, ammesso che uno voglia averlo tutto (e già questo è discutibile, dato che si dovrebbe cercare sempre di andare per upgrade progressivi), "costa" fino a 50 mila richieste. Accodandole per gruppi di 400 giochi alla volta si ottiene un valore prossimo al centinaio, che è molto più gestibile e mi viene da dire anche più veloce per chi lo utilizza.
Quindi, anzichè scandagliare tutto ogni volta, bastarebbe gestire la data di ultima richiesta, farne al massimo 1 al giorno (quindi cache sul client) e unire tutte le richieste in uscita in poche chiamate cumulative.

Non ho deciso i dettagli, l'idea è questa e nei prossimi giorni dovrò lavorare al database per manutenzione ordinaria quindi il tutto rallenterà un pochino più del solito.
In ottica futura sto comunque rendendo le pagine e le elaborazioni molto più leggere (o meglio più "intelligenti") per avere meno carico possibile sul server e sul database. In pratica, con l'hardware attuale, si dovrebbe vedere un bel salto in qualità e velocità anche all'aumentare degli utenti. Ma di questo ne riparliamo a natale... spero...

[Gothrek]

Oggi ho visto che il server si è "seduto" per le tante richieste, unite anche alle elaborazioni pesanti che sto cercando di migliorare riscrivendo tutto il sito. Ma questo arriverà più avanti.

Ho quindi fatto qualche indagine per capirne la causa ed ho visto che il recupero info da programmi esterni (scraping) non è gestito bene.
In poche ore di attività ho visto 300 mila richieste di giochi diversi (a volte lo stesso gioco dallo stesso ip, forse un errore di programmazione di qualcuno o un programma lanciato più volte).
Io ho scritto dappertutto che è consigliato, quando possibile, unire le richieste e magari ottenere dati su più giochi insieme e limitare il numero di connessioni totali allo stretto necessario, ma vedo che in pratica nessuno lo fa.
Così ho deciso in futuro di chiudere dei pezzi e limitare l'accesso ad un massimo giornaliero per indirizzo ip.

Oggi sto solo raccogliendo dati, ma il prossimo aggiornamento introdurrà questo tetto massimo di richieste per giornata.
Potrei impostarlo inizialmente a 30 mila e ridurlo poi man mano fino a 5 mila.
Ad esempio un set completo del Mame, ammesso che uno voglia averlo tutto (e già questo è discutibile, dato che si dovrebbe cercare sempre di andare per upgrade progressivi), "costa" fino a 50 mila richieste. Accodandole per gruppi di 400 giochi alla volta si ottiene un valore prossimo al centinaio, che è molto più gestibile e mi viene da dire anche più veloce per chi lo utilizza.
Quindi, anzichè scandagliare tutto ogni volta, bastarebbe gestire la data di ultima richiesta, farne al massimo 1 al giorno (quindi cache sul client) e unire tutte le richieste in uscita in poche chiamate cumulative.

Non ho deciso i dettagli, l'idea è questa e nei prossimi giorni dovrò lavorare al database per manutenzione ordinaria quindi il tutto rallenterà un pochino più del solito.
In ottica futura sto comunque rendendo le pagine e le elaborazioni molto più leggere (o meglio più "intelligenti") per avere meno carico possibile sul server e sul database. In pratica, con l'hardware attuale, si dovrebbe vedere un bel salto in qualità e velocità anche all'aumentare degli utenti. Ma di questo ne riparliamo a natale... spero...

noooooooooooooooo

resto sempre piu' convinto che la soluzione sia diversificare, un unregistred castrato , un registred e un donatore, trattare in egualmodo il tipo che scrapa da una distro da un utente dei AI sarebbe un peccato.

tutte le distro fanno richieste 1 a 1 (anche il gotscraper aime), ma mettere insieme 400 titoli e gestire il result non è cosi lineare, interruzioni a metà e quant'altro. ma quello che ad esempio faccio col gotscrpaer e NON andare online da te se hai già le info in locale perchè scaricate 1 volta, quindi questo dovrebbe evitare che chi ha già un set completo (per dire), all'uscita di una nuova versione i titoli da cercare saranno davvero pochi.

tra l'altro ho aggiunto oramai da un pò i cloni, per cui se un gioco è il clone di un'altro e i media sono gli stessi, duplica quelli locali piu' che scaricarli

my 2 cents

[motoschifo]

Non ho modo di capire chi è utente "serio" e chi no, perchè per registrarsi al sito basta una mail e comunque è tutto libero.
L'unica discriminante che posso usare è il numero di richieste per indirizzo IP: se sono troppe, devi separare in più giorni il tuo lavoro e dare spazio agli altri.
Eventualmente poi si potrà pensare di limitare solo in caso di troppe richieste totali, quindi se il server è scarico anche 200 mila richieste non danno fastidio, oppure di accodare ciò che va oltre con attese forzate (es. max 1 ogni tot secondi).

Normalmente abbiamo poco più di 1 milione di richieste (api) al giorno. Sicuramente in futuro saranno aumenteranno e non voglio arrivare alla saturazione completa.
Fare dalle 20 alle 40 mila chiamate (per utente) solo per avere un titolo o un'immagine aggiornata mi sembra un po' eccessivo, considerando che questa cosa impedisce poi agli altri utenti di visitare il sito o li rallenta, facendo rallentare tutto il sistema tra l'altro.

Vedrò i numeri che otterrò nei prossimi giorni, non è un sistema infallibile ma sicuramente permette di liberare il sito e consentire la navigazione.

I software di scraping li fanno i programmatori, se uno programma male non vedo perchè debbano rimetterci tutti gli altri.
Poi non è che da domani chiudo i rubinetti, sarà un passaggio graduale come sempre e chi vuole aggiornare o chi ha bisogno di aiuto può sempre scrivermi per venirne a capo senza impazzire.
Magari scopro che facendo un'api diversa e specifica risparmio tempo macchina, oppure posso predisporre già dei file pronti che non necessitano di usare la cpu (una sorta di scraping già fatto e pronto da scaricare). Insomma i modi per migliorare ci sono, però quello di oggi non è il sistema corretto per la mole di dati che abbiamo e quindi va cambiato

[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.