Hi I don't know where the problem is in Skinr, but my local dev site got very slow. So i created a new empty site. Copied over all the modules that were installed on the dev site and enabled the one by one and ran apache benchmark against the site. I went from about 200-300ms to 6000ms after enabling skinr. (I'm testing on windows so PHP is already slow on it's own)
I downloaded the 6.x-1.x-dev and the problem was gone.
So I think whatever problem exists in 1.4 has already been fixed, but I wanted to report this anyway. I didn't start debugging 1.4 any further because it looks like the problem was fixed in dev.

Comments

moonray’s picture

moonray’s picture

Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

lpalgarvio’s picture

Version: 6.x-1.4 » 6.x-1.5
Priority: Normal » Major
Status: Closed (fixed) » Active

it's still rather slow on my site, with garland theme (actually i tested on 3 different sites with different themes).
i'm using InnoDB engine and Transaction and DBTNG modules.
i don't have any styles configured, this is after installing skinr (cleared caches, ran cron, refreshed pages, etc)

is skinr that complex...
to bring up a typical page loading time, from the normal 400-600ms, to 700-3000ms (avg 1500)?
and add a lot of new queries?
most modules i've installed only add up a few ms.

frontpage without skinr:

Page execution time was 540.23 ms. Executed 90 queries in 80.03 milliseconds.
Memory usage:
Memory used at: devel_init()=1.13 MB, devel_shutdown()=19.05 MB.

frontpage with skinr:

Page execution time was 1320.25 ms. Executed 142 queries in 183.94 milliseconds.
Memory usage:
Memory used at: devel_init()=1.13 MB, devel_shutdown()=19.65 MB.

seems fishy for a module that only has 21KB gzipped in v1.5.
makes me think that if i don't use a file cache module (shared hosting), then skinr isn't meant for me.

Drupal 6.19
Skinr 1.5
currently i have 57 modules (58 with skinr) installed, plus core optional modules:

Enabled Modules

This page shows the Drupal modules that have been used to build this site.

Click on the project name to visit the project page on Drupal.org.
Project: administerusersbyrole
Administer Users by Role (administerusersbyrole)
Version: 6.x-1.4
			
Project: adminrole
Admin Role (adminrole)
Version: 6.x-1.3
			
Project: admin_menu
Administration menu (admin_menu)
Version: 6.x-1.6
			
Project: admin_theme
Administration theme (admin_theme)
Version: 6.x-1.3
			
Project: advanced_help
Advanced help (advanced_help)
Version: 6.x-1.2
			
Project: already_in
Already in (already_in)
Version: 6.x-1.0
			
Project: autoload
Autoload (autoload)
Version: 6.x-1.4
			
Project: better_formats
Better Formats (better_formats)
Version: 6.x-1.2
			
Project: block_edit
Block edit links (block_edit)
Version: 6.x-1.10
			
Project: cck
Content (content)
Version: 6.x-2.8
	
Number (number)
Version: 6.x-2.8
	
Option Widgets (optionwidgets)
Version: 6.x-2.8
	
Text (text)
Version: 6.x-2.8
Project: config_perms
Site Configuration Permissions (config_perms)
Version: 6.x-2.0-beta2
			
Project: date
Date API (date_api)
Version: 6.x-2.6
	
Date Locale (date_locale)
Version: 6.x-2.6
	
Date Timezone (date_timezone)
Version: 6.x-2.6
	
Project: dbtng
DBTNG (dbtng)
Version: 6.x-1.0-alpha6
			
Project: devel
Devel (devel)
Version: 6.x-1.22
	
Performance Logging (performance)
Version: 6.x-1.22
		
Project: drupal
Aggregator (aggregator)
Version: 6.19
	
Blog (blog)
Version: 6.19
	
Book (book)
Version: 6.19
	
Color (color)
Version: 6.19
Comment (comment)
Version: 6.19
	
Contact (contact)
Version: 6.19
	
Content translation (translation)
Version: 6.19
	
Database logging (dblog)
Version: 6.19
Forum (forum)
Version: 6.19
	
Help (help)
Version: 6.19
	
Locale (locale)
Version: 6.19
	
Menu (menu)
Version: 6.19
OpenID (openid)
Version: 6.19
	
Path (path)
Version: 6.19
	
PHP filter (php)
Version: 6.19
	
Poll (poll)
Version: 6.19
Profile (profile)
Version: 6.19
	
Search (search)
Version: 6.19
	
Statistics (statistics)
Version: 6.19
	
Taxonomy (taxonomy)
Version: 6.19
Tracker (tracker)
Version: 6.19
	
Trigger (trigger)
Version: 6.19
	
Update status (update)
Version: 6.19
	
Project: drupal_queue
Drupal Queue API (drupal_queue)
Version: 6.x-1.1
			
Project: enabled_modules
Enabled modules (enabled_modules)
Version: 6.x-1.0-beta1
			
Project: fieldset_helper
Fieldset helper (fieldset_helper)
Version: 6.x-1.0
			
Project: filefield
FileField (filefield)
Version: 6.x-3.7
			
Project: filefield_paths
FileField Paths (filefield_paths)
Version: 6.x-1.4
			
Project: filefield_sources
FileField Sources (filefield_sources)
Version: 6.x-1.2
			
Project: filefield_uiextras
FileField UI Extras (filefield_uiextras)
Version: 6.x-1.0-rc2
			
Project: file_aliases
File Aliases (file_aliases)
Version: 6.x-1.1
			
Project: imageapi
ImageAPI (imageapi)
Version: 6.x-1.8
	
ImageAPI GD2 (imageapi_gd)
Version: 6.x-1.8
	
ImageAPI ImageMagick (imageapi_imagemagick)
Version: 6.x-1.8
	
Project: imagecache
ImageCache (imagecache)
Version: 6.x-2.0-beta10
	
ImageCache UI (imagecache_ui)
Version: 6.x-2.0-beta10
		
Project: imagecache_profiles
Imagecache Profile Pictures (imagecache_profiles)
Version: 6.x-1.3
			
Project: imagefield
ImageField (imagefield)
Version: 6.x-3.7
			
Project: image_resize_filter
Image resize filter (image_resize_filter)
Version: 6.x-1.9
			
Project: input_format_permissions
Input Format Permissions (input_format_permissions)
Version: 6.x-1.1-beta1
			
Project: insert
Insert (insert)
Version: 6.x-1.0-beta6
			
Project: login_security
Login Security (login_security)
Version: 6.x-1.0
			
Project: password_change
Password change confirm (password_change)
Version: 6.x-1.0
			
Project: pathauto
Pathauto (pathauto)
Version: 6.x-2.0-alpha2
			
Project: permissions_api
Permissions API (permissions_api)
Version: 6.x-2.11
			
Project: poormanscron
Poormanscron (poormanscron)
Version: 6.x-2.2
			
Project: role_delegation
Role Delegation (role_delegation)
Version: 6.x-1.3
			
Project: skinr
Skinr (skinr)
Version: 6.x-1.5
			
Project: system_table_cleaner
System Table Cleaner (system_table_cleaner)
Version: 6.x-1.x-dev
			
Project: taxidermy
Taxidermy (taxidermy)
Version: 6.x-1.x-dev
			
Project: token
Token (token)
Version: 6.x-1.14
			
Project: transaction
Transaction (transaction)
Version: 6.x-0.1
			
Project: transliteration
Transliteration (transliteration)
Version: 6.x-3.0
			
Project: update_form_enhancement
Update form enhancement (update_form_enhancement)
Version: 6.x-1.5
			
Project: url_alter
Url alter (url_alter)
Version: 6.x-1.2
			
Project: userprotect
User Protect (userprotect)
Version: 6.x-1.4
			
Project: user_delete
User Delete (user_delete)
Version: 6.x-1.3
			
Project: vertical_tabs
Vertical Tabs (vertical_tabs)
Version: 6.x-1.0-rc1
			
Project: views
Views (views)
Version: 6.x-2.11
	
Views exporter (views_export)
Version: 6.x-2.11
	
Views UI (views_ui)
Version: 6.x-2.11
	
Project: wysiwyg
Wysiwyg (wysiwyg)
Version: 6.x-2.1
lpalgarvio’s picture

this is when logged in with the admin.

ChrisBryant’s picture

LPCA, thanks for providing the extended details regarding performance here. Can you do the same test with the dev version of Skinr 2.x?

lpalgarvio’s picture

posting results from first to last, in a series of tests

frontpage with skinr 2.x-dev (without UI):

Page execution time was 743.8 ms. Executed 167 queries in 89.84 milliseconds.
Memory usage:
Memory used at: devel_init()=2.14 MB, devel_shutdown()=24.02 MB.

Page execution time was 1052.35 ms. Executed 167 queries in 112.91 milliseconds.
Memory usage:
Memory used at: devel_init()=2.14 MB, devel_shutdown()=24.02 MB.

Page execution time was 1800.19 ms. Executed 167 queries in 900.44 milliseconds.
Memory usage:
Memory used at: devel_init()=2.14 MB, devel_shutdown()=24.02 MB.

Page execution time was 1754.15 ms. Executed 167 queries in 82.45 milliseconds.
Memory usage:
Memory used at: devel_init()=2.14 MB, devel_shutdown()=24.02 MB.

more queries now (167), but most of the time, it queries the db in less time and executes averagely in less time.
sometimes however it lags though, both in DB and PHP.

frontpage with skinr 2.x-dev (with UI):

Page execution time was 1289.64 ms. Executed 233 queries in 294.86 milliseconds.
Memory usage:
Memory used at: devel_init()=2.14 MB, devel_shutdown()=25.55 MB.

Page execution time was 1522.53 ms. Executed 198 queries in 164.24 milliseconds.
Memory usage:
Memory used at: devel_init()=2.14 MB, devel_shutdown()=24.62 MB.

Page execution time was 1077.69 ms. Executed 197 queries in 172.54 milliseconds.
Memory usage:
Memory used at: devel_init()=2.14 MB, devel_shutdown()=24.62 MB.

Page execution time was 1633 ms. Executed 197 queries in 184.9 milliseconds.
Memory usage:
Memory used at: devel_init()=2.14 MB, devel_shutdown()=24.62 MB.

Page execution time was 1087.5 ms. Executed 197 queries in 137.61 milliseconds.
Memory usage:
Memory used at: devel_init()=2.14 MB, devel_shutdown()=24.62 MB.

Page execution time was 922.17 ms. Executed 197 queries in 116.33 milliseconds.
Memory usage:
Memory used at: devel_init()=2.14 MB, devel_shutdown()=24.62 MB.

while one would think it's slower because of the addition of Dialog API, Chaos Tools, jQuery Update and jQuery UI, it's actually faster (overall) with those enabled when considering DB speed results. on a PHP to PHP speed comparison, without UI gets better results (spike and average).
the db queries are heavier and takes them longer in average, but it doesn't gets spikes of 900ms.

note: i think there's room to improve as DB results are inconclusive and weird.
note: the browser progress bar consistently takes a while to finish. most likely might be due to some bug in Dialog API (dev version), but could also be a bug in the other libraries or in Skinr UI.

conclusion: overall it's better than Skinr 1.x version, because it's average speed when loading pages is faster. nice improvement ;)
(take into account that these tests are being performed on a live shared hosting account and not on a dedicated idle server.)

frontpage without skinr:

Page execution time was 540.23 ms. Executed 90 queries in 80.03 milliseconds.
Memory usage:
Memory used at: devel_init()=1.13 MB, devel_shutdown()=19.05 MB.

frontpage with skinr:

Page execution time was 1320.25 ms. Executed 142 queries in 183.94 milliseconds.
Memory usage:
Memory used at: devel_init()=1.13 MB, devel_shutdown()=19.65 MB.

ChrisBryant’s picture

Title: Performace problem in 6.x-1.4 » Performace questions in 6.x
Version: 6.x-1.5 » 6.x-2.x-dev
Assigned: Unassigned » ChrisBryant
ChrisBryant’s picture

Title: Performace questions in 6.x » Performance questions in 6.x
Jacine’s picture

Any updates?

lpalgarvio’s picture

suggesting complete replacement of Dialog API with Chaos Tools modal dialog, for both 6.x-2.x-dev (ctools) & 7.x-2.x-dev (in core)

Jacine’s picture

LPCA, wrong issue?

lpalgarvio’s picture

oops, yes

Jacine’s picture

Version: 6.x-2.x-dev » 7.x-2.x-dev
Priority: Major » Critical

This really needs to be assessed.

@ChrisBryant, if you can't get to it, please unassign yourself.

Moving this to 7.x because that is where all the changes will go down.

ChrisBryant’s picture

I'm working on this today and will post back later with results.

ChrisBryant’s picture

Quick update on this, I didn't finish my work on Friday (BADcamp duties called) so I'll be working to finish up testing later today.

Alan D.’s picture

I just hit the limits on my local server, any progress on this?

ChrisBryant’s picture

@alan, I haven't been able to finish this, but plan to work more on it on Friday.

Can you provide some more details about your setup, environment, etc., as well as the amount of traffic and the problems you are seeing? What limits are you hitting? CPU, database, memory, etc.?

Thanks!

Alan D.’s picture

Zero traffic, I'm working locally on a 6.x production site. There is a massive MySQL hit happening, and this was one of the modules that I had to disable to reduce the server load. This module is not the primary cause, we have 50 content types, 100+ modules, multiple domains in DA, etc, but disabling did significantly reduce load, and stopped the "MySQL server has gone away" error (for a few hours until the next 20 types were added).

ChrisBryant’s picture

Here are my findings from a setup of basic skinr 6.x site. I wanted to use the 6.x version since that is what @LPCA tested and pretty much everyone is using this version in production. I'll do further testing on 7.x as well. These results are similar to what's posted, though with a much smaller margin of error on each run. These were run on a dedicated server with no other activity on the server:

Normal (without skinr & skinr_ui, caches cleared each time)
Executed 1862 queries in 476.57 milliseconds.
Executed 1872 queries in 481.49 milliseconds.
Executed 1872 queries in 480.72 milliseconds.
Executed 1872 queries in 480.89 milliseconds.
Executed 1872 queries in 481.49 milliseconds.

Skinr (without skinr_ui, caches cleared each time)
Executed 1891 queries in 486.64 milliseconds.
Executed 1901 queries in 495.8 milliseconds.
Executed 1900 queries in 492.72 milliseconds.
Executed 1900 queries in 490.39 milliseconds.
Executed 1900 queries in 489.28 milliseconds.

Skinr (with skinr_ui, caches cleared each time)
Executed 1966 queries in 509.02 milliseconds.
Executed 1981 queries in 528.8 milliseconds.
Executed 1966 queries in 508.49 milliseconds.
Executed 1966 queries in 506.85 milliseconds.
Executed 1966 queries in 506.72 milliseconds.

No Skinr (cached)
Executed 31 queries in 6.91 milliseconds.
Executed 31 queries in 6.86 milliseconds.
Executed 31 queries in 5.66 milliseconds.
Executed 31 queries in 4.95 milliseconds.
Executed 31 queries in 4.96 milliseconds

Skinr (with skinr_ui, cached)
Executed 51 queries in 8.8 milliseconds.
Executed 52 queries in 7.16 milliseconds.
Executed 51 queries in 7.12 milliseconds.
Executed 51 queries in 6.89 milliseconds.
Executed 51 queries in 7.07 milliseconds.

Based on the above, you can see there is very little impact from enabling skinr and skinr_ui. The number of queries goes up approx 23 or 1.5% and the time increases by approx 16 ms or 3.3% by enabling the skinr module. Enabling skinr and skinr_ui the number of queries increases by approx 94 or 5% and the time increases by approx 27 ms or 5.6%. Please note these are rough calculations, but you get the idea.

When the page is loaded from the cache, the number and time of queries drastically reduces as expected. Skinr is loading approx 2ms or 29% slower. If 29% is accurate, then it is slightly alarming. Also (and @Jacine pointed this out recently,) the fact that there are still approx 20 more queries over baseline when cached indicates that there may be an issue with skinr's database queries not being cached when they should be.

I have more testing in the works (ab, profiling, etc.) and will report back on further findings and recommendations.

lpalgarvio’s picture

Title: Performance questions in 6.x » Performance: How does skinr perform?

i would say the performance hit is not just in the DB, but also in PHP.

specially in the case of shared hosting, with no opcode caching (ex, apc) or dedicated memory caching (ex, memcached).

i would advise stating in the project page, that atm, in servers with low resources and/or with absence of opcode caching / memory caching, skinr is not recommended

(even more in the case of 6.x-1.x, as it's terribly slow and 6.x-2.x, as it requires Dialog API... 7.x-2.x is much faster)

ChrisBryant’s picture

Yes, there is definitely an impact, though relatively small percentage wise, at the PHP level as well. I plan to report back with profiling results as well so we can see what parts of the code are expensive.

Thanks for replying back!

ChrisBryant’s picture

Priority: Critical » Normal

Downgrading to normal priority. We'll do more performance testing with D7 soon, now that it's mostly working.

sun’s picture

Category: bug » support
Status: Active » Closed (duplicate)

Skinr 7.x-2.x still is a performance killer. However, this is a known problem and will be fixed, but requires major architectural changes to the module's design, which will happen via #1029058: [META ISSUE] Change skin configuration and/or related issues. Therefore, I'm going to mark this issue as duplicate, since we need a clean and actionable 7.x queue.