Jump to content

WHMCS server requirements for 20,000+ clients


aushosts

Recommended Posts

Howdy folks,

 

Just a general thought that popped into my head after talking with a friend about ModernBill and how slow it gets after a few thousand clients and 2-3 years worth of invoices...

 

What do people think about WHMCS server requirements if it was managing the billing and helpdesk for say 20,000+ clients; and 5 years of invoices (about say 20-30 invoices per client per year)... Not needed yet but you never know :)

 

Do people think it would start to slow down and become problematic; or is WHMCS robust to a point where the limit is simply the server specs / servers setup?

 

I guess if your hosting 10,000+ clients in WHMCS at the moment; are you having any issues?

 

Would you consider separate web and MySQL servers once you get to that number? What are peoples long terms thoughts on things like this?

Link to comment
Share on other sites

aushosts,

 

I am not too sure of how many large hosts are out there using this software, however, we are in a similar situation and have purchased a license a earlier this year.

 

In our testing, it seems like it is holding up to the strain, and have seen little issues with a large database. We are running the db on a separate server. The logs and tickets grow quickly, but we are planning to archive it every 30 days, (truncating 30 days from the WHMCS logs, leaving XX days), then building a separate interface for admins, as well as the emails sent.

 

All in all, it seems to be fairly efficient, but have had some issues particularly with the ticket overhead. You can cron an optimization if it gets out of hand.

 

We will not be importing any old invoices. You may want to reconsider importing your ~ 250k records if you can leave the legacy system in place for a year or so. This will save some processing time when it is doing SELECTs on tblinvoices for automated billing...although that will also depend on your server config.

 

Hope this helps.

Link to comment
Share on other sites

Having got into WHMCS's database structure I certainly agree with you. Today I basically fixed up all our customers packages so they are on streamlined packages instead of all over the place like as I was using ModernBill (it actually was 2 modernbills converted to 1 WHMCS - big mess now much better)...

 

Will be 100% good by next month.

Link to comment
Share on other sites

Beyond archiving the larger things like the logs, the only thing I'd look to do when WHMCS's database grows large is check/create indexes on the tables :)

 

xx,xxx and xxx,xxx rows are no problem for MySQL with a well-designed system...we host some xx,xxx,xxx-row tables on even our shared hosting servers :)

Link to comment
Share on other sites

@brianoz absolutely ... It seems to perform quite well under the load.

@dominic ... true, right now it seems that the only indexes are on row id. Unfortunately with WHMCS you can not alter the queries, so it's kind of half the equation. You can see some/most of the queries by printing out all the user assigned variables. There seem to be few joins or complex ones (or at least that I can tell). The good news is the tables are pretty well thought out, and makes it pretty efficient... hence the good news about performance.

Link to comment
Share on other sites

Could turn on the MySQL query log if you wanted to dig down into it I expect - the great thing about WHMCS is that the code itself is so light, and the data structure nice and sensible.

 

Adding indexes on common search fields would help, but really for only xx,xxx rows there's likely no huge differences if as you say there aren't that many complex queries. Heck even the reports are nice and speedy for us, even our custom ones :)

 

One thing I forgot to mention earlier was any PHP execution time limits - with lots of accounts to suspend, and lots of e-mails/invoices to send, the cron might hit the default PHP limit.

Link to comment
Share on other sites

  • 2 weeks later...

We run the DB directly connected via xover to the main web server in our scenario. Puts it private and inaccessible except for certain IPs that are private. I have seen very little performance degradation like this and it could be adapted to work through a GB switch instead very easily. If you took the support off to something such as Kayako that would ease the DB use in the ticket system otherwise you might have to look into MySQL clustering at some time.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated