Host whinning about demanding cms.Is this usage really demanding? 13 queries & 2.43mb

[buggedcom]

Hi, we've just put together a cms and in my mind it has a fairly small footprint. However there are one or two problems with the server and the admin seem to think it is the demanding script, however I don;t think it is demanding in the slightest, but I don't know much about the results returned by memory_get_usage();

The site is similar in size to http://www.fried-online.co.uk/ and uses the same CMS (the actuall site is in dev so can't be shown)

Each page compiles from database data and templates. It is then cached and server from a semi static file. The compile time of the first run script ranges between 0.8 and 1 second. It makes 13 mysql queries and has 2.43MB of memory used. When the page is cached it compiles in 0.018 seconds, has 0 db queries and uses 1.07mb of memory.

Are the hosts justified in saying this is a demanding script? If it is why is it, what are reasonable memory uses and db query counts? (I know the impact of a script is more than just db queries)

[CommanderZ]

13 queries is too much. Are you sure you cannot reduce it throught joining etc. ? I think 5 queries is a bit much and 1 second is too much too, but I don't understand the compilation. How often is it compiled? Daily? Hourly? Every 30 seconds?

EDIT: Just a thought...the Fried website is quite simple, it seems to be small-to-medium sized website. 13 queries would be reasonable for much larger webs carrying a lot of information...

[kromey]

13 queries to me does seem a little on the high end, but not enough that I'd complain about it if I were a host, especially since you are caching the resulting pages (incidentally, how long are you caching them?). Using 2.43MB of memory doesn't seem all that much to me, but if your host is complaining about it you might be able to reduce it by unsetting variables that are no longer needed and freeing database results (e.g. with mysql_free_result) once you are finished with them. Your script's execution time is relatively long, however, so you might want to see if you can't optimize your script any to run faster (I'm referring of course to generating the cached page, not to serving up a cached page).

There are no hard answers to what defines a "demanding" script. Scripts that do image manipulation, for example, can easily defy PHP's default 8MB memory limit. However, if your host is complaining, try to consolidate database queries (see if any can be JOINed or UNIONed - the MySQL forum here would be an awesome resource for this), and do what you can to reduce the memory requirements and execution time. In your particular case, though, if after making every reasonable effort to optimize your script your host still complains, find a different host, because honestly your script is far from what I would define as "demanding".

[Dan Grossman]

0.8-1 second is awfully slow. Are there not indexes defined on the database tables?

[TheRedDevil]

The number of queries in itself does not really have a impact on the load time, it is the query they perform which makes the impact.

You can easily write one bad query which would take just as long time as 20 advanced but optimiced queries.


Your script execute awfully slow, so you should take a look and most probably do some adjustments.

First do a check and see which part of your script require most time, then check what you can apply to speed it up. Keep doing that until you have covered all areas and the script execute fast.

The issue can be the queries, in that aspect take a look if the database structure can be altered or indexes can be applied to speed it up (in addition to rewriting the query).

Though in this case the issue can just as well lie in the "cache" solution.

[buggedcom]

Thanks for the input. The initial queries are high. They are the highest amount for the home page which pulls in content from different areas of the site. This is the maximum creation time and query count. The average page is less depending if comments and user details are being used or not.

The query speed really isn't the issue. Basically when he page is compiled it is compiled from various template blocks from which the primary page template comprises of. Each block is then processed from a different block templates untill each has been done. the block codes are subsituted in the primary template and the template is thereby compressed to remove all uneeded white space (ie outputs the html in one line) (sub note: I actually find this quite handy. it gets rid of any annoying layout issues due to spaces where they are not wanted). The page is then outputted to the buffer, the buffer is then read and cached dependant on the page settings.

Although the inital query count and page compile time may be hi, would you not say it is offset by the fact that the cached page compile time is generally 1/10th of the time it is used to originally compile, and the fact the compiled pages don't use any queries apart from the occasional logged-in user based info and forms? If it were a trade off between inital first page loads and ease of templating and creation then I would gladly trade the inital page creation for the ease of use, but then I am slightly biased as I wrote the damn thing.

Also the cached pages are cached forever and only update when changes are made to either the comments or the articles/media uploaded. Even when the pages have user information the cached pages are optimised so they only load the information about the user and not the already cached info. It's quite sweet actually, but I'm still relativley new to this cms writing game.

[Dan Grossman]

That's nice and all, but doesn't address the fact that the non-cached page load time is high and your host isn't happy with it. Far more complex applications than a CMS can pull together far more information in less time. A second is an eternity -- there's definitely some non-optimal queries or logic in there.

[buggedcom]

I don't think that is the issue here. I pointed out that on several occasions that the site was producing blank pages where there was supposed to be content (and at this point there was no caching involved). I've asked them to find out where it's coming from and they said the memory useage and queries. But there are two reasons why the cms query count/memory usage are unrelated to the current performance. A) the site works fine on another server, B) no one is currently viewing the site so you can't blame the server load.

I will look into why the initial compile takes so long. For the 13 query page, it actually compiles in 0.21852993965149 and the queries excecuted in 0.028255939484 which is roughly 13% of the compile time. which would lead me to believe that the templating is the item bogging down the script

[Dan Grossman]

0.2 seconds is a lot less than 1.0; for something like a CMS, that's reasonable. If that's causing complaints from the host, I'd look at other options. More "developer friendly" hosting, or a VPS. No idea what the blank pages are about.

[buggedcom]

Yeah, I think the server is quite honestly crap as the initial generation times vary from 0.08 to 1.6 for the same page. I think the server techs are trying to pass the buck with this one. Sadly the host can't be changed as it's a company thing where by the client, a large company, so it's all prearranged and structured.