Web Hosting Forum | Lunarpages


*
Welcome, Guest. Please login or register.
Did you miss your activation email?



Login with username, password and session length
February 09, 2012, 07:01:25 PM

Pages: [1]   Go Down
  Print  
Author Topic: AJAX Chat Installation on Abell?  (Read 1192 times)
jatticusryan
Space Explorer
***
Offline Offline

Posts: 7


« on: November 27, 2009, 06:33:13 AM »

I can guarantee this question has been asked before and I have already read through a number of questions and responses here regarding AJAX Chat. However, I want to be certain and am hoping someone (a Lunarpages support/admin person, maybe) can confirm.

I have downloaded and installed AJAX Chat with SMF integration via ajax_chat-0.8.3_SMF.zip available at SourceForge. I have already tested the installation and AJAX Chat is running fine for me, including authentication via SMF.

Before I proceed with skinning my installation of AJAX Chat and further configuring it, I want to confirm having AJAX Chat installed is not contravening Lunarpages security policy and that it will not cause my hosting account/server space to be moved to some quarantine server or similar action.

Important Information

AJAX Chat Version: 0.8.3
Maximum Users: 50
Hosting Server: Abell

I have set the maximum number of participants in a chat session at 50 via the AJAX Chat config file, therefore, no more than 50 users could possibly chat at a given time. A more likely scenario is a maximum of around 25-30 users and, even then, only on rare occasions would I expect our small fantasy baseball community to reach more than 25-30 users accessing AJAX Chat at the same time.

I am running on the Abell server but am no longer certain what hosting plan I have, since I have been with Lunarpages since 2003. I know I am about to be billed $95.40 for my upcoming annual renewal if that helps identify the hosting plan, which I am going to guess is the Basic Plan.

Can I proceed to skin AJAX Chat confident that it will not get zapped and that it is secure and not violating Lunarpages or my own site security?
« Last Edit: November 27, 2009, 06:37:47 AM by jatticusryan » Logged
Mitch
Berserker Poster
*****
Offline Offline

Posts: 12838


WWW
« Reply #1 on: November 27, 2009, 07:24:15 AM »

Shouldn't be a problem as far as rules on what you can or can not host goes.  You might do some research or contact the author of the addon though to make sure nobody else has reported any issues using it in a shared hosting environment, and if so - then what the problems might have been.
Logged

New to Web Site Hosting? Check Out the Lunarpages Blog Hosting Guide!


Follow us @lunarpages on Twitter!
Important Threads: Read This Before Posting! | Lunarforums Rules! | Mitch's Link of the Day!
Also, be sure to check out and subscribe to the Lunartics Blog and the Lunarpages Newsletter !

Need Web Hosting Help? Check out the Lunarpages Web Hosting Wiki. It has tons of tips, tutorials and resources!
jatticusryan
Space Explorer
***
Offline Offline

Posts: 7


« Reply #2 on: November 27, 2009, 07:34:57 AM »

Thanks Mitch! I will do the due diligence on any issues reported for AJAX Chat in a shared hosting environment.

Much appreciated!
Logged
Danielle
Guest
« Reply #3 on: November 27, 2009, 08:48:48 AM »

AJAX chat isn't violating any security policies. The bigger concern would be resource utilization. Your plan is basic hosting based on what you are paying. On basic and business plans, you are sharing a server with other users. If your site resources start impacting other users on the server by increasing the server's load, processes or memory, you will get noticed as being the cause by admins monitoring that shared server, then you will either be moved to a non-production server to correct the resource issues or have the site temporarily suspended.

Given you are using a chat system on the account, it could well spike server load or use high resources depending on how well the script is coded. Frankly, you should ask support in a ticket to check your current resource usage for your account and then ask again on a day with a lot of users in chat to see whether it is poses any issues. There is no other way to know how it is impacting the server otherwise.
Logged
jatticusryan
Space Explorer
***
Offline Offline

Posts: 7


« Reply #4 on: November 27, 2009, 09:15:48 AM »

Thanks Tristan.

I would be shocked if the activity in the client-sideJavascript and server-side PHP code base caused a spike on the shared server. To give you an idea of how many people would even have access to the AJAX Chat installation, the unitedleagues forum (http://www.unitedleagues.net/smf/) has only 59 registered users. Of those 59, one is the admin account and another five have not visited the site in many months. So, we are looking at a closed community of around 50 total registered users. Registration is by invitation only; the public cannot happen upon the site and create an SMF user account. The installation of AJAX Chat I have in place does not allow guest chat, only those already possessing a unitedleagues SMF account. I was primarily looking to have the chat available for a handful of people to discuss fantasy baseball trades whenever or to hold player draft/auctions every few months.

What concerns me in what you responded is this: "If your site resources start impacting other users on the server by increasing the server's load, processes or memory, you will get noticed as being the cause by admins monitoring that shared server, then you will either be moved to a non-production server to correct the resource issues or have the site temporarily suspended."

Are we not warned if by Lunarpages admins monitoring shared servers if we are causing issues with server load, processes, or memory, allowing us to take action to disable the consistently offending apps/content? Do the Lunarpages admins just move the site to the non-production server without warning or suspend it without warning? The last thing I need is to have the four fantasy baseball leagues I host via my account to have their seasons disrupted because I did not have the opportunity to take action upon the advice of Lunarpages admins. I would have assumed Lunarpages admins would contact the customer if there was a problem via the same email account associated with the Lunarpages account (the one used for notifying us of an upcoming or processed hosting bill).

The only problem with checking the impact of AJAX Chat is that I really do not expect regular use of AJAX Chat beyond a few users a day. I could be wrong. But, it is not as if I expect all 50 users on concurrently ever let alone on a regular basis. Therefore, it will be hard to pick a day to ask support for an analysis of load, process, and memory use. I am concerned that if I request forum users test out the chat application at a given time then it will trigger a Lunarpages admin reaction of pushing the site to a non-production server or suspending it.

Do you see my quandary? It is pretty close to a Catch 22.
Logged
Danielle
Guest
« Reply #5 on: November 27, 2009, 11:29:13 AM »

Quote
Are we not warned if by Lunarpages admins monitoring shared servers if we are causing issues with server load, processes, or memory, allowing us to take action to disable the consistently offending apps/content? Do the Lunarpages admins just move the site to the non-production server without warning or suspend it without warning? The last thing I need is to have the four fantasy baseball leagues I host via my account to have their seasons disrupted because I did not have the opportunity to take action upon the advice of Lunarpages admins. I would have assumed Lunarpages admins would contact the customer if there was a problem via the same email account associated with the Lunarpages account (the one used for notifying us of an upcoming or processed hosting bill).

The only problem with checking the impact of AJAX Chat is that I really do not expect regular use of AJAX Chat beyond a few users a day. I could be wrong. But, it is not as if I expect all 50 users on concurrently ever let alone on a regular basis. Therefore, it will be hard to pick a day to ask support for an analysis of load, process, and memory use. I am concerned that if I request forum users test out the chat application at a given time then it will trigger a Lunarpages admin reaction of pushing the site to a non-production server or suspending it.

Think of it this way, if you are causing load so that all other accounts have sluggish or non-working sites due to your application, then what choice do we have? We do not normally notice an account to see it is high usage until that account starts causing actual issues on the server. If the site only does it for a short period of time such as 5-10 minutes, we would not take any action, since it would have ceased after a very short time to be an issue. If the issue continues after 5-10 minutes and does not stop causing load or high memory or processes, we cannot allow the account to continue causing the load and we do not have pre-warning either that it will be until it happens.

Imagine our quandary if we were to warn you rather than take action when your account is causing high load (or even possibly coming close to crashing the server) and we had to wait until you fixed the issue, causing slowdown and site unavailability for every other person on that server. We cannot do that. Moving a customer to non-production servers really does not negatively impact the site as it would still be up and the non-production servers are typically beefier to handle high resource usage over the regular production ones. The reason they are called non-production is that an account can only remain on that server for around a month without doing anything to improve resources before we ask the site owner to either upgrade to VPS or dedicated or ask the owner to find other hosting.

We rarely suspend sites rather than move them. The main instances when a site is suspended would be it is huge (10 or more GB large) and would take forever to move it over, causing downtime for the user if we tried anyway and possibly not copying everything. Another instance would be when the site is getting attacked by a denial of service (DoS) and moving the account won't fix the issue. The final instance would be when an account is exploited and we are unable to locate the exploited script(s), so we have no choice but to suspend until the customer can go over the account to find the exploit.

We don't take actions on an account unless we absolutely must do so, since we really have no desire to upset a paying customer, but if that paying customer is negatively impacting all the other paying customers on the shared server, then we do what is necessary to get that account off the server onto non-production to improve the usage on the production server. If we did not do this, then your account would suffer when another user is high usage and we allow that user to make the choice after slowing down the machine or crashing it on when to take action by warning the user. Everyone wants the server to respond quickly and work. You are benefited as a normal user who isn't high usage when we move high usage users off your server, and you are benefited as a high usage user who is impacting everyone else when we move your account to non-production, since we didn't suspend you and did allow you to fix it. How would you be benefited in any fashion if we warned high usage users before moving them? First, if we did that, your site would be slow due to that user until they fixed their usage. Second, if we did that, your site would be slow if you were the high usage account until you fixed your usage, since your site would be slowing down the server for your account along with every other account.

I hope this clarifies the reasoning for you on what happens.
Logged
jatticusryan
Space Explorer
***
Offline Offline

Posts: 7


« Reply #6 on: November 27, 2009, 12:10:51 PM »

Thanks again Tristan. That completely explains it. And I do appreciate the extensive reply to clarify what happens in the event an account is impacting a shared server. I definitely do not want to cripple the server for others, especially since that would also mess up unitedleagues users, too. I just wanted to make sure there was no horrible admin guided missile primed to blow up offending sites and files. The options available to admin and how they are managed makes perfect sense.

I imagine the worst that could happen in the unitedleagues AJAX Chat case is transfer to a non-production server since I think we only have a couple of GB worth of data. And if we were offending all of a sudden I would know exactly what the source of the problem would be.

I have been reading up on the options for reducing server load and the easiest seems to be further limiting the maximum number of users connected to the AJAX Chat installation. I have set this to 25, down from 50 earlier today. In fact, all of this is moot anyway, since I have it set for forum admin use only for the time being and there are only two of us. I can also slightly increase the time interval of the client-side Javascript calls to the server, which is set by default to 2000 milliseconds. Maybe tweaking that to 3000 milliseconds would help avoid problems.

I will give it a think and continue researching reports impacts of AJAX Chat on server load, processes, and memory. Ultimately, I may just bag the whole idea, as disappointing as that is, if I cannot feel confident on the set up prior to letting some people use it. It has just been a bear trying to find a good web-based chat application/system that is not dodgy, ad-based, or costs more than I already spend.

Once again, though, thanks for taking the time to thoroughly explain everything! It really is appreciated. I have to say, that is excellent customer support and service on the part of Lunarpages!
« Last Edit: November 27, 2009, 12:24:51 PM by jatticusryan » Logged
jatticusryan
Space Explorer
***
Offline Offline

Posts: 7


« Reply #7 on: November 27, 2009, 12:43:19 PM »

After all that fuss and stuff I was too freaked out by Tristan to go ahead with AJAX Chat.

Well, Tristan and the few sources I found online that describe AJAX Chat as a server hog.  Very Happy
Logged
Pages: [1]   Go Up
  Print  
 
Jump to: