hi all

i've found some "spots" and i would like to resume there here becouse maybe will help some Others.

1) there are lot of discussions around web about problems wtih windowsDomain controller , active directory etc, i dont know for my inability or maybe becouse often the "answers" seems never CLEAR to the point

(someone like DO NOT DO THAT OR THIS , and that's it , but then you find that someone is doing it , HOW ?,!!) anyway :

a windows domain controller usually disable the HDD write cache for integrity pourposes , i dont know how unix/Linux are doing that becouse the server there seems more performant also when you have lot of datas.

that "write cache" disabled on a DC controller means LACK of SPEED/performances

so the first point of discussion is that. Maybe if you have a dedicated server that is not a domain controller you do not have "write cache disabled" and then , noone get performance problems

after some tests i've found a post where was suggested to set ASYNC parameter on the FB database to avoid that FB "forces" to write after a commit the datas on the HDD.

SO, FB now get faster like on a client in an embedded installation. Why? becouse each Windows client usually have "write  cache" enabled option by default on system installation

i dont know how much it wuold be a solution becouse in this way you risk data corruption in a case of server crash

i am just wondering how enterprise dba are managing this situation (that doenst not affect only FB but any DB)

the alternative ? ok to "play" with buffers, pages, etc , but nothing could SPEED UP all the operation like an option to "cache" the writing operation to an HDD

or maybe to have a very faster "system" (cpu , hdd channel, hdd , etc)

i've found all this only making a small test project tring to write on an old server w2011 and FB 2.5.3 some images around 1mb 10mb

on the first time i've got a very slow operation also insering a simple record with no image at all , or betterer , the image was 1byte on a table with 5 fields. to save 5 record it took "seconds" and was unbeleivable (slow)

so the final trick is :

have a 2° server , but with "write cache enabled"

maybe the same server with 2° hdd where you can enable write cache (with or without DC controller installed on the first hdd)

if you have like me , 1 server with all "inside" (we are not an enterprise environment) with 1 hdd and DC installed , you could use ASYNC operational mode setting in the FB DB

gfix -w ASYNS dbnamelocation