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
Comment #1
moonray CreditAttribution: moonray commentedThis is most likely due to #717644: Another system_theme_data() issue in v1.4 w/ PATCH.
Comment #2
moonray CreditAttribution: moonray commentedComment #4
lpalgarvio CreditAttribution: lpalgarvio commentedit'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:
frontpage with skinr:
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:
Comment #5
lpalgarvio CreditAttribution: lpalgarvio commentedthis is when logged in with the admin.
Comment #6
ChrisBryant CreditAttribution: ChrisBryant commentedLPCA, thanks for providing the extended details regarding performance here. Can you do the same test with the dev version of Skinr 2.x?
Comment #7
lpalgarvio CreditAttribution: lpalgarvio commentedposting results from first to last, in a series of tests
frontpage with skinr 2.x-dev (without UI):
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):
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.)
Comment #8
ChrisBryant CreditAttribution: ChrisBryant commentedComment #9
ChrisBryant CreditAttribution: ChrisBryant commentedComment #10
JacineAny updates?
Comment #11
lpalgarvio CreditAttribution: lpalgarvio commentedsuggesting 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)
Comment #12
JacineLPCA, wrong issue?
Comment #13
lpalgarvio CreditAttribution: lpalgarvio commentedoops, yes
Comment #14
JacineThis 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.
Comment #15
ChrisBryant CreditAttribution: ChrisBryant commentedI'm working on this today and will post back later with results.
Comment #16
ChrisBryant CreditAttribution: ChrisBryant commentedQuick 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.
Comment #17
Alan D. CreditAttribution: Alan D. commentedI just hit the limits on my local server, any progress on this?
Comment #18
ChrisBryant CreditAttribution: ChrisBryant commented@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!
Comment #19
Alan D. CreditAttribution: Alan D. commentedZero 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).
Comment #20
ChrisBryant CreditAttribution: ChrisBryant commentedHere 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.
Comment #21
lpalgarvio CreditAttribution: lpalgarvio commentedi 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)
Comment #22
ChrisBryant CreditAttribution: ChrisBryant commentedYes, 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!
Comment #23
ChrisBryant CreditAttribution: ChrisBryant commentedDowngrading to normal priority. We'll do more performance testing with D7 soon, now that it's mostly working.
Comment #24
sunSkinr 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.