Server Reset While Page is Loading

A vanilla install (no active plugins) running Twenty Twelve should run with only 32M of PHP memory without the slightest problem. If this is not the case on your domain, then it’s either a server or database issue.

Yes, that was the only choice in the face of no viable support from the hosting support.

That does run – Ugly but runs – Now to reassemble, piece by piece, the old set and see where it breaks, or If it breaks.

I’ve said all the time its a server issue due to the box saying its is the SERVER that reset, but my hosting support won’t agree.

Do you have access to server/site error logs? They might help to track down the culprit(s).

No, but the support folks said it was fine from their end. My support guy had me send him a capture of the tracert to my site form here, and took the problem to someone in his place who said he knew what it was, and would have it fixed by the time I got up, several hours. He said it showed that I was not able to access their particular server from where I was in the country. They, of course, won’t put me back in touch with that person when they come back in to work, claiming “policy”. I let them know the problem was NOT solved, that nothing was different this morning than when I first called.
This one person alluded to some DNS issue and was “well aware” of it and how to fix it. No details given even though asked for.
Even though WordPress might not be the “problem”, as you can see, I am being forced to find a WordPress solution.

Based on the above, there is noting on earth that we could suggest that would help. Obviously everything is not “OK” at your hosts’ or domain registrars’ end (assuming they aren’t one & the same). My bet is on the hosts given the server connection reset message. I think they have some sort of internal networking issue. All I can suggest is that you keep pressuring them and perhaps start looking around for a new host in the meantime.

Yup. But i have a very unusual task I am using WP for so everybody might be correct.

Big question gleaned from my conversations with them: Are there there page limits in WordPress? Not Posts but Pages. I have a page for each business. There are literally thousands. There are queries required to generate each page with its associated business information and updates. This is why I’m using WP. Is this too strenuous for the system? I built this in WP for its ability to do this kind of job – and it does exactly what I need! Does it not have the muscle? Is there a way to give it more?

Naturally enough the hosting support is saying I have too many pages, too many queries, and there are a lot, with more in the making.

Modified php Ease Theme.

Are there there page limits in WordPress? Not Posts but Pages.

No. There are theoretically no limits on the number of Pages you can have on a WordPress site. From a practical perspective, the permalink structure that you use and the load limitations of the server can all be factors affecting performance.

That’s the strength of the program. If I’m correct here, WordPress doesn’t call all the pages or all the data at once, only that which is needed for the particular page display. No actual pages are produced. This is what I want so I only have the data which is normally passed very fast. Naturally enough we’re not going to convince my host that their server is at the root of the problem in limiting the number of queries passed. The next issue is that of is there a hosting company that doesn’t throttle one’s queries. There are not many here but they are necessary to load business specific information – nothing out of the ordinary here, just address, phone and map data – text and numbers. They now say that there is “some problem” with the number of pages and the fact that a theme switcher is being used.
The Actual problem is with the wp_post file having been damaged by their server reset in the middle of a save. Unrecoverable. Data and time lost. I used backups that were fine the week before that don’t work now, indicating there is some change on their end. i rolled it back to several, once working, iterations which all worked when they were taken.

I’d much rather switch than fight.

only that which is needed for the particular page display

Correct – unless you over-ride this by way of a custom query.

Interesting but not good news for folks who want to build sites with thousands of pages – WordPress is a great platform to do that on but shared hosting providers have timeout limits on their servers that help cause problems with large WP installations. As you said Esmi, the problem is at the server and it is within the provider’s control but something they will not alter for one customer. It can only be set globally. Found a reference to this on a linux forum – a control panel where this is set.
Possible solutions: expensive virtual hosting, more expensive special accounts, your own server, or find a provider who does not impose these limits. Know that this is a choice the providers make and is not actually written in stone as they say. So far, however, no provider will admit to such throttling – they all say they support unlimited pages – this might not be any more true than the present provider who is one of the big players and makes the same erroneous claim.

Also for whatever it’s worth, the limit experienced is 5000 pages and is associated with a 30 second timeout on the server. To load that many pages into the dashboard takes a little time but not exorbitant showing the 30 second setting is actually too small. This is the default, out of the box setting and can be changed as needed.

In order to determine if the number of pages was actually the problem, I took a logical approach and started with a clean install of WordPress and used no plug-ins. Themes were the two stock themes then a random set with which to test. I started with a working 900 page load, then went to 3000, 4000 before reaching the reset number. With each theme tried the server reset at about 5000 pages.

At no point have they offered to actually solve the issue in place, once it has been established the problem IS at their server and not something that can be fixed from this end at all.

I’ve got the same/similar problem. My main site is fine, and I can update pages without issue. However, I am starting to redesign the site with a new theme, so I another copy of my whole site on a subdomain. No issues with it at all, either…

…until I switch themes. I switch to the new theme, then I can’t update pages or posts (I have 900+ pages). I’ve tried numerous things to get it to go, clearing the htaccess file, changing php.ini settings, resetting internet/router, even calling godaddy (to which they had no other suggestions after a 20 minute conversation). In Chrome its the 324 error, in Firefox, I get “The connection was reset: the connection to the server was reset while the page was loading”. I even tried a new subdomain, new database and fresh WP install. I’ve tried doing things on a different network, as well, but no dice.

The theme designer has had noone else with a similar problem, and the theme runs fine if I drop it into a localhost setup, so its nothing that my host wants to blame it on.

Figured I’d throw my experience into this thread, so you know you’re not alone (and can cross some other things off your list, possibly).

No, we are not alone.

I’d like to share with you and everybody some of the results of my attempts to solve this. I hadn’t mentioned the provider-host for my site. It also is GoDaddy. I made a lot of calls to them, talking with a different tech each time where none of them were willing to admit the problem is on the GoDaddy end. I came back to WordPress and as you see in this thread one of the WP knowledgeable folks posted the skinny about WP. She’s on point with her analysis. Here’s what’s happening with my instance: GoDaddy has timeouts set on their servers. This is a default. I found the actual screen shots for this setting on a linux server, on the web. This timeout is set to 30 seconds by default and GoDaddy utterly refuses to change it , not realizing or caring that it will improve, not degrade, performance(ultimately it helps sell more expensive service packages, upgrades. Why not just advertise limits instead of effectively throttling?). Most of the tier I support people are totally unaware of this, themselves never being server administrators. What this setting causes is when you have a lot of pages, and especially if there are a lot of queries, speed slows to the timeout limit and generates a server reset.

OK. I have a site that started with over 6000 pages and is planned to become rapidly twice that size in pages, then add posts on any, or all, pages, with custom database calls that were, and are, not a part of any theme – entirely developed by, and written by me. I ran into the same problem, and thanks to GoDaddy techs either not knowing, and/or their refusal to up the timeouts, I was left with solving it myself. That solution led to their losing this customer for that service.

First, solution – I moved the site to another host. Didn’t have to move the registration, just the hosting involving only a DNS setting change, and of course buying, and setting up, the service. I now host this site at justhost.com while GoDaddy maintains the registration. Called around and got the responses from several hosts and they were one of the least expensive that explicitly said they have no page limit and have their servers and services set up not to timeout for normal processes. They even offer some options on optimization. Both services an troubleshoot down to the line event.

So what was the actual problem? In my case the timeouts occurred at nearly 5000 pages. I deduced this by starting with a fresh, clean, WordPress installation, with no plug-ins or widgets, using stock 2011 and 2012 themes, then added a couple of extra random themes for testing. I started importing pages incrementally until I got to 5000 pages and where the resets began. Anything less it would work, but slow after about 3000 pages. My limit of 5000 pages may have been from having them change my php.ini file so it used more memory, but that’s on their end and they didn’t want to do it – I can be a persistent b******* when I wanna be :). This was done on the local side also with a slight increase in performance. I’m running xampp.

In your case you might be passing some serious queries making it timeout with less pages but same load. These timeouts are dependent on load and not number op pages. Depends on how your theme(s) and your custom code are operating. Plug-ins, widgets, are a major issue also. And especially – any custom code. I try to keep mine short, clean, safe.

I had the same experience on my localhost. It ran slow but my machine is not a bear, more like, koala or lemur. So between what I learned, Esmi’s input, and having this local setup that did not reset ever, I said this is the wall and it’s time to look for another service. With justhost, it’s faster on the server than ever. No glitches. The one issue I did have was justhost’s security. Their service is not easy or intuitive to set up due to that, but their help is good and once this is done, you’re in, end of story. I’m not plugging their service or anything. Do some homework. There are several in any price range that offer no limit to pages. Due to variance in what we’re dealing with, no host can offer nirvana, just what works for your particular setup.

Multiple themes: There are several plug-ins that say they do this cleanly. I tried a few and found the jonradio-multiple-themes to work for me. I don’t know how it will work as well for anyone else due to the fact I am switching between half a dozen very similar themes, all modified from the original, as opposed to totally different themes, possibly making theme switching easier for the plug-in. Know that theme switching is a touchy process that is difficult for WordPress, so any plug-in that claims to do this has to be cleanly written and possibly for a specific set or type of theme set. Add to the pie that themes also are varied. Add any plug-ins, widgets, and forbid – as i live on – custom code, and —— Whew!

The lesson learned here is that not all providers of any service are equal. Some are better at some things than others while others are better at some things than some. I still have sites and domains with GoDaddy with no intention or need to move them. I Can tell you that Both these service have knowledgeable and nice folks on the phone to help you. That’s a plus. Short wait times, pleasant crew, easy to understand, and they know when to get tier II or III. Who wins? The customer!

If you don’t mind me asking, which other hosts did you contact? Was one bluehost? (I’ve been considering them). I have appreciated godaddy’s service, until now…

I realized, since WPs database keeps media as a “post type”, I’ve got over 9000 pages now. That would help explain it.

I did this through a lot of homework on the web and they were the first to even respond on the phone within a reasonable time. I had already picked them out before calling from homework. Having been on the net I had services from everybody from Waymark to Verizon(Yeech!) and Time-Warner [Sorry ?? ] then went to GoDaddy after dotEarth. GoDaddy is OK – my site just overloaded their setup and I got a better deal.

So you’re saying your post_type is page?

The servers are croaking due to the amount of information being transferred overall – load. That database on the server end is taking too long to respond. To resolve this one has to wade through logs. Look at the timing on queries and see where it loses it’s cool. It’s bad enough to wade through your own logs. Ever wade through someone else’s? When I started building I did have some of this in mind. For instance some of my queries are combined as opposed to separate queries. I chose a php “friendly” theme as to minimize problems with my own code and the plug-in execphp.

Another issue here was with any visual editor in WordPress. I chose to turn off visual editing altogether. Eliminated a lot of problems early on. Boo to anything that rewrites my code. Dreamweaver has the strength of being able to work in both modes carefully but cleanly.

Another factor not mentioned yet is the internet connection speed. Slow connections, lots of hopping. The venerable tracert and ping tools at the command line tell the real story.

In my peculiar case I’ve had nearly no problems with the theme and theme set offshoot that were debilitating – nothing unsolvable. I’m running several stripped down, customized versions of one theme as opposed to trying to load several unrelated themes. The best I can suggest there is at least have all the themes from the same source.

Ka ora’ Ka ora’
Hī!