Tony

We will be in the next few days

One year users already complain to us about how they should get refunds 6 months later. I could just imagine the number of 5 year users we'd have this issue with and disputes and chargebacks coming from us denying.

There is also the issue of how much people pay already. So basic plan costs $39.48/yr so in five years that is $197.40. So I imagine someone would want to pay $100 for 5 years. We could not make money when we would be earning $1.67 per month on the account. Cashflow is great and all but there is a point where you're not making money on the accounts. Hawk Host is ran in such a way we're not constantly needing big amounts of cash from users. We make sure that we always have cash on hand or loans available to always acquire more hardware as necessary. So all that extra cash flow would go to waste in helping the company. All we could do with it is collect interest on it in our bank accounts but we would not make enough to justify what people would expect to pay for a 5 year account. If we were selling $120/yr accounts like some providers offering the longer term accounts could work since most of them can make money if on a 5 year payment it works out to $60/yr

This has been completed. The server was upgraded from 12gb of memory to 24gb.

That's very strange I'll see if I can get that fixed.

Edit: It appears to be our hawkhost custom theme

vbulletin costs money but with a paid product you do have support. It also in my opinion is more refined than phpBB. It has a lot more features and I think has better performance options as well. You also have the whole vbulletin brand itself people take a forum powered by vbulletin more serious than one by phpBB. At least with the vbulletin one someone paid for it so maybe the forum is a little more serious than just some random forum on the internet.

The maximum we allow is 128mb and you cannot change this. If you require more than this you might want to look at why your script is doing that. It's not normal to require say 500mb for a PHP process that kind of use suggests a dedicated server. Even on a server with 12GB of ram you're talking about wanting to use over 4% of the servers total memory with one php process!

Testing making a post now with the skin and cache all cleared.

Edit: Yep seems like it was a cache problem work fine for you now?

That's very strange I'll see if I can get that fixed.

Edit: It appears to be our hawkhost custom theme

If you're familiar with SSH what I'd recommend doing is checking your process list so:




ps -u yourusername
[/code]


Then find the ruby process which I assume is still running. Then just do kill 3983983 with the number being the process id for the ruby instance running.

Just check the versions that they claim will work and match up accordingly. You probably may even be able to upgrade some portions. The only thing you can't run right now is Rails 3. We're working on a non Mongrel solution to that though no ETA though lot of stuff going on.

vbulletin costs money but with a paid product you do have support. It also in my opinion is more refined than phpBB. It has a lot more features and I think has better performance options as well. You also have the whole vbulletin brand itself people take a forum powered by vbulletin more serious than one by phpBB. At least with the vbulletin one someone paid for it so maybe the forum is a little more serious than just some random forum on the internet.

I figured I'd mention most likely tomorrow and if not tomorrow on the weekend we'll be switching from vbulletin to invision power board. We've just had our fill of the bots overrunning our forums and just vbulletin in general being a major annoyance.

So expect a new look soon and probably a whole lot less annoying bots showing up on our forums. Which I guess means more people are going to need to post to make up for the bots

This feature is not available and we've stopped advertising it. The reason is we found it extremely unreliable which resulted in complaints and increased ticket load due to this. The feature simply did not mature as we had hoped so eventually we just had to drop it as it was just causing more problems then it was worth having as a feature.

On Tuesday August 24th between 6am and 9am PDT we will be switching the Spitfire server to CloudLinux. The window is for 3 hours however we estimate there will only be about 10 minutes of downtime while we reboot the server in order to load the CloudLinux kernel. CloudLinux will allow for us to better control resources being utilized by users as well as to better track the usage. This should result in an even more stable environment where single users will be unable to cause service degradation in most situations where typically a technician would be required to intervene to stop any service degradation a user may be causing. With this change a user who is using an abnormal amount of resources will see strictly their website slow down rather than the entire server slowing down.

If you have any questions about this maintenance window do not hesitate to contact support.

Date: 08/24/2010
Start time (PDT): 6:00am
End time (PDT): 9:00am
Estimated Down Time: 10 minutes
Duration: 3 hours

It's not really a suggestion considering we're going to be using it but I figured I'd make a post. With us becoming more popular the number of people who abuse our services is growing with that. So we needed a better solution as having technicians disabling accounts and sending out emails was a time consuming process. Users were also at random causing service degradation which is difficult to stop.

So basically it will allow us to do is limit users CPU automatically and this will reduce the amount of time technicians are dealing with issues. Basically for the users who abuse resources they're going to get a slow web site while the good majority of users will operate like there is nothing happening. Which is how it should be it is far more fair if the guy who loads up 100 wordpress plugins and has 25 second load times for pages they should not be slowing down your site. They should be slowing down strictly their web site. You can apply this to many other cases so attacks, looped scripts, exploited scripts etc. All cases where technicians acted they should no longer have to do that in most cases.

So some links: http://cloudlinux.co...tions/overview/

We've been running it on Frog Host for almost 2 weeks now which is a production environment. We were testing it even before then to see exactly what would happen. So here's a great example of our testing we loaded up a wordpress blog just vanilla install made a single post. We decided to replicate a huge amount of traffic by having 500 concurrent users visit this blog. We loaded CloudLinux up on our little Opteron 170 test server and had a brand new not fully deployed Dual Xeon 5620 system. We ran the test on the cloudlinux server and that web site slowed down however SSH and everything was still responsive such as SSH, cPanel etc. as the PHP processes only got a few percentage points of CPU. We ran the same test on a machine with 16 visible CPU's to the OS vs 2 on the Opteron and it was slowing down this machine as each process was able to take as much CPU as it liked. It's not a great test obviously but gives you an idea on just how effective it can be with a lot of situations.

I have no doubt some users may end up with slower sites as a result. A small minority who are attempting to use more than their fair share of resources. So they have their wordpress blog with 100mb error_log file full of problems and lots of max execution time errors. Though the person with a properly optimized site so in wordpress using caching and what not their site will remain just as fast as before. So basically it's just going to encourage people to optimize their sites or look to a VPS or dedicated where they could attempt to use up entire CPU's for extended periods of time.

Now for a deployment time well for now it's deploying on Mustang and Spitfire next week. Then the week after it'll show up on the rest of our shared hosting boxes assuming everything goes as well as it did in our testing. That week we'll also deploy it on our first few reseller / mixed servers to make sure in that environment it works the same. Then finally the week after that it'll be deployed on all machines.

Feel free to post your comments and concerns here