Wordpress Themes - WP Forum at BFA
Click here to register or to donate.
Auto self-registration is not available here - far too many spammers. This forum has many, many backlinks and because of that there is an intense desire among spammers to drop their links here.

Wordpress Themes - WP Forum at BFA » WordPress Themes » Atahualpa 3 Wordpress theme » New Versions, & Updating »

Number of Queries and CPU Usage getting worse with each version


  #1  
Old Jul 13, 2009, 05:28 PM
extremecarver
 
105 posts · Jul 2009
I don't know how you and your websites cope with it, but as much as I like atahualpa for its adaptibility and options, as much I hate it for it's abuse of CPU Cycles and queries.

Using wordpress default theme I can get by with around 50 queries per pageview with all my plugins activated. Going for atahualpa this goes up to 120 queries on 3.3.4 or 160 queries with 3.4.1

Simply said it's a disaster and doubles the time to build a site. This goes so far that even with wp-superchache in full on or bad behaviour on and wp-supercache half-on in the evening my dedicated server crashes (celeron 2.8 ghz, 1GB Ram, running Suse and 2.6.29 kernel).
My site ( www.openmtbmap.org ) gets currently bout 10.000 pageviews a day, so this should not be a big problem.

However with each atahualpa version cpu-use got more devastating leading to a lot downtime of my site.

Is anyone actually running atahualpa on a page with say 10.000 visitors a day without getting problems with CPU usage? I got banned from my first hoster for cpu-usage and now I have problems keeping my own server from crashing.

Atahualpa is the main culprit for this. I have tried out more or less any cpu wordpress optimization guide, but using atahualpa seems to be attacking from the wrong side. Because over 10.000.000 database queries each day are simply too much for a simple site.

inline vs external css options showed no improvements at all.
  #2  
Old Jul 15, 2009, 02:23 PM
Flynn's Avatar
Flynn
 
3,768 posts · Oct 2008
Munich, Germany
If you save the options of each menu tabs the number of queries goes down. Run your site with another theme and see if that helps you as much as you think. You may be overestimating the resource usage of Atahualpa based on that number of queries. Reading is cheap in MySQL, and if you run super cache you shouldn't have the queries on each page view.

If you think that CPU usage is an issue then having CSS and JS internal will be better.
You could also create a static CSS file after you're done with customizations.

But I don't think Atahualpa is the sole reason for your issues. Your site takes 4.5 seconds to render. There's no reason why it should be that slow. On a fast server it should render in 0.1-0.3 seconds with a bunch of plugins. On a budget host still below 1 second. You also seem to have 2 different kinds of caching active while none of them seems be actually working.

If you try another theme, make sure you leave all that other stuff on as well for a fair comparison.

Last edited by Flynn; Jul 15, 2009 at 02:30 PM.
  #3  
Old Jul 18, 2009, 11:59 PM
pwsolutions
 
1 posts · Jul 2009
Unless you have your max-queries set abysmally low, the number of queries from Atahualpa is certainly not your problem.

I rewrote Atahualpa 3.2 to use a database for its options and php objects to display the pages and managed to get the number of queries per page down to between 10 and 20...less than the default theme.

The result from a speed standpoint was a measly 0.05 to 0.08 seconds off of each page. ( 0.12 to 0.18 compared to 0.21 to 0.25 or so )

So...the queries shouldn't be an issue. But if you are certain that they are, you might want to see if your mysql max-queries setting is too low as that could definitely be problematic on a high traffic site.
  #4  
Old Jul 19, 2009, 03:32 PM
extremecarver
 
105 posts · Jul 2009
Thanks for your answers, I did not reply yet because I still have not implemented them with testing.

I saved all subpages and am down to 48 queries, speed improvement more or less none. deactiving db_cache helped a bit to get down cpu use, db_cache tries to minimize queries too, but somehow does not work on my main site server, I have another site where I run a backup of my site ( www.extremecarver.bplaced.net ) so people can access my site if on my main site my server has crashed.....

I will try out moving to static css tonight, to see if it makes any difference.
I really don't understand what is wrong and why my site loads so slow (I was kicked out from my first (budget) hoster for CPU use, but would expect a Celereon 2.66ghz with 1GB running newest Suse 11.1 with all updates and Plesk as interface to be able to cope with the load, especially if moving wp-supercache AND widget cache for all but two light widgets). When using php_speedy I got pageload times around 100seconds, so php_speedy made it even worse....

atahualpa doubled my page load time on my backup site versus standard skin. So 0.5 vs 1 sec. On that page I also experimented by deleting all plugins (moving them to another folder) but that would not improve page-load time either by a lot.

Current issues with my server: e_accellerators not installed (supposedly halves the cpu time) and mod_headers not in appache. I can't find out how to integrate either though, as I don't really understand how to do it with plesk, and adding those two things with yast seems to have no effect.

Is max-queries changeable with myphp (will edit this it if I find out via google)?

My current page load time, with server idle is around 3 seconds, so there has to be something drastically wrong. It's difficult for me to notice changes, as cpu load usually races up to 2-3 on a singlecore machine because of backlogs waiting to be processed.

edit: okay I got mod_headers enabled (it was already installed). cannot yet see any improvement. My next step is trying to find out about eaccelleration on suse 11.1

maybe something in .htaccess wrong (i think most is really needed)???:
Code:
# Expire images header
ExpiresActive On
ExpiresDefault A0

ExpiresByType image/gif A2592000
ExpiresByType image/png A2592000
ExpiresByType image/jpg A2592000
ExpiresByType image/jpeg A2592000
ExpiresByType image/ico A604800
ExpiresByType application/pdf A604800
ExpiresByType text/css A6040800
ExpiresByType text/javascript A6040800
ExpiresByType text/html A6040800


# KILL THEM ETAGS
# FileETag none
# Header unset ETag 
FileETag None


# BEGIN WPSuperCache
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
AddDefaultCharset UTF-8
RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{HTTP_user_agent} !^.*(Android|2.0\ MMP|240x320|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|hiptop|IEMobile|iPhone|iPod|KYOCERA/WX310K|LG/U990|MIDP-2.0|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|Playstation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|Windows\ CE|WinWAP).*
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html.gz [L]

RewriteCond %{REQUEST_URI} !^.*[^/]$
RewriteCond %{REQUEST_URI} !^.*//.*$
RewriteCond %{REQUEST_METHOD} !=POST
RewriteCond %{QUERY_STRING} !.*=.*
RewriteCond %{HTTP:Cookie} !^.*(comment_author_|wordpress|wp-postpass_).*$
RewriteCond %{HTTP_user_agent} !^.*(Android|2.0\ MMP|240x320|AvantGo|BlackBerry|Blazer|Cellphone|Danger|DoCoMo|Elaine/3.0|EudoraWeb|hiptop|IEMobile|iPhone|iPod|KYOCERA/WX310K|LG/U990|MIDP-2.0|MMEF20|MOT-V|NetFront|Newt|Nintendo\ Wii|Nitro|Nokia|Opera\ Mini|Palm|Playstation\ Portable|portalmmm|Proxinet|ProxiNet|SHARP-TQ-GX10|Small|SonyEricsson|Symbian\ OS|SymbianOS|TS21i-10|UP.Browser|UP.Link|Windows\ CE|WinWAP).*
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1/index.html [L]
</IfModule>

# END WPSuperCache

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress

Last edited by extremecarver; Jul 19, 2009 at 05:00 PM.
  #5  
Old Jul 19, 2009, 08:45 PM
bushtool's Avatar
bushtool
 
93 posts · May 2009
According to pingdom, you have over 700k in image files. I am running about 90 plugins (I'm a plugin and sidebar junkie) on my site on a budget host and test out only a few seconds slower than your site, www.d4v.org.

A couple of things that helped me a lot were ImageShack Offloader plugin and Use Google Libraries plugin.
  #6  
Old Jul 20, 2009, 05:29 AM
extremecarver
 
105 posts · Jul 2009
Bandwith is not a problem at all (yet), so offloading images will not help much.
Although i have unlimited traffic (really unlimited), my map downloads go into the TB region every week, so no worries yet about that. The website traffic (1-3GB a day) is minimal compared to the map download traffic (about 100-400GB a day).
Its mainly the frontpage with lots of images.

I am working on getting xcache or eaccelerator compiled on Suse 11.1, but seem to be doing something wrong there.

I did configure my httpd.conf settings a bit and now my server-load is pretty stable (mostly around 0.2 - 1, not going into 20-30 region anymore) and redirect .com and www to http://mydomain.org so that supercache creates no copies of identical sites for the different domain aliases.

The main problem of why my sites take 3-4 secs to load still consists however....

I will try out wp supercache plus, maybe its faster.....
  #7  
Old Jul 20, 2009, 07:07 PM
extremecarver
 
105 posts · Jul 2009
okay, I now moved on to wp supercache-plus and compiled and enabled xcache for my server. Memory usage now seems to have divided by 4, and page rendering time decreased by about 50%.

My site seems much faster now.......
Let's see how it copes tomorrow evening.

2 seconds remains still a bit unacceptable though, I don't know what's wrong with my wordpress installation that it needs so much cpu time....

Using standard theme decreases page-load time to around 1 second.

edit:
Optimizing my mysql and qcache settings I get idle pageload time using atahualpa down to around 1.6 seconds....
I still don't understand how you get pages built in aroung 0.3 seconds....

Last edited by extremecarver; Jul 21, 2009 at 07:29 AM.
  #8  
Old Jul 21, 2009, 06:01 PM
extremecarver
 
105 posts · Jul 2009
Well I just did a test without page caching and all plugins disabled except debug-queries of 1. nearly empty page, 2.frontpage, each 10 reloads
1a) with default theme load time between 0.6 and 1.2 seconds. Average 0.9sec
1b) with atahualpa theme between 1.6 and 5 seconds. Average 2.5sec
2a) frontpage with default theme between 2 and 3 seconds. Average 2.3 sec
2b) with atahualpa between 2.3 and 7 seconds. Average 3.8

Enabling widget-cache and csprites reduced pagecreation times a bit but not much.

Using atahualpa my server needed much more run in prefork. maybe worker would be better suited for atahualpa, or moving to lighthttpd, but I am a bit afraid to change this and opensuse 11.1 means compiling most of this before using. Debian has much better repositories for apache. My next XAMP will definitely work on debian/ubuntu and not suse.

maximum mysql query time 0.08 seconds. Rest of time is needed for php.
So yes, you are right that if mysql is properly configured databased calls are very very cheap (escpecially if qcache, threadcache and keybuffers... are configured and have enough memory available).

Nevertheless on my server Atahualpa adds around 1 to 2 seconds to pagecreation time. Enabling all of my 30 plugins does not add more than 0.3-0.4 seconds to page-creation time. So the main problem persists that a) wordpress is slow and b) atahualpa makes it even slower.


Where can I find a howto on how I move to static css file? If that also offers no big improvement I will probabely rather switch to joomla than to another theme.
  #9  
Old Jul 22, 2009, 08:33 PM
Flynn's Avatar
Flynn
 
3,768 posts · Oct 2008
Munich, Germany
If performance is an issue consider powercms.org (German) if they have English docs by now. It is a performance fork of CMS Made Simple (which is also nice).

As for WP and Atahualpa. If WP Super Cache is indeed running you should absolutely not have these issues. It's static pages served with mod_rewrite. If your server cannot handle that then there's an issue with the setup.

I am also running a server with Nginx & XCache (and Wordpress), Atahualpa is very fast on that server.
  #10  
Old Jul 23, 2009, 01:47 AM
extremecarver
 
105 posts · Jul 2009
I know that nginx would eliminate any probs, but I'm a bit afraid to move to it, as there is no documentation on how to move from apache to nginx for Suse 11.0 or 11.1 that I could find (plenty for CentOs or Debian).

The problem is that many many of my visitors have cookies from commenting, and wp-cache was still too slow for my server. Now with wp-supercache plus, xcache, mod_php, stripped down mysql/apache cpu 15 min load stays at around 0.3-0.4 in the "rushhour", but I'm still not really satisfied.
  #11  
Old Jul 23, 2009, 04:24 PM
bushtool's Avatar
bushtool
 
93 posts · May 2009
I just installed xcache and my queries went from around 150 to 50-60 on a load. Also installed this wordpress plugin:

http://dougal.gunters.org/blog/2008/...r-wordpress-25

Did not really notice any speed up for the site though.
  #12  
Old Jul 23, 2009, 04:59 PM
extremecarver
 
105 posts · Jul 2009
don't use the xcache plugin but wp supercache plus in half-on mode.
If you feel really fast, go for the svn version and implement all the needed bits to use fragment caching.

That should really blast away any other wordpress install if you keep dynamic widgets and likewise to a minimum. Fragment caching means that not whole websites are cached, but all static elements.

I'm not sure how much xcache helps without a caching plugin. My wordpress admin pages load a lot faster now however (as they are cached too).

For me the main difference is however not speed, but cpu-load which drastically reduced.

wp supercache plus can be found here: http://murmatrons.armadillo.homeip.n...wp-super-cache
  #13  
Old Jul 29, 2009, 12:53 PM
3ukman
 
22 posts · Jul 2009
Quote:
Originally Posted by Flynn
If you save the options of each menu tabs the number of queries goes down.
I just saved all tabs and queries are down to 36 from 120. That is 36 from 120.

Could you give us a script that does this , or include in a future release.

I was considering switching theme when I saw 120 queries .. but this is much better...

Also , does it mean if more options are set different from default , then more queries.... ?

Last edited by 3ukman; Jul 29, 2009 at 12:56 PM.
  #14  
Old Aug 7, 2009, 06:26 PM
Flynn's Avatar
Flynn
 
3,768 posts · Oct 2008
Munich, Germany
I will change that in the next or next but one release
  #15  
Old Oct 27, 2009, 02:39 PM
Gravity's Avatar
Gravity
 
34 posts · Sep 2009
Quote:
Originally Posted by Flynn
I will change that in the next or next but one release
I'm unsure if this has been done in the latest version? It doesn't appear to be.

Last edited by Gravity; Oct 27, 2009 at 02:43 PM.
  #16  
Old Apr 27, 2010, 06:27 PM
Gravity's Avatar
Gravity
 
34 posts · Sep 2009
Hi,
I gather this bug/issue remains, am wondering if it is slated to be fixed in a future version?
  #17  
Old Apr 28, 2010, 05:51 AM
Flynn's Avatar
Flynn
 
3,768 posts · Oct 2008
Munich, Germany
I already transformed the 200+ queries into 1 query / pageview for 3.4.7 which will be released any day now. I'll probably leave the import/export feature for the next version so 3.4.7 won't be delayed any longer
  #18  
Old Apr 28, 2010, 05:55 AM
extremecarver
 
105 posts · Jul 2009
Great, please really do bring out a 3.4.7 that fixes all bugs that you can quickly solve (like all the ones where there is a patch on here on the forum already) soon. And unlike 3.4.6 that left fixed bugs (like comment form disappearing) open, but include a possibility to disable Atahualpa Post Option easily, as they are incompatible with loads of plugins.
__________________
Don't settle for lousy expensive Maps - Get free Maps based on Openstreetmap with great autorouting for cyclists, hikers and Mountainbikers at http://openmtbmap.org
  #19  
Old Apr 28, 2010, 06:28 PM
Gravity's Avatar
Gravity
 
34 posts · Sep 2009
That's good news, Flynn.
On the original topic, I'm serving 10 to 15K page views a day using Atahualpa with wp-united for phpbb3 forum integration. I have had to move to a dedicated host because of the forums, but my blog alone was already causing problems on the shared host (due to CPU usage).
This new Atahualpa version will help my ongoing efforts to optimise for speed (user experience), now that CPU is not a problem (dedicated server).

Last edited by Gravity; Apr 28, 2010 at 10:44 PM.
  #20  
Old May 2, 2010, 12:11 PM
extremecarver
 
105 posts · Jul 2009
Push push. We're waiting since August last year.
__________________
Don't settle for lousy expensive Maps - Get free Maps based on Openstreetmap with great autorouting for cyclists, hikers and Mountainbikers at http://openmtbmap.org
  #21  
Old May 5, 2010, 10:12 AM
heaven99
 
wonderful news, please also do try to fix any previous errors or bugs, thanks

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
SQL queries for option parameters gejba Atahualpa 3 Wordpress theme 5 Jan 20, 2010 12:58 PM
[SOLVED] Can't upload the latest version to my Dashboard because I have older version rhymes New Versions, & Updating 2 Apr 25, 2009 11:22 PM
Debug Queries js9600 Plugins & Atahualpa 0 Apr 23, 2009 09:25 PM
Pages not odering according to number jamaas Atahualpa 3 Wordpress theme 4 Mar 20, 2009 07:52 AM
Usage of Affiliate Link Cloakers Nefeli Atahualpa 3 Wordpress theme 1 Feb 26, 2009 07:22 PM


All times are GMT -6. The time now is 01:53 AM.


Powered by vBulletin® Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.