tru_tags: A tagging plugin for textpattern

merz1 · 2010-01-21 18:32:31

What happens when you delete the zem_cache wrapping everywhere?
In the 2nd code example I would delete minpercent="90" maxpercent="200" and stay with the default. I once had reproducable performance issues when using those min&max sizes (with > 1.000 keywords in the cloud / depending on the machine).
I would also set showcounts="1" to zero or delete it.

All in all I would recommend to strip down tru_tags attributes one by one to see if one or two specific attributes cause the load. Go back to default values and work your way up.

In general the issue looks like a database issue. tru_tags is pretty clean & tested well.

whocarez · 2010-01-21 20:07:45

Thanks Markus for your hints.

I tried to reduce the attributes – no success.
Then I removed separately the tags in article form and the cloud – no success
I removed all tru_tag tags – no success.
Only and only switching of the plugin brought me a acceptable load.

Btw. I stressed the site with a curl (no cache) script – individual articles and the mainsite.
When I have tru_tags switched on, then a single page request from a partly cached side needs about 10s and the php-cgi process uses 1 core! If I switch tru_tags off, then ceteris paribus a single page request needs only 1s at max!

Hm, I´m stucked :-(

whocarez · 2010-01-21 21:42:35

To play safe I removed the plugin and the tru_tags_prefs table (I had three redirections) and made a fresh install of tru_tags, but again, after activating the plugin the cpu use and respectively the response time is climbing …

Last edited by whocarez (2010-01-21 21:43:29)

merz1 · 2010-01-22 00:48:43

Did you disable the partial cache?
Can’t you use a full page cache like asy_jpcache? (more performance etc.)

That a switched on tru_tags without using the tags is causing the bad behavior points at a plug-in collision.
You can try to play around with the plug-in order.
To analyse which instruction(s) eats up all the ressources you must check the debug output.

whocarez · 2010-01-22 06:50:13

Full caching is not possible, because of elements (weather, financial dates, tags, meta_keywords) that need a different caching time.
The phenomena of using tru_tags without using tags in the textpattern code was caused by “xcache”. If I flush this one, then tru_tags stops working, after removing the tags – sorry my fault …

After that I could discover, that <txp:tru_tags_from_article generatelinks=“1”/> is causing this load ….
And only the php-cgi processes are affected, not mysql, so in my understanding it is not an mysql issue. It is something in php.

So at the moment I use only the cloud in partial cache. If I don`t use the cache, then the site needs more than 10s. But it isn´t waiting for mysql. Look here …


<!-- Runtime:    23,287 -->
<!-- Query time: 0,344383 -->
<!-- Queries: 39 -->
<!-- Memory: 5146Kb


	<txp:tru_tags_cloud listlimit="50" texttransform="capitalize" title="Schlagworte" activeclass="tagwolke" generatelinks="1" usenofollow="1" section="artikel" />
		[SQL (0,00014400482177734): select name from txp_section where searchable != '1']
		[SQL (0,047055006027222): select Keywords from textpattern where Keywords <> '' AND ( Section = 'artikel')and Section != ''and Section != 'error_default' and Section != 'tag' and Section != 'kontakt' and Section != 'artikel_senden' and Section != 'test' and Section != 'feeds' and Section != 'newsletter' and Section != 'unsubscribe' and Section != 'mitarbeit' and Section != 'service' and Section != 'drucken' and Section != 'newsletter_real' and Status >= '4' and Posted <= now() and (now() <= Expires or Expires = '0000-00-00 00:00:00')]
		[SQL (0,00015091896057129): select name from txp_section where searchable != '1']
		[SQL (0,035753965377808): select Keywords from textpattern where Keywords <> ''and Section != ''and Section != 'error_default' and Section != 'tag' and Section != 'kontakt' and Section != 'artikel_senden' and Section != 'test' and Section != 'feeds' and Section != 'newsletter' and Section != 'unsubscribe' and Section != 'mitarbeit' and Section != 'service' and Section != 'drucken' and Section != 'newsletter_real' and Status >= '4' and Posted <= now() and (now() <= Expires or Expires = '0000-00-00 00:00:00')]

So it is not an mysql issue.

whocarez · 2010-01-22 08:08:59

Btw. if I create an article and open the write page and also if I open the plugin preferences – that means, everytime the full list of keywords is generated – the responsible php-cgi process is using all of the cpu. That means also for me, I didn`t check the code, that txp:tru_tags_from_article uses the same function, as if it would not only generate the list for the actual article, but the whole list. Or one of the used functions is whether inefficient or my php configuration is constricting/slowing down the function.

Last edited by whocarez (2010-01-22 08:09:36)

merz1 · 2010-01-22 10:55:46

You don’t need generatelinks="1" because it’s default.
I would not use the tag list in article write tab if you have many keywords. I have many keywords & I don’t use the list.

I have two tag pages which really need a lot of ressources: The tag page itself sankt-georg.info/tag and the keyword Hamburg. You might see the real performance when you click but I use a full page cache wrapped around my whole Textpattern site, so chances are good you only see the cache performance :)

Well, if it is a PHP issue with your specific installation you have to dive into the PHP configuration. Memory is always my 1st bet. I run PHP 5.n with 40 MB for the PHP process (AFAIK, it’s a simple shared hosting solution). In the old days with PHP4 I used “memory_limit = 40M” in php.ini (Default was 8).

whocarez · 2010-01-22 12:53:28

merz1 wrote:

I would not use the tag list in article write tab if you have many keywords. I have many keywords & I don’t use the list.

That`s not the problem I see. For me is the main problem, that obviously <txp:tru_tags_from_article /> is using the same function like the cloud tag and I have to cache this <txp:tru_tags_from_article /> for more than a week, but it is only for one “simple” database request to show up some keywords and to link them (instead this tag analyzes the whole column and generates the whole list). This tag was also cached, but every time my site is scanned by some search engines and so the situation is, that not all of these keyword tags are all the time cached. Of course I can cache them for a month or a year, but why should I?
It´s clear that generating the whole list needs some time, but the tag should fetch only the few keywords from an article.

Btw. maybe Nathan should consider caching the whole keyword list, with counts and so on …

merz1 wrote:

Well, if it is a PHP issue with your specific installation you have to dive into the PHP configuration. Memory is always my 1st bet. I run PHP 5.n with 40 MB for the PHP process (AFAIK, it’s a simple shared hosting solution). In the old days with PHP4 I used “memory_limit = 40M” in php.ini (Default was 8).

AFAIK is it not such a problem, the script would return a memory error when it needs more.
But I can not really imagine what kind of problem it could be, because I´m not a programmer.

Last edited by whocarez (2010-01-22 12:53:47)

merz1 · 2010-01-22 13:46:17

I have no idea. The only signal I want to give is that tru_tags is running pretty fine with all the standard features everywhere. There must be something special/odd about your configuration. The problems you see I can’t see. There must be a reason.

Caching the database output is a database thing and not a CMS plug-in thing. We are talking different data abstraction levels.

Please dive deeper into the subject ‘plug-in collision’ & ‘PHP configuration’.

The time of 23 seconds your Textpattern system (=all components) needs to output the debug TXP page is ridiculous! Everything greater than one second is to be considered really bad system performance!

whocarez · 2010-01-22 14:48:28

merz1 wrote:

I have no idea. The only signal I want to give is that tru_tags is running pretty fine with all the standard features everywhere. There must be something special/odd about your configuration. The problems you see I can’t see. There must be a reason.

As I tried to mention above, the problem for me is why <txp:tru_tags_cloud /> needs the same time and cpu like <txp:tru_tags_from_article />

merz1 wrote:

The time of 23 seconds your Textpattern system (=all components) needs to output the debug TXP page is ridiculous! Everything greater than one second is to be considered really bad system performance!

It´s because of tru_tags_cloud, weather- and financedata, my scripts are not efficient, the responds of the sourcesites are not so fast and because of that I cache the output. Without tru_tags – it is uncached under 10s and with partial caching it is under 1s, so there is no problem.

Last edited by whocarez (2010-01-22 15:02:48)

truist · 2010-01-22 15:44:09

Andreas,

Can you tell us what markup you are using for your tru_tags_from_article call? Specifically, are you using the useoverallcounts attribute? If so, that would explain why that call is slow – useoverallcounts has to load the entire tag cloud, for every article shown on the page.

Also, note that tru_tags is not as efficient as it theoretically could be, because it is using the Keywords field for entering the tags. The problem is that the Keywords field is a Textpattern feature, and the entered keywords are just stored in a field in the Articles table, so there’s no centralized table that lists all the keywords. That means that every time I need to generate a complete tag cloud, I have to load all the keywords from all the articles, and then merge them together into a unique list. That operation will tend to get worse quickly as the number of articles, number of keywords, and number of keywords per article increases. I don’t know for sure if that’s your problem, but in could be. (In fact, Marcus’ site seems to be proof that it isn’t too much of a problem for very heavy tag use, so I would guess that that’s not the core problem for your site, either.)

And Marcus – thanks, as always, for your help on this thread.

whocarez · 2010-01-22 16:47:00

truist wrote:

Can you tell us what markup you are using for your tru_tags_from_article call? Specifically, are you using the useoverallcounts attribute? If so, that would explain why that call is slow – useoverallcounts has to load the entire tag cloud, for every article shown on the page.

<txp:tru_tags_from_article texttransform="capitalize" generatelinks="1" />
I tried also
<txp:tru_tags_from_article texttransform="capitalize" generatelinks="1" useoverallcounts="0" />

Maybe there is a problem with xcache. I will test it ….

Textpattern CMS

Textpattern CMS support forum

#649 2010-01-21 18:32:31

Re: tru_tags: A tagging plugin for textpattern

#650 2010-01-21 20:07:45

Re: tru_tags: A tagging plugin for textpattern

#651 2010-01-21 21:42:35

Re: tru_tags: A tagging plugin for textpattern

#652 2010-01-22 00:48:43

Re: tru_tags: A tagging plugin for textpattern

#653 2010-01-22 06:50:13

Re: tru_tags: A tagging plugin for textpattern

#654 2010-01-22 08:08:59

Re: tru_tags: A tagging plugin for textpattern

#655 2010-01-22 10:55:46

Re: tru_tags: A tagging plugin for textpattern

#656 2010-01-22 12:53:28

Re: tru_tags: A tagging plugin for textpattern

#657 2010-01-22 13:46:17

Re: tru_tags: A tagging plugin for textpattern

#658 2010-01-22 14:48:28

Re: tru_tags: A tagging plugin for textpattern

#659 2010-01-22 15:44:09

Re: tru_tags: A tagging plugin for textpattern

#660 2010-01-22 16:47:00

Re: tru_tags: A tagging plugin for textpattern

Board footer