CMS Made Simple Forums

Hi all
We are developing a newspaper site http://rs.7dias.com.do.
We have it running it on a cloud server with 4GB RAM and 160GB of HD and 1.8 dual core processors. This is a test server so it's not getting hit by any traffic.
We are using CGBlog extensively. We are calling the articles through User Defined Tags though because we managed to improved the load time that way.
The homepage has some 17 calls to a UDT to fetch the articles based on the different categories we have created within CGBlog. The homepage is also calling the CGBlog twice and we are loading some other modules like the gallery, banners and some other global content blocks.
I've run Google Pagespeed and the results are far from optimal https://developers.google.com/speed/pag ... sponseTime
Specially regarding Server Response Time which for this site is typically 2.5 seconds. I tested CMSMS own site and the Server Response Time is typically 0.2 seconds.
How can I improved on these results? I've searched a lot on the topic of Server Response Time for CMSMS and haven't found anything yet. Any help would be greatly appreciated.

----------------------------------------------

Cms Version: 1.11.6

Installed Modules:

CMSMailer: 5.2.1
CMSPrinting: 1.0.4
FileManager: 1.4.3
MenuManager: 1.8.5
MicroTiny: 1.2.5
ModuleManager: 1.5.5
Search: 1.7.8
ThemeManager: 1.1.8
CGExtensions: 1.32.6
CGSimpleSmarty: 1.6.1
CGBlog: 1.9.12
CGCalendar: 1.10.4
Banners: 2.6
Gallery: 1.6.1
ListIt2: 1.4-beta1
youtubeplayer: 1.3.1
AdvancedContent: 0.9.4
CGSmartImage: 1.10.8
CGFeedMaker: 1.0.17
Uploads: 1.14.4
CGFBApp: 1.0.7
ListIt2Autor: 1.4-beta1
FrontEndUsers: 1.21.11
CustomContent: 1.9

Config Information:

php_memory_limit:
process_whole_template:
output_compression: false
max_upload_size: 100000000
url_rewriting: internal
page_extension:
query_var: page
image_manipulation_prog: GD
auto_alias_content: true
locale:
default_encoding: utf-8
admin_encoding: utf-8
set_names: true

Php Information:

phpversion: 5.3.23
md5_function: On (True)
gd_version: 2
tempnam_function: On (True)
magic_quotes_runtime: Off (False)
E_STRICT: 0
E_DEPRECATED: 8192
memory_limit: 32M
max_execution_time: 30
output_buffering: 4096
safe_mode: Off (False)
file_uploads: On (True)
post_max_size: 100M
upload_max_filesize: 100M
session_save_path: /var/lib/php/session (0770)
session_use_cookies: On (True)
xml_function: On (True)
xmlreader_class: On (True)

Server Information:

Server Api: apache2handler
Server Db Type: MySQL (mysqli)
Server Db Version: 5.1.66
Server Db Grants: Found a "GRANT ALL" statement that appears to be suitable

----------------------------------------------

1. Reduce PHP Memory limit to a reasonable level
if you set it to 256mb when you don't need 256mb your page speed will suffer
2. Reduce queries (100+ queries is a bit much)
3. Optimize queries (query analysis and tuning, create indexes where necessary, revise the algorithm if possible). (If you can create UDT's to read the database then you should have the skills to do this).
4. Reduce requests
- Setup your .htaccess file to allow caching
- Use embedded images and/or a CDN.
5. Setup caching
- Browser caching
- Smarty Caching
6. Use an opcode cache like APC or eAccelerator)
7. Use a caching proxy

And more:
- analyze the mysql query cache, make sure it is tuned to your site.
- use a mysql tuner.
- put tmp files on a fast disk (maybe a RAM disk).

Thanks for the input Calguy. I'll look into these points and keep you posted on how they work for us.
We have already tuned .htaccess to allow caching and have set up browser and smarty caching as well.
Which mysql tuner you recommend?

We have already tuned .htaccess to allow caching and have set up browser and smarty caching as well.

I am sorry to say, but you have not... or have not done it correctly. I looked.

Hmmm... we have Site Admin > Global Settings > Smarty Settings
Enable Smarty Caching = Yes
Do a Compilation Check = Yes
Cache module calls = Always
Cache UDT calls= Always

And on Site Admin > Global Settings > Advanced Setup
Allow Browser to Cache Pages is checked

And the pages are marked as cachable.

We have also this directive on our .htaccess file

ExpiresActive On
ExpiresByType image/jpg "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/gif "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType text/css "access plus 1 month"
ExpiresByType application/pdf "access plus 1 month"
ExpiresByType text/x-javascript "access plus 1 month"
ExpiresByType application/x-shockwave-flash "access plus 1 month"
ExpiresByType image/x-icon "access plus 1 year"
ExpiresDefault "access plus 2 days"

What are doing wrong or what are we missing?

Any update on this?

I would like to start a discussion where maybe we'd make some kind of guide to tune your CMSMS site. One thing I found very helpfull is this article:

http://blog.arvixe.com/put-your-cms-mad ... -steroids/

There are no real news.

You can use

https://developers.google.com/speed/pagespeed/insights/

for more hints.

There's only one thing I don't find in this topic - the advice to transform all UDT to real (file based) Smarty plugins.

Before an UDT will running it must be loaded from database and this means an additional request (and time). Especially on high traffic websites it make sense to eliminate every performance brake.

Like Calguy said there are additional options like using APC. So it's possible to get Smarty APC powered. But it's similar like activation of mysql connection compression - it needs modification of core files. And this is not allowed to post it here in cause of the forum rules.

Thanks,

I know about the Google pagespeed measurement tool, and I have a site where sometimes on the mobile version the server response is a bit slow. Not all the time, but sometimes.

I use the {mobiledetect} plugin to adapt my HTML and CSS for mobile devices without using separate templates, and I was wondering why sometimes the mobile server response was slower than the desktop. I thought maybe I could find some hints here.

Don't know the details of Google mobile check but maybe it has something to do with a higher latency of mobile connections.