What's your Siteworx account limit per server?

I know this sounds strange and you can say that “it depends on the cpu/memory/bandwidth of each site” but still here goes the question:
When do you say: “enough accounts on this server, let’s move to a new server”?

  • Is it when your disks fill up?
  • Is it when your cpu/memory usage is very high?
  • Is it when you use a lot of bandwidth?

What’s your criteria?

What I really want is a personal answer, based on your experience. I’d also like Chris and the team to pop in and comment what the average number of accounts is per server on their servers and on client’s servers.


Bandwith is never really an issue for us - so that’s not a factor for us :slight_smile:

CPU, yes it is monitored but we don’t tend to have too many issues.

For us it’s mainly diskspace, as this is where you can become unstuck very quickly if you oversell. We tend to have a ‘trigger’ limit which is around when 40% of diskspace is used - we would bring online another server. This allows the existing sites to grow without us having to continually watch and move accounts around if required.

We have one server currently running with just over 150 ‘siteworx accounts’ on it. It’s diskspace is at 47%, CPU Load averages 0.40-0.80 and last month it did around 180GB of bandwith.

Hope this helps in your research. :slight_smile:

I have right at 160 sites on my IW server and and the disk space is at 13% (250GB) RAID 1 set up. Our bandwidth usage is running around 150 to 200GB per month.

Most of the time the server load is way below 1.0 and once in a while its up over 1.0.

As for as max sites, I will see what happens, I am targeting 200 sites based on what the server has been doing so far.

490 sites is the max (Dual Optron 270 with 8 GB RAM), after that you have to recompile a lot since the open file limit is 1024 and more than 1024 files need to be opened (error logs and transfer logs). But of corse mainly depends on what kind of sites you are hosting. Once we had a customer which had a site hosted on our cluster setup and it claimed all the resources, now they have a own cluster setup.

However, we have a cluster setup which is working fine with 600+ sites without recompiling anything.

Bandwidth usage is about >500 Gbytes a month per server.

WebXtrA , how you amke for run 600 sites on server?
The real limit is 512 on interworx, interworx use 2 descriptors, per virtual host.

How you make work without recompile?
vbmenu_register(“postmenu_11947”, true

[QUOTE=Dj-Grobe;12141]how you amke for run 600 sites on server?
The real limit is 512 on interworx, interworx use 2 descriptors, per virtual host.[/QUOTE]

Technically, it’s less than 512. Not counting the vhosts, Apache opens a few files itself (like in /var/log/httpd), so it’s a bit under 512. 490 sounds about right. :slight_smile:

And technically, it is Apache’s limit when using InterWorx’s setup :wink:

Thankyou for that update, 490 sites…
Webextra how you run 600+ sites without recompiling nothig?

I really cant udnerstand how you do that, please can repply?

What you think socheat how he make that !! ?

I don’t know, but the Iworx guys have done some work on it :wink: so I don’t know. I have to say that we are not running 600 sites on it anymore.

I honeslty don’t recall what we did to help out, it’s been a while - we may have helped recompile apache, or we may have disabled the error logs for most vhosts.

Our goal is to eventually provide the recompiled packages that will eliminate this barrier completely.


If I recall correctly, I think we just disabled logging entirely on a handful of sites, to keep you under the 1024 descriptor limit. :slight_smile:

well i see…disableing logs? bad idea…
The best its recompile, but what exactly? apache? and what more?
no great documentation about this available : (

Disabling error logs is less of a bad idea than disabling transfer logs. At a minimum, httpd and php would be recompiled. But no, we don’t have documentation on doing this because we haven’t throughly tested the scenario yet.

Disbale error logs its not great idea.? ; (
Sure, …its better to disable transfer logs, but what about php, and waht about imap, and what other sevrices need recompilation?

I think the recompilation way its the only way, i try to find more info around the web, please if sombody know how make this, please just put info.
Anyway i tink be better open new post about this, for see if sombody cna help to do this.

Thanks anyway.

I mentioned that php would have to be recompiled. IMAP would not, it does not interact directly with the httpd server in question. As I said, recompiling with the limit removed is indeed the best, although more difficult, solution.

Paul just need recompile apache, and php?
Not other thing need recompile?

I do not know for sure because we have not throughly tested the scenario yet.


Only cpanel support correclty host more 500 sites aparently : (
I no really like use cpanel !! its really ugly lol

We got one up to 8,000ish once - Dual Xeon 2.66. :slight_smile:

Free hosting accounts on freewebsitehost.net; most in-actives were pre-cleaned by a bash script. I’m pretty sure it was the first serious test the InterWorx mass cPanel importer got.

FYI- it took 3 very unstable cPanel servers (each crashing every 18 hours or so) to attempt what we accomplished with one InterWorx server. It didn’t run quickly, but it did run consistently.

DNS sync also worked beautifully then as we scaled outwards from there, before we finally let all of our poor free hosting test subjects go.

8000 sites?

How much take apache to restart lol.

lease if this is correct, cna tellme what its changed for make thatamazing number work?

I no want host that very high number lol, just want host around 600 sites, but need know what need change on iworx.

I apreciate any instructions?

You have that number? with mails? and php working in some sites?

I want run 600 sites with dual xeon, or posssible make the smae with clsutered machine.

An Apache restart took 20-30 minutes if I remember right.

We made all kinds of tweaks to the system, Clint or Mr. Wells could probably tell you a lot more about what some of what we did. But, the basics (ie. PHP / MySQL) remained enabled.

We did lock things down to only allow web-based email.