siteground shared server upgrade problem to pro

well i have been in contact with the cs-cart support team and according to them, my hosting provider Siteground has some low server settings.



site ground will not change any server settings.



Site ground is advertised by cs-cart.



Is anyone else using siteground shared server and has upgraded to pro?

if so please reply, this would eliminate the reason given by cs-cart why i have problems upgrading to pro

Hello,



My name is Nikolay Todorov and I am CTO @ SiteGround.com. While browsing through the CS-Cart forum I've noticed your post, which concerned me a lot, hence I would like to add some comments on it.



Let me start with why some server side limitations are essential for shared hosting environment (even though you might be aware of that already). The nature of the shared server is such that no matter how powerful or how well optimized the machine is, it is still possible that one user and even one application consumes most of the server resources and overloads the machine. Thus all other accounts on the server stop responding and become inaccessible.



So, certain limitations are needed to ensure that all accounts hosted on the same server maintain top overall performance. This is a standard procedure for every hosting company, not just SiteGround. Unfortunately, we cannot maintain server stability if we don't have strictly defined limits that basically protect users from themselves.



I've searched through our ticketing system and found your case. According to it the required PHP settings are:



memory_limit - 256Mb;

default_socket_timeout - 300sec

max_execution_time - 600sec



Honestly said, I believe that a standard shared hosting server that runs PHP with the above limits would be easily killed just with few badly written scripts. And believe me there are tons of such scripts hosted everywhere including our servers and managing the resources they drain from the servers is not easy at all. Therefore, allowing every customer to change those limits is a very bad idea.



Anyways, I would love to hear some other comments from other CS-Cart users who tried to upgrade to Pro on shared hosting server, no matter whether this is SiteGround.com or other hosting company. I would also like to hear comments from CS-Cart representative about whether such high PHP limits are really needed or there is another way around.



Thanks,

Nikolay T.

Those limits should be fine for any site that would use shared hosting to begin with. Depending on the store, the memory limit is the only one I'd be concerned about. Given that product imports and other such administrative functions can be quite memory intensive (for brief periods of time). But a large percentile of cs-cart shops should run fine within those limitations.



I'd be interested to know what limitation the OP is running into (assuming) upgrading from Community Edition to Professional.

I ended up doing a new install of the pro version the hard way…

People here need to understand that sloooooooooooow to nooo helpful support in resolving issues that should not even exist, or just pointing fingers to hosting providers is not professional!!



These are shopping carts you are dealing with. This means there are businesses depending 100% on a shopping cart.



There will be no more upgrades or edition upgrades on my part!!

If you search the forum for failed upgrades, you will find that 99.9 % were due to server issues/configurations. I, myself, have had to download clients files and databases and upload them to my server to perform the upgrade and then back to their server due to their server not being able to handle the upgrade.



I agree with Tony and even the 256 memory limit is fine as that is what I have my limit set to and I have not had any issues whatsoever with upgrades.

[quote]

People here need to understand

[/quote]

Actually @carbjetkits people here are other users just like you taking time out of their day to try to help you. So we don't really need to understand anything!



Your response comes across as extremely ungrateful and quite condescending. But I think you've accomplished your goal, you certainly won't get any additional help, support or advice from me.

That is not for those that are cs-cart customers, but to those that sell cs-cart and advertise the hosting company to be used!



and not much to be grateful about when you have to spend your day getting some shopping cart upgrade to work instead of selling.



Would be another story if there would be some minimum server requirements information available before people spend their money.





Its like selling apples and recommend a certain basket to carry them, then when the apples appear to be rotten, blaming the basket that it is too small.



Would be better to be honest and tell people in advance what the exact requirements are Right?



I have not been able to do 1 upgrade without problems, and now when i pay for the pro edition upgrade, i ended up doing a complete re-install.



Frustrated YES!

Happy Customer NO!

Will i upgrade again NO!

Will I use another CS-Cart NO!

Hi to all,



The below update I gonna post is with no intend to argue with you, but I feel I need to reply to the following comments:


[quote name='tbirnseth' timestamp='1323388240' post='127552']

Those limits should be fine for any site that would use shared hosting to begin with. Depending on the store, the memory limit is the only one I'd be concerned about. Given that product imports and other such administrative functions can be quite memory intensive (for brief periods of time). But a large percentile of cs-cart shops should run fine within those limitations.



I'd be interested to know what limitation the OP is running into (assuming) upgrading from Community Edition to Professional.

[/quote]



I can't agree to that. The limits might be perfect for the site itself, but would they be for the server health. Probably most of the applications (CMS, Blogs, Forums, Shopping Carts, etc) are well written and optimized and would not harm a server, but there are quite many that are not that good. So we, as a hoster, need to set limits on the server in order to prevent overloads.




[quote name='The Tool' timestamp='1323408345' post='127564']

If you search the forum for failed upgrades, you will find that 99.9 % were due to server issues/configurations. I, myself, have had to download clients files and databases and upload them to my server to perform the upgrade and then back to their server due to their server not being able to handle the upgrade.



I agree with Tony and even the 256 memory limit is fine as that is what I have my limit set to and I have not had any issues whatsoever with upgrades.

[/quote]



Well, the memory limit is not the only problem here. The execution time required should be also taken into very careful consideration. In order to get advantage of this PHP limitation, the Apache Timeout has to be increased as well, otherwise the client connection will be terminated before the script finish. Increasing the Apache timeout to such a value is literally a madness, because that way it becomes very vulnerable to attacks. Anybody with simple DoS/DDoS attack will be able to bring the service down in a matter of seconds.



In general, nowadays I see more and more applications that require more and more server resource for their tasks like install, upgrade, import data, etc. The task of shared web-hosters to offer cheap solutions and to be compliant with the requirements to all that many applications became very hard. I think, in order to prevent problems like the one described here, developers and hosters should start working together and have closer relationships. That way everybody wins - application providers, hosting companies and most importantly - the end client.



For example in this case, instead of arguing who to blame, I can suggest a solution to this issue, which I hope CS-Cart developers will take into consideration. Instead of doing the whole upgrade process with a single script/task it would be better if the entire process is divided into small and short tasks and use Ajax for the front-end?



Sorry for the long post, but I hope it was useful for most of you.



Thanks

Nikolay T

@Nikolay - First off I'm glad to see a representative of the hosting community actually have a technical discussion here.



As I said, your limits should be fine for sites of the size/scope that would utilize shared hosting.



The upgrade process already is broken into several steps. The steps are separated into 'retrieve upgrade', 'check system', 'backup conflicts', 'upgrade files', 'upgrade DB', etc. Then there are several optional steps following the upgrade to allow someone to review conflicts, etc.



What I describe is the upgrade process between different versions (not different editions). I have no idea about the upgrade of the community edition to the Pro edition. I would look at the community edition as a trial or sample without the 30 day limitation of the Pro edition) and when I wanted to run Pro, I'd simply install Pro and load my products and configure the cart.



Beyond upgrade issues…



I don't think you've really looked at what resources cs-cart uses on a server. If you did, you certainly wouldn't recommend they use more AJAX. Run the following command on a server running a moderately active instance of cs-cart:

netstat -tp 2>/dev/null | grep 'ESTABLISHED|Send-Q' | grep -v ':imap'


You'll find 3-6 (depending on the site's configuration) php-cgi processes for every page load being done. If you dig deeply enough, you'll find that if the site is using the 'files' backend_cache method that the cache files are all in contention with each other and the performance will degrade rapidly. If you use fast-cgi versus suPHP you'll find the PHP processes (still multiple per page) have a long lifetime and the overhead of managing the fast-cgi pools starts to become severe very quickly.

AJAX was intended to be used to dynamically retrieve data upon user request to allow some parallelism in fetching dependent data without requiring a page reload to simply do things like "fill the next selector based on a previous selection". However, cs-cart uses AJAX to load their pages and to perform operations like statistical updates and logging activity. Yes, they also use it "properly" (my definition) for updating info based on a user's request, selection or action. But to use it for every page load is a huge drain on server resources with very little gain if the site is moderately active (though for a low-use site an improvement might be seen).

So regardless of memory, cpu or timeout configurations, cs-cart is a very heavy user of the server and not very kind for use of server resources.

That being said, it is the most functional cart for the money available today.