"an error message" is just a little vague; do you remember the actual error message? Were there debug-logs created?
"an error message" is just a little vague; do you remember the actual error message? Were there debug-logs created?
Well, the error message was pretty vague:
WARNING: An Error occurred, please refresh the page and try again.WARNING: An Error occurred, please refresh the page and try again.
As for the debug logs, would you mean "notice and/or warning log data" from the Review or Export Logs Admin Activity Logs section of the Zen Cart? I am rather new at this so please bear with me. Thanks.
The Zen of cat.
You need to look in your store's /logs folder using either your webhost's cPanel or an FTP (File Transfer Protocol) program like FileZilla. There will be a number of files matching the pattern myDEBUG*.log that will indicate an error with the query_factory class.
You can post the contents of one (make sure that if you're posting one with a filename that includes -adm- not to include your admin folder's name). Use the CODE tag (the # in the edit-strip when you're making your reply) to surround the contents you post.
FAQ on this specific response: https://www.zen-cart.com/content.php...-and-try-again
ZC Installation/Maintenance Support <- Site
Contribution for contributions welcome...
OK. this is good information. I will be finding the debug logs and posting (minus the admin name). And, mc12345678, would that also include something interfering with a shared server, or it that not usually the cause?
The Zen of cat.
OK, here is the content of the debug folder at the time when my customer contacted me yesterday:
Code:[08-Aug-2015 14:54:21 America/New_York] PHP Fatal error: 2008:MySQL client ran out of memory :: select products_id, products_price, products_tax_class_id, products_weight, products_priced_by_attribute, product_is_always_free_shipping, products_discount_type, products_discount_type_from, products_virtual, products_model from products where products_id = '462' ==> (as called by) /homepages/38/d164002731/htdocs/includes/classes/shopping_cart.php on line 660 <== in /homepages/38/d164002731/htdocs/includes/classes/db/mysql/query_factory.php on line 155 [08-Aug-2015 14:54:21 America/New_York] PHP Fatal error: 2013:Lost connection to MySQL server during query :: select count(*) as total from sessions where sesskey = 'fd162fbfd9bd9c5b18e0f88131acda49' ==> (as called by) /homepages/38/d164002731/htdocs/includes/functions/sessions.php on line 66 <== in /homepages/38/d164002731/htdocs/includes/classes/db/mysql/query_factory.php on line 155
The Zen of cat.
OK, a couple more questions (I've never seen that specific error on any of the 1&1-based sites that I support): your PHP version and your mySQL version. Both can be grabbed from the screen displayed by your admin's Tools->Server/Version Info.
ZC Installation/Maintenance Support <- Site
Contribution for contributions welcome...
OK, I got these stats (if they are not right please let me know, they were being pretty specific in ways I am not familiar with):
PhP version 5.4.42 (Zend: 2.4.0)
My SQL-Client API Version 5.1.73
PhP memory Limit: 120m
The Zen of cat.
Although 'interference' is quite unusual terminology to describe a server related problem I have to admit that I've actually been thinking along these lines myself - In fact it was this possibility that prompted to ask/query about whether it was somehow related to products with attributes.
Products with attributes are a lot more demanding on a server than products without attributes - And I *have* seen server/sites with a *similar* problem to yours whereby occasionally an attributed product couldn't be added to a cart because it was apparently out of stock - but only intermittently. In each of these somewhat rare occasions they have been accompanied by MySQL server errors that had been logged.
I realise that hindsight is 20/20, but your recent log entry with the SQL server running out of memory has pretty much confirmed my suspicions that this is almost certainly the reason for your problem(s).
I'm always somewhat dubious about this common suggestion, because it doesn't really address the issue. A *lot* of people simply take the advice and get the cheapest dedicated server they can find, which generally speaking will have less CPU power and a lot less memory than the shared server that they are currently using - In other words many find themselves with either the same issues, and in many cases even bigger issues, and to resolve them they are 'sold' a bigger and bigger priced hosting plan until eventually the problems do go away.
In other words a 'dedicated server' is, in itself, not a solution to the problems.
HOWEVER, having said that, if the current shared server is grossly overloaded (as many are), then even a low budget 'dedicated server' may invoke a solution to the problem - But so will another *shared* server that isn't as overloaded.
It isn't generally isn't the *traffic* that is the issue - You could have very little traffic, but if another site on the same shared server is hogging all the resources available then you'll still get this kind of problem.
A high power dedicated server with lots of RAM can 'hide' (aka 'fix') all manner of problems and issues, so I can only say Yes, this will be *one* way to solve the problem - And if you have a *really* busy site it may even be the *only* solution.
However, there are a wide range of other options that will also invoke a cure/fix rather than jumping from one extreme (overloaded shared server) to the other extreme (high powered dedicated server).
Of the 60 or so eCommerce stores that we host or maintain, we only have *one* that we've had to give a dedicated server to, and this store is averaging between 50,000-60,000 *sessions* per day (100,000-150,000 page requests) - According to ZenCart's counters.
The other sites rarely reach 3000 sessions ( <10000 page requests) per day and hosting on a 'good' shared server isn't a problem.
How does your counters compare to these?
Anyway, as I was saying, I'm pretty confident that your problems *are* server related (not code related), so the solution does mean a change of servers (unfortunately).
What *I* would suggest though is probably going to be a little different than most, and that is to request your host move your site to a *different* server under the same hosting plan. Although the 'new' server will almost certainly have the same specs and resources as your current one, it will be hosting *different* customers and different sites and these customer/sites could easily be making less of demand on the hardware. which will in turn leave more resources available for *your* site.
If that doesn't solve the problem (or your host isn't willing to migrate your site) you'll need to look into other hosts, or a 'better' plan with your current host.
You should also keep in mind that shared servers aren't 'static'. The fact that they ARE shared means that they'll often start out 'good', but as the host adds more and more customers they get slow and slower until they eventually get overloaded (as yours seems to be) and bigger issues arise. Also, because they are shared, it only takes one customer running 'faulty' software to cause problems for all customers on the server - Generally speaking, the host will quickly identify these customers and have them removed.
Upgrading to a 'dedicated server' is only a viable solution if the server itself has enough resources to handle the demands of *your* site. As a general rule It is better to be on a shared server with 8-16gig of RAM (or more) than a 'dedicated server' with less than 1Gig.
A dedicated server is, in my view, a last resort to fixing server overload/out of memory issues rather than the 1st resort.
On *rare* occasions - IOW, a REALLY BUSY site, a high power dedicated server is going to be the only solution. Unless you are pulling in over $200k in annual sales you probably don't need something like this. A non-overloaded shared server is almost always the better option.
Cheers
RodG
Last edited by RodG; 10 Aug 2015 at 12:34 AM.