Wiki seems to be slow

… especially when using the “back” button in the browser…
… anything we can do about this?

some measurements:
Opening wiki: 7 sec. - ok
Opening “Manual” from entry page: 8 sec. - hmm quite a long time
Opening “Getting Started”: 5 sec. - long, but ok
using browser back button: 9 sec. - too long…
(all of these have been opened before, so should still be in cache)

opening new page (not opened before):
5-8 sec. - ok

When I’ve done intensive modifications of the wiki I have suffered the same problem. I usually open several pages in different tabs and edit multiple pages at the same time. It is a pain when you press the edit button or preview the changes.
I don’t know what can be done taking in consideration that the resources are from a free host service (tuxfaimly)
-G

Wiki probably will be a bit faster when we will get rid of joomla.

Hmm, why should it depend on Joomla?

Because they shared same limited resource - server memory?

But you would need to get something else but Joomla for the webpages, right?
Do you have something significantly less resource-hungry that you like to use?

See discussion here: New host services

commented the toughts around moving from Joomla to mediawiki there…
but as for the performance… no good reasons found there…

can we move the mediawiki and content to one of my servers just to see whether or not it is faster there?
Would like to test that… can you help a bit? Don’t know how to install mediawiki and how to move content from there to another server.

do we see how many users on the wiki at a given time somewhere?

can we get any numbers/statistics from the server (like from “top”) when we experience performance problems, so that we can see whether or not this is a problem with Joomla making the server slow down or just mediawiki or something else?

I noticed that mediawiki seems to run slower for me when I’m logged in. Is this the case for anyone else?

I’ve not said that the problem is joomla only. I’ve said that getting rid of joomla can reduce server load.
The problem is extensive usage of templates. But we can’t live without them.
Eventually I can rewrite some complex templates into MediaWiki extensions - that can increase speed, I think.

I think we can give it a try, but later - currently I’m concentrated on documentation.
I foresee the questions here: cost of the servers, their type (shared hosting/VPS/dedicated).
Possible drawbacks: if you’ll disappear we will be unable to resolve server problems if they appear.

can we get any numbers/statistics from the server (like from “top”) when we experience performance problems, so that we can see whether or not this is a problem with Joomla making the server slow down or just mediawiki or something else?
[/quote]
stats.tuxfamily.org/synfig.org/ - this may help

Hi,

very interesting numbers…

Assuming caching on the server works for the most used the best
I don’t think that moving off the joomla part would help a lot…
I’ll work with the statistics a bit more… will post here by then.

I’ve analyzed some of the numbers, haven’t found any big problems for wiki and joomla so far.

What really puzzled me was this:
page “/forums/download/file.php” is one of the most accessed pages
and if multiplied w/ average data it is leading by factor 2.5 over “/” and factor 5 and more over the rest.

The total amount of data transfered is 1/3 of all data transfered (of the data listed per page)
So this seems to be significant.

I’m not aware of where this gets called and if we can reduce the amount of calls and/or data.

Maybe it’s accessed for every file downloaded from the forum - e.g. sif files, or challenges pictures…?

Yes, it’s the way how phpbb handles attachments. It masks original attachment address by wrapping it through file.php.

just want to say: was having much better performance today… anything changed?

nothing

was getting worse later on… :frowning:

OK, I have reimplemented most resource-consuming wiki template (L) in pure php. I wonder if wiki will be any faster now.