(imported topic written by SystemAdmin)
Has anyone tried running the BES Console on a 64 bit OS and found noticeable performance benefits?
We believe that BES Consoles with large memory footprints, above 500MB, have better performance on a 64 bit OS and would like to know who else has seen similar benefits. In particular, movements like switching tabs, expanding filters and opening documents is better.
(imported comment written by SystemAdmin)
I am running the console in a 64 bit environment and I have not seen any real performance boasts (marginal at best). I am however running my 64 bit client as a VMWare guest - which also runs on a VMWare 64bit host. So, I have a 64 Athlon X2 and have dedicated a processor to my 64 bit XP guest. I have not tried the console straight on my 64bit host (base OS) - but I could try that if you like (would be happy help in testing). That brings up a question I have been wondering - can BES run on a 64bit server? Thanks.
Mike
(imported comment written by SystemAdmin)
Thanks Mike,
It would be best to do a comparison between running the BES Console on dedicated hardware without any type of VM ware or guests. Not to say that these won’t work but just to eliminate variables from the comparison.
It would also be good to compare it with running on a 32 bit OS on similar hardware. Although that may be difficult unless you load a 32 bit os onto 64 bit hardware.
Finally, yes, BES will run on 64 bit servers for all components. Currently we still run as a 32 bit application. Windows has a 32 bit and 64 bit ODBC interface to be aware of though. Our DSNs exist in the 32 bit ODBC which isn’t the default interface from the Administrative tools UI.
(imported comment written by SystemAdmin)
Right now any 64bit stations we have are all running VMware. I will try the console on my host and see if there any difference. I did however find that we have a 64bit server (HP DL360 G4 Dual Core) that is not in production yet - so I will load the console on that and give it shot. My console open with no additional console windows opened is at 76,048k. With 4 additional windows open within the console it rises to 115,516k. And as you know continues to climb with each additional windows opened. I will give you an update on the console in 64bit shortly.
(imported comment written by SystemAdmin)
Here are my results. I did my tests based on watching CPU load during the load of the client. When CPU for the console service dropped from 99 completely to 0 - then I stopped the clock. Also, I have added what we are loading for records each time. All consoles are at 6.0.12.5. I guess there are some real differences.
1,046 - Action Sites
5,900 - Action Records
279,688 - Action Results
809,466 - Retrieved Properties
713,994 Fixlet Results
32Bit XPSP2
Stored Cache
Open - 3:15min - Resting K of 322,984k
Close - 45sec
Reload Cache from DB
Open - 2min - Resting K of 311,824k
Close - 44sec
64bit VM Client
Stored Cache
Open - 1:30min - Resting K of 294,960k
Close - 50sec
Reload Cache from DB
Open - 2min - Resting K of 311,824k
Close - 44sec
64bit NonVM
Stored Cache
Open - 50sec - Resting K of 301,524k
Close - 2sec
Reload Cache from DB
Open - 45sec - Resting K of 293,108k
Close - 2sec
(imported comment written by rad.ricka91)
Possibly slightly off-topic, but this article might be an interesting read for some:
http://msdn.microsoft.com/vstudio/java/compare/benchmark64/default.aspx
(imported comment written by SystemAdmin)
That’s very interesting data, thank you Mike. The close times that you listed are very interesting. If you are storing the cache it needs to be written to disk while if you are loading from the database it just needs to close the application. In your tests it seems to show that writting to disk and closing the application are taking the same amount of time and there is a huge win on the 64bit NonVM computer for both opening and closing the BES Console.
Another question, do you notice any sort of usability differences in the BES Console between those systems that you listed?
In particular, try these activities and see if you notice any differences:
Switching between tabs (computers, actions, Fixlets, analyses)
Expanding Filters. Try a computer property filter with lots of results. Try the All Fixlets->by source release date filter (this one is particularly slow).
Sorting columns. Try sorting computers by last report time and computer name.
Opening the Take Action Dialog.
Opening the Manage Properties Dialog.
Highlighting computers in the computers list.
Opening multiple windows. Try opening windows and see how many you can open before things start slowing down or become sluggish from the number of open windows. Try only opening windows of one type, like only action windows or only computer windows.
(imported comment written by StacyLee)
I am running the console on a XP 64 bit system and notice it’s faster. It’s not an apples to apples comparison because this was a desktop upgrade from my 32 bit system. The new system is faster w/ more memory and faster CPU speeds.
Here are my results based on the same checks as “mgoodnow”
64 Bit XP SP2
Action Sites: 3238
Action Records: 2129
Action Results: 890 975
Retrieved Properties: 863 508
Fixlet Results: 1 754 481
Open - Stored Cache
Console Up (still loading fields): 60s
Console Up: 1m 35s
Close: 52s
Memory: 397,967k
Open - Reload Cache
Console Up (still loading fields): 22 s
Console up: 3m 25s
Close 1.5s
Memory: 389,960k
—>Fast no Delay
—>3m 20s (21 subscribed sites)
—>by computer name: 1.55s
—>by last report time: 1.58s
—>1.67s
—>1s
—>Highlight 1 computer: 1.1s
—>Select all comptuers: 3.97s
—>98 Action Windows opened without delay
—>99th Action window hung opening : 6+ minutes so far. Actually the whole console is not responding. Memory is at 440,020k and CPU is stuck at 25% utilization. I’ll get back to you if it starts responding again or if i have to kill my console
(imported comment written by SystemAdmin)
I got basically the same results as Stacy with the activity testing on 64bit. The one thing that really was no different was actually deploying a patch with 64. It still took about the same time as on a 32bit system for the deploy to go through the “sending package” and “diff creations”. But since that activity is really taking place on the server (correct?) - I would figure to see little change.
Mike
(imported comment written by SystemAdmin)
Oh forgot. I got about 50 windows opened - with no real loss in utilization. Only 399,160k in use for that. There is a slight flicker of hesitation between screens - but not much. I would of killed my 32bit box with that many windows opened.
(imported comment written by BenKus)
This is excellent feedback from all of you!
Based on these results and some of our internal testing, I anticipate we are going to start making recommendations to our bigger customers to get 64-bit computers for their consoles and servers.
You can paste this message into your ticket-request for a brand new top-of-the-line x64 computer. =)
Ben
(imported comment written by StacyLee)
I’m a year or 2 away from a hardware refresh and thinking of going all out (budget permitting) with 64 Bit Server hardware, x64 Server OS and x64 SQL 2005 . Hopefully by that time you will have a smooth migration plan for me to migrate from one hardware to another and retaining the 100+ CO accounts intact. 
Maybe you guys will have a x64 BES Version too.
(imported comment written by SystemAdmin)
We were actually in the process of thinking about moving to new server hardware real soon. I am going to see if I can get this rolling sooner - and it will be with 64bit. I will keep you posted on the process and most likely will need some assistance anyway when it comes time to migrate from old to new. I would also like to go to SQL 2005 - that should not be a problem, correct? Thanks.
(imported comment written by SystemAdmin)
Yes, both the 32 and 64 bit versions of SQL 2005 are supported.
(imported comment written by SystemAdmin)
Great news. I got an early Christmas present. I now have a brandy new HP Proliant DL385 G1 2600MHZ AMD Opteron 285x4. My plan is to install Win2003(64) and SQL2005(64). I’m nervous about porting the old BES to the new. Can you tell me all the necessary Knowledge Articles that I will need for this? And what are any “gotchas” that I should be looking for. Thanks.
Mike
(imported comment written by jessewk)
Mike,
There are many ways to do this.
Basic migration instructions are detailed here: http://support.bigfix.com/cgi-bin/kbdirect.pl?id=133
Tyler has a nice script to speed up failover to a new box: http://forum.bigfix.com/viewtopic.php?id=366
My advice would be to install the server software on the new box using your existing mastead and keys. Then stop the services, replicate over the database (ensuring that your user accounts are also migrated), and then run Tyler’s script. Finally propagate the DNS switch to the new server.
I would test this process a couple times before doing your final change in production. It is very important that once you propagate an action from the new machine, no actions are subsequently propagated from the old one.