For a 250 to 500 agent G1 system would SQL Express be suitable ?
If you use SQL Express 2008 R2 with it's new 10 gigabyte database size limit, this should be OK.
Yes, based on normal activity you can manage up to 1000 agents on a dedicated SQL Express server with G1. You should consider implementing SQL Express 2008 R2 which now offers a 10gb database limit along with 1gb memory limit. You should also establish a process to monitor the size of the database and memory usage on a regular basis to ensure optimum performance.
I am running 300 agents
Just upgraded from SQL Express 2005 to 2008 R2, with my Kaseya server in a VMware VM
Performance is fine.
p.s. I found out that even though SQL Express only uses 1 CPU - use a 2 CPU server for VM and the performance is great (I did this after the upgrade and noticed a significant performance improvement for Kaseya)
Jason, what does your Disk I/O look like on your Kserver db? I have a friend who had some issues with 1k nodes on a vm install and his disk i/o was killing his box, he p/v the server and saw immediate performance improvements.
Just because I like butting in mid conversation...
It all depends on how much data you are pulling for each agent, as to how much space is used, and how much disk i/o there will be as a result of this. If you are using relatively simple monitoring (i.e. pulling errors and warnings out of app and sys logs, with some monitor sets for key machines like exchange) the database size should stay below the limit of express. The more you add on top of that, the close you will get to the db size limit.
We have just about 500 endpoints, with most being the standard monitoring as mentioned above, but there are about 100 or so that have more indepth monitor (SQL, exchange etc...) and out VM front end peaks out at 200kb/sec. I suppose it depends on the disk infrastructure that the vm's are built on, and what speed that can cope with.
When we had it all on one physical box, for a variety of reasons, it was really slow. I personally think its better, if you can, to keep the SQL side of things segregated as much as possible.