Newsgroup: it.comp.lang.delphi
Titolo: "Stranezze" con delphi Xe7 e FB su server

buongiorno
 
stavo facendo dei "primi passi" con i prodotti in oggetto. Per testare le capacità di FB l'ho installato su un "vecchio" server Windows SBS 2011 (che vedo si rifà a parecchie cosette di W2008)
 
il server ha 12gb di ram ed una catena SCSI suddivisa in 2 volumi. sul primo c'è il sistema, active directory ed alcune cartelle condivise.
sull'altra Exchange.
il server non è particolarmente performante ma tutto sommato "risponde" bene quando si eseguono varie applicazioni in loco e alcune applicazioni che fanno uso del solo fileserver (anche con file di grosse dimensioni)
 
mi trovo di fronte a due "stranezze"
 
la prima è che FB risulta particolarmente lento con una semplice applicazione che inserisc un record in una piccola tabella.
la stessa applicazione in locale su win7 funziona molto velocemente
 
stavo "studiando" un bel po di materiale circa il fatto che è sconsigliato installare un SQL sotto un Domain controller e/o un Active directory proprio per scongiurare questioni di prestazioni (non solo per FB ma anche lo stesso MSSQL ed altri)
Mi chiedevo, a parte gli ambienti enterprise, come fanno i piccoli uffici di 5/10 utenti che hanno un server unico per fare tutto e non potrebbero mai permettersene 2?!?
 
tra l'altro vedo "girare" molte applicazioni commerciali che funzionano decentemente su unico server DC - AD , anche più lento del mio
 
nel materiale che ho letto si parla anche delle impostazioni sulla "write cache" che solitamente (e giustamente) è disattivata sui server e che non certo dovrebbe essere la chiave di volta per risolvere il problema
chi si sognerebbe mai di mettere a rischio il DB a seguito di un crash? (ance se ci sono i backup)?
 
la mia domanda è quindi, come far a far sopravvivere decentemente FB su tale server?
stavo leggendo della page size , della possibilità di atttivare/disattivare le async mode in FB , provato alcune cosette ma il risultato non cambia purtroppo.
 
tra l'altro ho notato una seconda stranezza e non so se dipende da XE7 oppure no ma quando faccio semplicemente la connect dal client (tramite IDE e non) siccome il server risponde lentamente all'applicazione, questo per Windows la porta in "hang"  e per pochi secondi mi appare il messaggio "l'applicazione non risponde" , mi sembra alquanto strano, ho provato sia con FireDac che non DBexpress
 
capisco la lentezza del server a non rispondere, non capisco invece perché l'applicazione si comporta in tal modo
 
se provo a connettermi con ibexpert , anche questo è ovviamente lento, ma resta in attesa senza che appaia il messaggio "l'applicazione non risponde" 
 
da cosa puo dipendere? (premetto che la mia postazione funziona ottimamente e non ha nessun problema del genere con altri programmi "pesanti")
 
grazie per i consigli e/o l'aiuto
Alessandro
 
 
 
 
 
 
 

 capisco la lentezza del server a non rispondere, non capisco invece perché l'applicazione si comporta in tal modo
 
Non hai indicato come hai configurato il server FireBird e quali parametri hai specificato sul client per collegarti: magari il problema potrebbe essere lì.
 
Inoltre, non ci è dato sapere altro sull'architettura di rete: potrebbero esserci fattori esterni (apparati, configurazioni, ecc.) che limitano la comunicazione tra il client e il server.
 
-- 
MARCO BREVEGLIERI (Software and Web Developer)
#Home: 
http://bit.ly/marcobreveglieri
 
#Blog: 
http://bit.ly/compilaquindiva
 


ho utilizzato una installazione "standard" superserver 2.5.3
senza alcun parametro particolare. ho preferito utilizzare "i default" cosi come ho fatto sul client
ho lanciato la stessa applicazione localmente su entrambe le macchine, sul client e sul server (ognuna con il suo db locale), sul mio client "va una bellezza" ma ovviamente qui non ho Domain Controller ne Active directory , oltre che avere un pc più aggiornato e veloce
quindi in teoria escluderei, almeno "ingenuamente" , gli apparati di rete e le configurazioni , soprattutto quelle di rete , visto che ho lanciato la stessa applicazione in locale sul server (dove tra l'altro il firewall è esterno su 
hardware)
è vero che il server sta facendo altre cose (è un server) ma una lentezza maggiore di 10x mi sembra ingiustificata
 
 
ho letto molto rispetto alle problematiche degli SQL installati su server Windows con DC e AC , ma nessuno che propone una soluzione , a parte un po di confusione sulle versioni di FB poiché pare che il servizio di active directory e il domain controller "controllano appunto" tutto quanto avviene sulla macchina.
cosa strana però è che se accedo da rete ad un folder condiviso e faccio uso massiccio di dati , questo risponde in maniera "decente" (è vero un motore db non è la stessa cosa, ma stiamo parlando di un semplicissimo DB vuoto con una tabella da 5 campi)
considera che per escludere codice,rete,postazione, Firedac, etc 
mi sono connesso anche dal client con IBEXPERT che sarà pure sensibilmente più veloce ma la cosa non cambia : il server è lento sia dal client che su "se stesso" 
 
 
A proposito della seconda stranezza, ho notato invece che se anziché eseguire l'applicazione senza debug, la eseguo step by step con il debug e poi lancio la classe che si occupa di fare l'insert, l'applicazione non va nello stato "non risponde" durante la prolungata attesa per ottenere la risposta del server
non vorrei che fosse qualche bug del nuovo compilatore XE7

 senza alcun parametro particolare. ho preferito utilizzare "i default" cosi come ho fatto sul client
 
Ovvero? 
 
Precisamente, quali sono i parametri di configurazione che hai specificato sul client? Ossia, qual è la stringa di connessione che hai indicato per accedere al tuo database FireBird quando l'hai pubblicato sul server?


 la stessa applicazione in locale su win7 funziona molto velocemente
 
Inserisci COME e con quale tecnologia di accesso ai dati?
Usi oggetti "tabella" con append o usi delle query INSERT INTO?
Quando dici "in locale" itenti "server db che gira sulla stessa macchina"?
Ha provato un tracert per vedere che route segue il client per arrivare al server FB? 
Ancora, non è che sul server c0è un antivirus che sta li a monitorare anche le cartelle con i file di FB?
 
A.

 Ancora, non è che sul server c0è un antivirus che sta li a monitorare anche le cartelle con i file di FB?
 
Magari parto prevenuto, ma io scommetto invece su un'altra cosa, ma la dico dopo... :P


"non vorrei che fosse qualche bug del nuovo compilatore XE7"
 
E te pareva.


allora, palrando di FB , ho utilizzato le impostazioni standard di default proposte dall'installer dove l'unica cosa che è possibile specificare è "superserver" o "altraopzionecheora_nonricordo"
in ogni caso ho scelto superserver
 
aldilà di disquisizioni prettamente tecniche in cui posso ancora poco addentrarmi ,la query anziché scriverla io , l'ho "fatta scrivere" ad ibexpert
connect, show data, una volta aperta la tabella ho provato a duplicare un record.
 
ho preferito affrontare prima questa strada proprio per evitare miei eventuali errori sull'utilizzo di FIREDAC ,etc 
 e , anche la duplicazione del record (si tratta di un blob da 10mg) era lento
 
poi ho trovato una impostazione da settare sul DB in alcuni post tecnici in giro per la rete....ed......eureka!!!

Il giorno lunedì 22 dicembre 2014 11:46:59 UTC+1, Alberto Salvati ha scritto:

no purtroppo mi sa che quella scelta M$ continua a suggerirla per l'SQL (ma anche altri produttori SQL sono sulla stessa linea)
a quanto pare su quei dischi non è possibile attivare la write cache (neanche con un fucile puntato su chi te lo configura/installa) e quindi , decadimento assicurato.
poi mettici che effettivamente Exchange ma anche il serve stesso mette a dura prova l'hdd unico ed il gioco è fatto.
 
ho provato ad usare DBexpress e Firedac, ma ripeto , ho "abbandonato" la questione quando mi sono accorto che prima di affrontare bene il discorso query etc , il problema è proprio sul server, utilizzanto un tool esterno come Ibexpert 
 

 ho provato ad usare DBexpress e Firedac, ma ripeto , ho "abbandonato" la questione quando mi sono accorto che prima di affrontare bene il discorso query etc , il problema è proprio sul server, utilizzanto un tool esterno come Ibexpert
 
Però non hai ancora specificato in nessuna delle tue risposte a questo thread quali sono i parametri che hai utilizzato per connetterti al database, né in Delphi (con dbExpress o FireDAC) né in IBExpert, nonostante ti sia stato richiesto più volte.
 
Non riuscirò mai a capire qual è l'utilità di chiedere aiuto in un luogo di discussione pubblico venendo già con una teoria (che ci sta) ma fissa e immutabile, senza fornire a chi risponde alla domanda utilizzando parte del proprio tempo libero i dettagli richiesti.
 
In questo thread, tutti quelli che sono intervenuti ti hanno posto un milione di domande a testa per cercare di capire il tuo problema, e non hai risposto a una di queste.
 
Ciao,
  Marco.


 E te pareva.
 
Sì, si tratta di un nuovo bug che, nella compilazione di un progetto, crea problemi nell'accesso a un database FireBird anche utilizzando un programma esterno, tipo IBExpert, se sul server che ospita il database è presente Exchange. :D


 in ogni caso ho scelto superserver
 
Io ti avevo chiesto la configurazione del *client*, non quella del server.
 
Non ti ho chiesto qual è la query che hai eseguito, né dove l'hai generata: ti ho chiesto cosa hai specificato nei componenti dbExpress/FireDAC/altro in termini di parametri per poterti collegare al tuo server FireBird, aprire la connessione per poter poi eseguire la query.


 poi ho trovato una impostazione da settare sul DB in alcuni post tecnici in giro per la rete....ed......eureka!!!
 
Cioe`?
 

 In questo thread, tutti quelli che sono intervenuti ti hanno posto un milione di domande a testa per cercare di capire il tuo problema, e non hai risposto a una di queste.
 
allora , forse stai facendo confusione con qualche altro post
io vedo il tuo intervento e quello di Alberto che forse ha capito la questione anziché focalizzarsi sul "ma come hai scritto la query" che come ho cercato di spiegare più volte , non è il punto della questione
 
infatti ho anche detto che ,EUREKA , andando a cambiare una impostazione sul DB , la situazione è cambiata
 
ma forse ti è sfuggito?
 
Alberto scusami forse non ho risposto a tutte le tue domande ma ho poca dimestichezza anche ad usare le varie "reply" qui nel NG
 
in ogni caso si ho pensato subito all'antivirus infatti ho aggiunto una serie di esclusioni ma poi l'ho anche disattivato


 su DB , la situazione è cambiata
 
E cioe`? Mai possibile che bisogna tirarti fuori le informazioni con le tenaglie?

 Alberto scusami forse non ho risposto a tutte le tue domande ma ho poca dimestichezza anche ad usare le varie "reply" qui nel NG
 
Il comando per replicare a un messaggio è sempre lo stesso: non ce n'è una versione per replicare con le risposte e un'altra senza.
 
Comunque faccio i miei auguri di buon Natale e rinuncio alla questione.


 Poi tutti questi assunti sui giudizi fatti alla tua persona te li sei inventati di sana pianta e non sono mai stati né detti né pensati, visto che ci conosciamo.
 
Ovviamente intendevo dire *non* ci conosciamo, di persona s'intende.
 
Ancora auguri!



ahh ma allora qualcuno che legge c'è!!!
ma sarà un bug di FB allora? :)
 
quello che mi sembra strano è che nessuno abbia colto subito la questione e quindi forse non vi siete mai trovati di fronte a questo scenario.
Puo capitare se si hanno a disposizione sempre macchine molto performanti e recenti , se non si gestiscono blob con campi "molto grandi" ma soprattutto se non si ha necessità di installare un motore SQL in un server Windows dove è attivo un domain controller
c'è un articolo proprio di Microsoft se qualcuno può essere interessato e ha capito che il problema non è nella query , non è nella configurazione di rete poiché anche accedendo al db sul server stesso (e quindi non dovrebbero esserci problematiche di rete , routing o altro, l'antivirus è disattivato) posso pubblicarlo (appena lo trovo)
 
in ogni caso , quello che avvalora la questione è tutta una serie di documentazioni che ho trovato su FB e che trattano appunto di queste problematiche di decadimento delle prestazioni che possono verificarsi su server Windows con DC attivo,
infatti l-alternativa (se non si ha un secondo server a disposizione o un secondo HDD) e' quella di impostare la gestione della cache nel motore SQL (quando questo lo prevede) in sostituzione di quella che non si puo impostare sul'HD 
 
cambiando queste impostazioni la situazione e' migliorata notevolmente
andando ad utilizzare il DB con IBEXPERT senza fare query a mano ma usando semplicemente un DUPLICATE
 
 

>>>la mia domanda è quindi, come far a far sopravvivere decentemente FB su tale server? stavo leggendo della page size , della possibilità di atttivare/disattivare le async mode in FB , provato alcune cosette ma il risultato non cambia purtroppo. 
 
 
nel frattempo, sono riuscito a configurare FB , non so perché ma quella prima postazione non era andata a buon fine (ovviamente colpa mia)
 
non e' difficile dare informazioni , figurati, ma secondo me proprio perché il tempo e' prezioso che volevo evitare a tutti coloro che stanno provando ad aiutarmi a non focalizzarsi su una cosa che non ho chiesto e che non e' il punto
 
non trovi? 
se poi qualcuno mi chiede 'ho il piacere di etc etc' , allora non ci sono problemi
 
 
riscrivo anche il passaggio EUREKA , sempre per comodit'
 
sono riuscito a configurare l'async write mode nel MOTORE SQL 
e ora FUNZIONA BENE
 
magari vi posso scrivere la query e ...le impostazioni del client , se riesco a capire dove le trovo!!:)

 Comunque faccio i miei auguri di buon Natale e rinuncio alla questione.
 
grazie tanti auguri anche a te 
forse e' tutta colpa mia , non so replicare bene sul NG ma forse qualche problemino c'e' anche altrove ..ma fa niente 
 
saluti
 

auguri a tutti e grazie lo stesso!!
 
ripeto 
gfix -w ASYNC pathnomedbetcetc
 
ops, bisogna riavviare il motore !!:)
spero che a qualcuno possa servire in futuro , mi ci sono dovuto rompere la testa non poco.... e leggere una marea di post
probabilmente o si lavora in piccoli ambienti e quindi il problema DC non si pone, o si lavora in grandi ambienti dove ci sono server dedicati questo e' il motivo del perché questa faccenda e' poco nota in giro.

p.s. 2 
il problema del 'non risponde' c'e' ancora purtroppo!! 
ma ora andiamo in vacanza a riposarci va' che e' meglio!!
 
 
ahahahah
 
ho gia' del materiale che sto leggendo in merito , tra multithread e cosettine da evitare con delphi
 

sono riuscito a configurare l'async write mode nel MOTORE SQL 
 
Vedi sopra: ovvero? Quale configurazione hai usato?

 ho gia' del materiale che sto leggendo in merito , tra multithread e cosettine da evitare con delphi
 
Multithread da evitare con Delphi? Sarei davvero curioso di conoscerle.
 


ci rinuncio ... grazie e tanti auguri


ma la configurazione di cosa, del piffero, o del pifferaio?
 
sto usando sempre ibexpert, stesso server in lan stesso motore FB installato come superserver con impostazioni di default quindi non c'è altra "impostazione" che è stata impostata/cambiata o altro
 
l'unica cosa che ho cambiato è : gfix -w async pathnomedb
 
non è chiaro?

 ci rinuncio ... grazie e tanti auguri
 
Mi sa che e` meglio.
 

 l'unica cosa che ho cambiato è : gfix -w async pathnomedb
 
E ci voleva tanto a dirlo? Bisognava tirartelo fuori con le tenaglie?


non credo proprio di essere stato uno sbruffone , ai tuoi "insulti" rispondono nuovamente con ... tanti auguri 
 
 
GFIX ASYNC era scritto anche parecchi "post fa". mi pare 2/3 volte.... bohh
 
mi sa che ci vorrebbe una bella distribuzione natalizia gratuita di dosi di umiltà ..ma soprattutto di farmaci ad azione distensiva (neurologica):)
 

 mi sa che ci vorrebbe una bella distribuzione natalizia gratuita di dosi di umiltà ..ma soprattutto di farmaci ad azione distensiva (neurologica):)
 
A casa tua, probabilmente.
 

 
 
e no, l'avevo scritto già nel primo post
 
***stavo leggendo della page size , della possibilità di atttivare/disattivare  le async mode in FB , provato alcune cosette ma il risultato non cambia purtroppo***
 
forse volevi che scrivessi direttamente come si ATTIVA/DISATTIVA la async mode in FB? 
pensavo che fosse scontato..
 
E, il risultato, da quando ho aperto il thread, non cambiava purtroppo. 
Poi, dopo alcuni giorni... EUREKA ... è cambiato e l'ho scritto... 
 
il "bohh" , si fa sempre più grande. 
 
In ogni caso, aldilà di qualche commento poco costruttivo, spero che questo post possa servire ad altri . . . .
C'è da capire un bel po di cose sui domain controller , sulla cache , su come FB può gestire la cache...
 
 

 e no, l'avevo scritto già nel primo post
 
Sei un troll, ed e` ormai chiaro.