Re: Odp: [firebird-support] FB server installation a nd concurrent users limits on Windows Server

[af_12...@yahoo.com [firebird-support]]

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