CMS Made Simple Forums

Pierre M. wrote: Please notice : this march version is focused on browser side cache tuning (via mod_expires and mod_headers).

... and Proxies as well. Proxies are even more important since they serve the pages on first contact, before your browser had a chance to cache them.

Cheers,
Alex

To speed up my cmsms site, I use this:
Static stylesheet tag (based on this thread)

and this:
Modified index.php and editcontent.php, based on this thread

[edit]: Recently I found out there is a little problem having these two hacks together, follow the link above if you have problems with your stylesheet not being updated

... and of course, I try to follow Cyberman's guidelines (just the modules, stuff I use...)
Maybe it wasn't mentioned you can delete support for other databases except mysql(i/t) in lib/adodb_lite/adodbSQL_drivers
(or except the database(s) you're using, that is).

Don't use Global Content Blocks, if you are with a host who has a very slow database server or just really bad database performance.

First change hosts, it's just not worth being with a sub-par host when there are so many to choose from.  Then you can use Global Content Blocks and you won't take a performance hit and you can manage everything inside CMSms.

If you're not willing or have a desire to change hosts, then I would probably also take a look at not using Global Content Blocks and instead probably create a static php, or "include" file.

{include file='/path/to/your/include/files/footer.inc'}
{include file='/path/to/your/include/files/header.inc'}

This will reduce at least 1 database call for every Global Content Block you use.  But you can really only do this if you don't use complex Global Content Blocks that use other CMSms features.

Or better yet, if you're using the same content on every page, just put that content in your template and be done with it, then you can still use or call other CMSms features and you still remove a database call for every Global Content Block you remove.

These are real world examples:
Example of a sub-par host:
3.6 seconds to generate a page with 15 SQL queries.

Example of a host who cares about performance:
0.22 seconds to generate a page with 43 SQL queries.

Switch hosts, but if you can't this might help with a work around to eek out a little more performance and speed.  And for those looking to eek out even more speed even if you are with a good host, this can help.

In module.functions.php, function.content.php and sopa.php change the line

if (strtolower($modulename) == strtolower($key))

to

if (strcasecmp($modulename,$key)==0 )

that is faster because no need to make strtolower twice.


The same in module.functions.php with

  if (strtolower($mactmodulename) == strtolower($params['module']))

change it to

  if (strcasecmp($mactmodulename,$params['module'])==0 )

Change in ModuleManager.module.php the function  uasort_cmp_details to this:

Open content.functions.php and delete this part in function serach_plugins:

// This hides the dummy function.summarize.php
// (function.summarize.php was renamed to modifier.summarize.php in 1.0.3)
// This code can be deleted once the dummy is removed from the distribution
// TODO: DELETE
if (
$file == 'function.summarize.php' &&
substr(file_get_contents(cms_join_path($dir, $file)), 9, 9) == '__DUMMY__'
)
{
continue;
}
// END TODO: DELETE

you must delete in the folder plugins function.summarize.php  - it is a dummy and distributed with cmsms 1.3 (but should not).

From class.contentoperations.inc.php you can delete the function

function SetDefaultContent

complete

NEVER IN USE  spare memory because a member of a class.

Hello "pb",

I can't tell about your code ; but please submit your diffs to the forge, not in the forum. Because the Devs say it is easier for them to track issues and patches in the forge while they can miss them in the boards.
Thx.

Pierre M.

The code is for the users and not a special for the devs.

But if this is too complicated for the users i stop these postings now and stop it complete (that is what i do now).

I have this all made for myself to speeding up cmsms .

My speed with v 1.3 is now 40% better as the original ( there are some changes open i have not posted here) and all has 100% compatibility with CMSMS.

I am wondering that the dev has this work not done, because that must be easy for the dev.

Ok folks, sorry but you must work with a slow cmsms.

if you're not willing to share your code in a proper way that people can find it, research it, and implement in the core, then you're just not 'playing well with others'.

As Pierre illustrated, these posts will be lost in about a week or less, and we won't be able to find them. 

You're willing to go through the code line by line, and post a thousand posts here, and be ignorant to the people that are trying hard to improve the product. but you're not willing to read for a few minutes and learn how to generate a 'diff'?  or to post some things in the forge so that you can help everybody out, and improve the product permanently?

If this is the case, we probably don't need your kind of help.

these posts will be lost in about a week or less, and we won't be able to find them

I can find here very old postings and so this is no argument (this starting at 26 Jul 2007).

If this is the case, we probably don't need your kind of help.

I see that only help is wanted in a way that you like, but that is too much work for me.

You are not able to take the code and check it from here ??  

I cannot believe it, because users can do it.

Because 1.3 seems to be the  last 1.x version it is worthless to post it in the forge.

Speeding up cmsms is a big wish of many users but nothing has happen in the last time and so i think  that was right to show the users some ways to do it.

I learned that there is no interest by the dev to do it.

And so help yourself.  That is the best way because you are knowing the source better.

I had an idea last night about speeding up stylesheets.

The problem exists that stylesheets were not getting cached in the browser... and this was due to a lack of understanding of how the cache stuff worked wrt http headers.

So I did some research and think I finally understand it, and I began working on a solution.

a) I modified the {stylesheet} tag to output seperate links to each stylesheet by cssid and to do database lookups
    to convert stylesheet name to id where necessary.
b) I modified the stylesheet.php to tread a cache file (tmp/cache/csshash.dat) which contains an md5sum of the
    css in the stylesheet and a stylesheet id as a key.
    - if the key does not exist for a particular stylesheet id, then the stylesheet is read, output, and the
      md5sum cache updated.  I then output the new md5sum and a last-modified date.
    - if the key does exist, and the hash matches that supplied by the browser, then an "HTTP/1.1 304 Not Modified"
      result is returned.

Preliminary results indicate a dramatic performance improvement because stylesheets can now be cached on the browser.

Next, all I need to do is to modify this cache whenever a stylesheet is added/edited/deleted so that even less database
loads are required.... but it's a purely optional step.

Just thought I'd let you know.

I am needing people with IE who can test for me to make sure that things are being cached properly in all browsers.
so let me know.
   
   

Thaks pb,
I hope that you know what you do and your code will let to speed up CMSMS.
Vilkis

P.S. I think that it is not comfortable but it is not very complex to take the code from forum for devs. And if the proposed code is useful one has to take it if there is no chance that it will be done by pb.

calguy1000 wrote: a) I modified the {stylesheet} tag to output seperate links to each stylesheet by cssid and to do database lookups
    to convert stylesheet name to id where necessary.   

Hi Robert!
Is http://dev.cmsmadesimple.org/projects/static-css/ not doing something similar? The difference is just that this tag outputs different and lets the browser cache the css files.

well, this plugin is a little better, but isn't as efficient as it could be either.

this plugin relies on the server cache to output static css filenames.  However it does regenerate the css files whenever the server cache is invalidated.

my update is a little better in that it:
  a) updates the hash-cache each time a template is changed (gotta finish the add/delete stylesheet stuff yet)
      so that file read/file-write is taken care of on the admin side a great deal more
  b) won't even try to request the stylesheet from the db if the last-modified date is okay
      or the Etag sent from the browser is okay
  c) if it does need to requesta particular stylesheet the md5sum (ETag) is cached on a per-stylesheet
      basis.

but, it's mostly just semantics as you've said... I prefer not to cache the static text.