|Subject||Re: Odp: [firebird-support] FB server installation a nd concurrent users limits on Windows Server|
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