Category: Performance / Speed / Load / Compression / Cache

I saw this error when visiting this url: http://doc.tiki.org/preview564

{CODE()}
( ! ) Notice: MemcachePool::set() [<a href='memcachepool.set'>memcachepool.set</a>]: Server 127.0.0.1 (tcp 11211, udp 0) failed with: SERVER_ERROR object too large for cache (3) in /path/lib/cache/memcachelib.php on line 169
Call Stack
# Time Memory Function Location
1 0.0004 797536 {main}( ) ../route.php:0
2 0.0016 1069608 include( '/path/tiki-download_file.php' ) ../route.php:245
3 3.6856 80335592 Cachelib->cacheItem( ) ../tiki-download_file.php:369
4 3.6856 80335592 CacheLibMemcache->cacheItem( ) ../cachelib.php:44
5 3.6856 80335768 Memcachelib->set( ) ../cachelib.php:387
6 3.6856 80336192 set ( ) ../memcachelib.php:169
{CODE}

{img fileId="720" thumb="y" rel="box[g]"}

After applying a profile in 20.x, plenty of ugly error message notices are shown, regarding inability to create plenty of cache files:

Things like:
{QUOTE()} Error
Cache file temp/cache/module8756ab3c25fd45a0a55957e6d7bb1f16 is not writable
{QUOTE}

Very bad image for any one testing a brand new tiki site, and clicking for instance at any of the featured profiles.

Hello,

we have noticed a problem within some HTTP response headers where the value the Expires-key is hard set to "Expires: Thu, 19 Nov 1981 08:52:00 GMT". This causes some browsers to not be able to cache the page and cause performance issues.

We first experienced this with requests to article_image.php?image_type=topic&id=<someid>

Then we noticed, that the index.php has this Expires header value set, too. And unfortunately it's the same on dev.tiki.org, too.

Could you please have a look?

Thanks in advance!

Lars

If you inspect the HTTP headers of a page generated by Tiki, it has an Expires header in the past:
-+Expires: Thu, 19 Nov 1981 08:52:00 GMT+-

Beside that, I also suggest to enable caching, at least in the Raw page display (tiki-index_raw.php?page=), it enables the browser to cache frequently used information by something like the AJAXLoad plugin and improves performance.
Now the Pragma header has:
-+Pragma: no-cache+-
And the cache-control header:
-+Cache-Control: no-store, no-cache, must-revalidate+-

{img fileId="864"}

Amette contributed a way for Tiki to report its health:
http://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/tiki-monitor.php
http://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/doc/devtools/check_tiki.php
http://sourceforge.net/p/tikiwiki/code/HEAD/tree/trunk/doc/devtools/check_tiki-new.php

This could help
1- Alert quickly the right people to get the site back up
2- Provide data to understand what went wrong

Related:
* {wish id=4836}
* {wish id=4678}

More info from bootstrap:
!# Unused CSS
...
While we don’t have a prebuilt example for using PurgeCSS with Bootstrap, there are some helpful articles and walkthroughs that the community has written. Here are some options:

https://medium.com/dwarves-foundation/remove-unused-css-styles-from-bootstrap-using-purgecss-88395a2c5772
https://lukelowrey.com/automatically-removeunused-css-from-bootstrap-or-other-frameworks/

Lastly, this CSS Tricks article on unused CSS shows how to use PurgeCSS and other similar tools.
...
!# Non-blocking files

While minifying and using compression might seem like enough, making your files non-blocking ones is also a big step in making your site well-optimized and fast enough.

If you are using a Lighthouse plugin in Google Chrome, you may have stumbled over FCP. The First Contentful Paint metric measures the time from when the page starts loading to when any part of the page’s content is rendered on the screen.

You can improve FCP by deferring non-critical JavaScript or CSS. What does that mean? Simply, JavaScript or stylesheets that don’t need to be present on the first paint of your page should be marked with ''__async or defer__'' attributes.

This ensures that the less important resources are loaded later and not blocking the first paint. On the other hand, critical resources can be included as inline scripts or styles.

If you want to learn more about this, there are already a lot of great articles about it:

https://web.dev/render-blocking-resources/
https://web.dev/defer-non-critical-css/

Please see: ((YSlow))

Increase ySlow score for all SUMO pages to A
https://bugzilla.mozilla.org/show_bug.cgi?id=444274

_htaccess contains the following but has no effect in ClearOS (which is like CentOS)

{CODE()}
<IfModule deflate_module>
AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css application/x-javascript application/javascript
</IfModule>
{CODE}

But the following works:
{CODE()}
<IfModule mod_deflate.c>
<filesMatch "\.(js|css|html)$">
SetOutputFilter DEFLATE
</filesMatch>
</IfModule>
{CODE}

http://gtmetrix.com/ reports a difference for PageSpeed Enable gzip compression and YSlow Compress components with gzip


I am wondering if I should add or replace.

Hi all, I have been using tikiwiki since it was about v14 and have seen it use more and more compute resource. I recently pulled a production site from AWS as the compute bills where starting to get out of hand. I think I would have a hard time convincing small sme's to fork out hundreds of euro each month for in-house tikiwiki hosting. Any thoughts are welcome. I have tried disabling various features but it still takes up cpu time. This isn't a complaint, I love tikiwiki , but if tikiwiki increase in size it will become a software suite for large corporations ONLY. Cheers, Kevin.

We have a site_closed preference which is very useful.

However, this permits only the admins to access the site.


What if we want a read-only mirror?

It would be nice to a have a preference for this, along with a message to users: "This site is in read-only" and admins could change this message to indicate where the live site is.

Perhaps it could be interesting to check if the mysql user is "read only" as well...

This could also be interesting if a project is completed and we want to keep a site an an archive but no longer have any changes.

Things like tiki-logs, date of last login, etc. will need to considered.

Perhaps there could be a check: If current users has an edit/add permission (we'd have to make a list), then, he gets a warning that site is read-only (a message that the admin could change) and that any changes will be lost.

I use Tiki Wiki for many of my sites and some of them have multiple domains associated with them. So domain.ca, domain.com and domain.co.uk all point to the same folder on the same server using domain redirection.

The main domain works and looks fine but if I go to any of the other domains everything is there but it is out of place. The modules were in the wrong place on the screen and it looked like the theme CSS was messed up. I tried playing with perspectives, multi-domain, areas, domain redirects (within Tiki), category, themes, and anything else that looked promising.

{syntax type="tiki" editor="plain"}
Themes.tiki.org is OK:
Indexation
wiki page: 214
forum post: 178
blog post: 59
article: 18
file: 80
trackeritem: 28
comment: 35

But the other sites are unable to complete the indexation.

---
Custom module "Search_tracker_summary" is generating: "Required features: feature_search. If you do not have the privileges to activate these features, ask the site administrator."

blank page here as well:
https://nextdev.tiki.org/tiki-admin.php?page=search&rebuild=now

TikiWiki 6.6

When using banners, and you update the banner table manually, the changes are not visible because the banners are cached. (so far so good).

However when clicking 'Clear all tiki caches' the banner cache (which resides in the /temp dir) is not cleared.

{syntax type="tiki" editor="plain"}
When Gzip output is enabled under Admin | Spped & Performance, it is not possible to send out newsletters greater than 100 in number, if at all. When attempting to send newsletters, it shows a 'Cannot load page' message in the frame where the log of email addresses normally appears.

{syntax type="tiki" editor="plain"}
I looked if something like this has been reported previously, but didn't find something that completely fits, so I post this and apologize if I missed something.

Since I have already put some detail into a [http://tiki.org/tiki-view_forum_thread.php?forumId=6&comments_parentId=44097#threadId44102|support request] and at the moment I believe it only concerns two Wikis belonging to the same admin, here is a description:

Steps to reproduce:
1) Take any Tiki installation and move a new directory
2) Create a new DB with a copy of the original DB
3) Upgrade and start it up
4) Log into the old installation as admin
5) Find out you're admin on the new one, too.

It may well be that for some admins this is a wanted behaviour like as a single-sign-on (SSO).

But it is my firm belief that any such behaviour is to be considerd a breach of security unless both admins have expressley activated this as a wanted behaviour. Possibly the problem also exists if two different admins operate two different Tikis on the same hosted volume, that somehow were created from one single predecessor, so maybe this is not as harmless as it might seem to be.

I do not know, but suspect, this could be a cookie issue.

Resolution could be that tiki-installer regenerates all security structures upon installation and/or upgrades, or at least asks the admin whether such should be reset. Also, there should be a button in the administration panel to reset this at any later time. In my opinion TikiWiki should at all times, if not told to behave otherwise, protect its instance against all other possible instances of itself...

At some point confusion may get so high to a user's browser that logging into Wiki B alone will not function, and you have to log into Wiki A to be able to access Wiki B. At the moment I experience this with my new 6.7 LTS and my old 1.9.8.3. sitting in different directories on the same volume, accessing to different MySQL DBs with differing user names and passwords...

Using wiki page cache, it happens that page cache is generated by a user who set his language to Italian. And then, the page is visited by someone who has language to something else, but sees Italian.


Workaround: turn off wiki page cache if you have a multilingual site

On doc.tiki.org/Installation, there is a link to doc.tiki.org/tiki-index.php/page=Installation

{img fileId=54}

And then, this page is broken, and it has many new links to index, most of which are invalid.

{img fileId=55}


Another example:
{img fileId=63}

http://www.iis.net/downloads/microsoft/wincache-extension

https://www.microsoft.com/web/post/performance-tuning-php-apps-on-windows-with-wincache

http://php.net/manual/en/wincache.configuration.php

This tracker is made to help filtering and sorting the features vs categories vs options we need to tag a bug/regression/wish with.

r45953

SVN (11.0svn): May 15 2013 - REV 45953

In a multitiki install of mine, I tested an upgrade from tiki9 to tiki11, and then, switching tabs in admin panels, stopped working.

Once I disabled the js minification setting, tabs worked again.

Tried in demo.t.o/Tiki11, and it works well with or without js minification. So I was that's where the issue must come from.
---

the issue is still present in : Monday 10 June, 2013 23:33:08 CEST- REV 46275, and seems related to the Catalan interface.
Once the interface is set to Catalan, and page reloaded twice, js features stop working.

Reproduced also here in dev.t.o

http://dev.tiki.org/Development

Full message is:

GET http://dev.tiki.org/vendor/jquery/plugins/migrate-min/dist/jquery-migrate.min.map 404 (Not Found) Development:1152
GET http://dev.tiki.org/vendor/jquery/jquery-min/jquery.min.map 404 (Not Found) Development:1152

See {CODE()}<script type="text/javascript" src="lib/jquery_tiki/tiki-maps.js"></script>{CODE} in the source.

We have a long table that presents fine on initial display, but when presented as (cached) the data is truncated. The footer appears mostly as normal except that it's evident that the table elements are arbitrarily cut off thereby affecting the subsequent footer.

Our table where the error is occurring is 680 lines long. The table will be truncated somewhere around line 390 or 540 but for a given edit instance it will always truncate at the same place.

We are seeing this behavior in 1.9.1 and 1.9.5. I don't believe this is a browser-related issue because we are seeing virtually the same results in IE and Firefox.

The menu cache can't create the directory at /templates_c, when the user loged has a lot of assigned groups. The name of the directory are the concatenation of the groups names.

Productization: Create admin preference to enable/disable minify
https://bugzilla.mozilla.org/show_bug.cgi?id=502092

Implement Admin panel/setting to flush/rebuild Minify cache
https://bugzilla.mozilla.org/show_bug.cgi?id=497703

[https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=minify&product=support.mozilla.com&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=|All "minify" related]

This cache should also be deletable


http://code.google.com/p/minify/