[Solved] Slow backend (admin)

[waltertakashi]

Hi, guys! We have CMSMS 2.1 installed here. Since when we had upgraded to the 2.0 version with OneEleven theme, the CMS seems to be slower than older versions. Even when we were using 1.x versions of CMSMS, when we switched to the OneEleven theme, it slowed down the admin page performance as well.

I uninstalled most of the modules and optimized tables, but performance is still bad. It takes about 15 to 20 seconds to load each page in the backend.

We have the Gallery module with thousands of images and hundreds of galleries and hundreds of news in News module as well.

We have another CMSMS 2.1 running in a sub-domain and the performance is great. But it just have a few content pages, few news and do not have Gallery module.

Here's our system information:

Code: Select all

----------------------------------------------
Cms Version: 2.1
Installed Modules:
CMSMailer: 5.2.4
ModuleManager: 2.0.1
News: 2.50.3
Search: 1.50.2
ThemeManager: 1.1.8
FormBuilder: 0.8.1.2
Gallery: 2.0.3
CGExtensions: 1.50
Captcha: 0.5.2
SiteMapMadeSimple: 1.2.8
FileManager: 1.5.1
CGSmartImage: 1.20.5
CGJobMgr: 1.3.4
AdminSearch: 1.0
MicroTiny: 2.0.2
CMSContentManager: 1.0.2
DesignManager: 1.1
Navigator: 1.0.1
TreeManager: 0.6.0
CGSimpleSmarty: 2.0.2

Config Information:
php_memory_limit:
max_upload_size: 100000000
url_rewriting: mod_rewrite
page_extension: /
query_var: page
auto_alias_content: true
locale:
set_names: true
timezone: America/Porto_Velho
permissive_smarty: false

Php Information:
phpversion: 5.5.14
md5_function: Ligado (Verdadeiro)
json_function: Ligado (Verdadeiro)
gd_version: 2
tempnam_function: Ligado (Verdadeiro)
magic_quotes_runtime: Desligado (Falso)
E_STRICT: 0
E_DEPRECATED: 0
test_file_timedifference: No time difference found
test_db_timedifference: No time difference found
create_dir_and_file: 1
memory_limit: 128M
max_execution_time: 240
register_globals: Desligado (Falso)
output_buffering: Ligado
disable_functions: passthru, show_source, shell_exec, system, pcntl_exec, popen, pclose, proc_open, proc_nice, proc_terminate, proc_get_status, proc_close, leak, apache_child_terminate, posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, myshellexec, c99_buff_prepare, c99_sess_put, fpassthru, exec
open_basedir: /home/faema/:/tmp:/usr/local/php/5.5/lib/php:./
test_remote_url: Sucesso
file_uploads: Ligado (Verdadeiro)
post_max_size: 64M
upload_max_filesize: 100M
session_save_path: No check because open basedir active
session_use_cookies: Ligado (Verdadeiro)
xml_function: Ligado (Verdadeiro)
xmlreader_class: Ligado (Verdadeiro)
check_ini_set: Ligado (Verdadeiro)
curl: Ligado

Performance Information:
allow_browser_cache: Ligado (Verdadeiro)
browser_cache_expiry: 60
php_opcache: Desligado (Falso)
smarty_cache: Ligado (Verdadeiro)
smarty_compilecheck: Desligado (Falso)
smarty_cache_udt: Ligado (Verdadeiro)
auto_clear_cache_age: Desligado (Falso)
Server Information:
Server Software: Apache
Server Api: fpm-fcgi
Server Os: Linux 3.12.42 Ligado x86_64
Server Db Type: MySQL (mysql)
Server Db Version: 5.5.43
Server Db Grants: Could not find a suitable "GRANT ALL" permission, this does not necessarily lead to problems... But if you have problems installing/removing modules or adding and deleting items/pages this could be the cause!

Permission Information:
tmp: /home/faema/www/tmp (0777)
tmp_cache: /home/faema/www/tmp/cache (0777)
templates_c: /home/faema/www/tmp/templates_c (0777)
modules: /home/faema/www/modules (0777)
uploads: /home/faema/www/uploads (0777)
Mascára de Criação de Arquivo (desmascarar): /home/faema/www/tmp/cache (0777)
config_file: 0444
----------------------------------------------

And here's my debug output (when loading Content Manager):

Code: Select all

Debug: (0.006689) - (usage: 892416) - (peak: 900672) loading page functions
Debug: (0.007834) - (usage: 979408) - (peak: 1022960) loading content functions
Debug: (0.008003) - (usage: 984520) - (peak: 1022960) loading translation functions
Debug: (0.0082) - (usage: 994808) - (peak: 1022960) loading php4 entity decode functions
Debug: (0.009357) - (usage: 1191352) - (peak: 1280864) done loading files
Debug: (0.00939) - (usage: 1191608) - (peak: 1280864) Initialize Database
Debug: (0.062146) - (usage: 1938536) - (peak: 1956416) (mysqli): SET NAMES 'utf8'
Debug: (0.062205) - (usage: 1937480) - (peak: 1956416) Done Initializing Database
Debug display of 'Loading Modules':(0.063819) - (usage: 2073832) - (peak: 2167864)
Debug: (0.066764) - (usage: 2306752) - (peak: 2317552) (mysqli): SELECT * FROM cms_modules ORDER BY module_name
Debug: (0.068164) - (usage: 2341184) - (peak: 2350816) (mysqli): SELECT parent_module,child_module,minimum_version FROM cms_module_deps ORDER BY parent_module
Debug: (0.089587) - (usage: 4575448) - (peak: 4592432) (mysqli): SELECT * FROM cms_userplugins ORDER BY userplugin_name
Debug: (0.095146) - (usage: 4982416) - (peak: 5002024) (mysqli): SET @CG_ZEROTIME = NOW() - INTERVAL 150 YEAR,@CG_FUTURETIME = NOW() + INTERVAL 5 YEAR
Debug: (0.108896) - (usage: 5557984) - (peak: 5582312) (mysqli): SELECT preference,value FROM cms_userprefs WHERE user_id = 5
Debug display of 'End of Loading Modules':(0.132685) - (usage: 7926848) - (peak: 8018576)
Debug: (0,132784) - (usage: 7927392) - (peak: 8018576) Initialize Smarty
Debug: (0,132818) - (usage: 7927736) - (peak: 8018576) Done Initialiing Smarty
Debug: (0,133258) - (usage: 7923624) - (peak: 8019128) original memory is 269000
Debug: (0,146447) - (usage: 8920584) - (peak: 8966552) (mysqli): SELECT group_id FROM cms_user_groups WHERE user_id = 5
Debug: (0,148261) - (usage: 9021080) - (peak: 9062040) (mysqli): SELECT * FROM cms_locks WHERE type = 'content'
Debug display of 'Fetch module_file_tpl:CMSContentManager;defaultadmin.tpl start':(0,148834) - (usage: 9055488) - (peak: 9098864)
Debug display of 'Fetch module_file_tpl:CMSContentManager;defaultadmin.tpl end':(0,482861) - (usage: 9262632) - (peak: 9363016)
Debug: (4,2E-5) - (usage: 9250448) - (peak: 9363016) before theme load
Debug: (0,000119) - (usage: 9252768) - (peak: 9363016) after theme load
Debug: (0,000189) - (usage: 9253512) - (peak: 9363016) before notifications
Debug: (0,009469) - (usage: 9562992) - (peak: 10031536) before populate admin navigation
Debug: (0,017234) - (usage: 9630120) - (peak: 10031536) before menu items
Debug: (0,01948) - (usage: 9674176) - (peak: 10031536) after menu items
Debug: (0,020048) - (usage: 9681168) - (peak: 10031536) before system modules
Debug: (0,020829) - (usage: 9700928) - (peak: 10031536) before non system module menu items
Debug: (0,021249) - (usage: 9709328) - (peak: 10031536) after non system module menu items
Debug: (0,024607) - (usage: 9789424) - (peak: 10031536) after populate admin navigation
 

Do you have any ideas?

Thank's!

[calguy1000]

Well... first, change the dbms in your config.php to 'mysqli'. as 'mysql' is deprecated and known to be slower.

Second. Have your server administrator enable the PHP 5.5 opcache. I get like a 50% performance improvement by enabling the opcache.

Third enable debug mode and find out where the bottlenecks are.

[waltertakashi]

Well... first, change the dbms in your config.php to 'mysqli'. as 'mysql' is deprecated and known to be slower.

Second. Have your server administrator enable the PHP 5.5 opcache. I get like a 50% performance improvement by enabling the opcache.

Third enable debug mode and find out where the bottlenecks are.

Hi calguy, thank you. I changed the dbms to 'mysqli'. Enabling the debug mode, I saw that the bottleneck seems to be when loading the page functions and the page theme:

Code: Select all

Debug: (2.3E-5) - (usage: 1050680) - (peak: 1057832) loading page functions
Debug: (5,7E-5) - (usage: 8533360) - (peak: 8962144) before theme load

I opened a support ticket and asked my server administrator to enable OPCache. Let's see if they'll do this.

[calguy1000]

Those last values are memory usages... it's only using ~3ms to load all of those files.

[waltertakashi]

Hi calguy,

I was seeing the debug mode of Chrome and I saw that the page elements are loaded quickly, but the request is being slow processed as you can see in the attached graph. Does it mean that the problem is on the server side?

[calguy1000]

well... it depends. if you actually hover over that bar graph it will show you 'waiting time' and 'download time'.

the waiting time is primarily server related. the download time would be the time sending from the server to your computer.

I just tested a remote CMSMS site that is located on a server on the east cost of the USA and I got a total time of 124ms.

Note: The performance on the server (list content) is directly related to the number of pages you are trying to display at one time. try changing your page limit to ~50 pages.

[waltertakashi]

well... it depends. if you actually hover over that bar graph it will show you 'waiting time' and 'download time'.

the waiting time is primarily server related. the download time would be the time sending from the server to your computer.

I just tested a remote CMSMS site that is located on a server on the east cost of the USA and I got a total time of 124ms.

Note: The performance on the server (list content) is directly related to the number of pages you are trying to display at one time. try changing your page limit to ~50 pages.

Hi calguy, this slowness happens on every page that I try to load on CMSMS backend, even when I'm loading a very simple page like the Group Permissions.

I checked the bar graph and it's almost 100% related to the waiting time as you can see on the picture below.

Can it be related to a corrupted instalation or something too?

[calguy1000]

If it's happening for a simple page like group permissions, or the backend user list then I would lean towards the server being overtaxed. like you said, those are very lightweight pages.

[waltertakashi]

If it's happening for a simple page like group permissions, or the backend user list then I would lean towards the server being overtaxed. like you said, those are very lightweight pages.

Got it, calguy! I'll be contacting the hosting provider to report this issue.

Thank you!

[scooper]

Sorry to dive in on a solved thread, but I think there's more to this.

We have a client with a reasonably large site who has been suffering from a slow admin area for a while now. Since waltertakashi mentioned the choice of theme making a difference I switched back from OneEleven to NClearGrey (the site is on 1.12.1) and there's a huge difference in speed.

The attached screenshot shows the requests for the admin home page from two instances of Firefox pointing at the same server at the same time (well as fast as I can click between them anyway).

On that example there's a 10 second difference in the time it takes for the page to render. The actual download times are similar but the initial wait for the page is consistently much longer. This is the case across all the admin pages including the simple ones.

Given that everything else is the same it looks to me that there's something in the theme that is making a big difference.

The code for NClearGrey is very different to OneEleven so it's not obvious what the difference is. I'll have a poke around to see what I can work out but any clues from someone more familiar with the way the themes work would be gratefully received.

[scooper]

Right... we're getting there....

After a bit of poking around I found that removing the call to the FileManager dropdown in pagetemplate.tpl brought the speed of the OneEleven theme up to reasonable levels.

In part this was because because in FileManager I had checked the
Enable advanced mode?: checkbox.

This meant my dropdown list of directories had 750 entries.

Just unchecking that option and just having access to the /uploads directory made a big difference (down to 240 lines). A further bit of tidying up meant that I was able to leave the dropzone area in the template and still have reasonable response times.

I'll repost this as a separate comment just so it doesn't get lost but let me know if it works for you.

s.

[calguy1000]

walking through 750 directories should not take ~10 seconds. that seems like poor performance.

[scooper]

Sure - 10 secs is me being over dramatic.

Just pulling out the directory walking routine from FileManger and sticking in some timings gives a normal response time of about 0.8 of a second, but every so often that'll be 3 or 4 seconds and occasionally as much as 10. (that link is a dedicated server as well - it's definitely slower on our shared cloud hosting).

Add in the extra page weight etc and it's not unreasonable to assume that it's adding a second to every page load in admin. That's something worth optimising and I don't think loading the file list in an ajax call instead would be difficult to implement.

[scooper]

And if the raw stats don't convince you, my client has just sent me an email after I'd removed the dropzone from their template:

Wow, so much faster! It does all seem to be working much faster which is a delight.

[calguy1000]

And if the raw stats don't convince you, my client has just sent me an email after I'd removed the dropzone from their template

:

And I'm sure you did it correctly by forking and renaming the admin theme. RIGHT!