Loading...
 
Skip to main content

Custom Share Module 0.1dev

Features / Usability

Features / Usability

Forum List Topic List

Forums » Features / Usability » Performance problems with the TikiWiki
 
Thread actions
Print this page
  • Print all pages

    • Performance problems with the TikiWiki

    Posted by wimvincken posts: 60

    Now that I have running the TikiWiki on a dedicated server, I have the ability to take a close look what is going on with the server when the TikiWiki is running.

    I use phpMyAdmin for that, because I discovered the biggest overhead of TikiWiki is its connections to the database (MySQL).

    And I must tell you that it is really expensive in processing and specially database connections.

    -

    I've upgraded my server with many gigabytes and that is already really enough. I changed the address space in php from 256Mb to 700Mb, and I see the difference in performance. The pages are going quick, menus are very fast.

    But then it comes. The second person shows up, then the third, etc. and the problems begin.
    The speed is reduced again and what makes it so slow? I look to the server load (0.05%-1.1%) and that was fine. But then I saw the number of connections to the MySQL, and my heart froze (including the fancy, big dedicated server by the way) ("Too many Connections to the database").

    Back to the TikiWiki (after resetting the machine and put the TikiWiki on hold).

    The TikiWiki I use has only one component: the galleries. The rest I stripped from the TikiWiki, because it was too heavy.

    When one person is downloading a file (a 'large one' of 1 Mb), a data connection is being made and stays until the download is finished.
    But I have also files with 25 Mb and the same occurs, of course.

    And what happens when 10 people download at the same time multiple files? Right, the database engine crashes (too many connections in the database).

    There is nothing I can do about that, and this is obviously not a bug, it is a design issue. In my opinion, the one who designed it, has no idea that he or she designed to use the TikiWiki for small stuff, nothing serious. Anyone with a public access to the TikiWiki can exploit it and bring down the server in a minimum of time.

    So I do something dirty and limited the connection to the MySQL and what happens. Pen and paper is faster! That is not a solution.

    I can't wait for another version, so I go over to other software (for the galleries). The rest was already forcefully moved, so there is nothing left.

    Sorry about that, but the TikiWiki looks great and 'feels' good, but I learned that it is a trap. What really goes on behind the scenes is terrifying. There is no way I can buy hardware to pull the TikiWiki in a production environment. Buy Oracle? The same, except that Oracle supports more concurrent database connections to the database, but that is also limited. Maybe I need to check for a Microsoft SQL-Server 2008 or 2010. Those DB-servers supports more concurrent data connections and the SQL Server 2010 supports almost unlimited I believe.

    But I have a Linux box and why should I pay for such servers when other software is doing it much different without the limitations?

    And then I can't help to wonder why the designers of the TikiWiki allowed something like this to happen! I would focus on redesigning the engine that it would not have such load on the database.

    -

    I am really sorry, but in production environment, I can't use the TikiWiki, it has too many problems. Maybe later when the problems are solved. Now I am transferring the users I have to another environment and continue with that.


    Wim

    Reads: 2061
    Posted by Bernhard posts: 104

    I'm using TW on a very small site, so I can't judge on the performance bit on large scale as you describe. However, speed is one of the major features missing from TW for years regarding other postings. This is why e.g. spin-offs happened in the past, too. (Next is the search functionality, but that's a different story).

    I still love TW for it's Wiki part, so I'll stick to it. But this thread and some other from the past should really make the developers take a break. If you read the features for 4.0, 5.0 it's all about new functionality. Not a single feature is targeted at: usability, speed, layout, design, architecture, graphics, …

    Dear TW team. Take a break. Copy Apple: they release a whole new major OS release just targeted to usability and stability. TW is already great. Please don't add new features all day long. Take a step back and enhance the core so we don't have to read those "I quit" messages anymore 😎

    All the best, Bernhard.


    Posted by wimvincken posts: 60

    Yes, you are absolutely right. When some of the users figured out the way how to bring down not only the site, but the server as well, that was what they started to do. Impossible to keep the site open anymore. Now I'm moving he whole thing over to other environments.

    And my site was not even big!

    The most important thing from my perspective is my visitors. All of my visitors were complaining about the speed. They don't care about wiki or any fancy things, they want a working site and not something extreme slow.
    And when the system started to crash and brought down other systems and sites with it ...

    Well, no need to continue, huh?

    The TW is an excellent initiative, but I would really reconsider what is going on. Being not commercial is nice and all of that jazz, but even you guys need to h ave a working piece of software. And at the moment, this is the biggest problem!

    And that is not all. With the new features each version brings, there are problems, which are not solved (neither reported).
    An example. You can allow each module in a column to collapse (flip I think). When you do that, it will have a huge impact on the performance!
    That did not happen with the version 3, but happens with the version 3.1.

    When you use the last files as module on your page, the number of database connections doubles and stay open! With too many users online, the database crashes.
    When you have the same, and the search engine friendly URLs are turned on, the site will go down instantly when you refresh the page.


    Posted by Gary Cunningham-Lee posts: 4663 Japan

    The last time I compared Tiki site responsiveness with that for other roughly equivilant software, Tiki was pretty much in the middle of the results, with the most significant factor being how much and what kind of content the particular site is displaying, which is independent of the delivery platform.

    I think the general perception is that Tiki is getting faster with each version (again assuming the site doesn't go overboard activating features, etc.). Performance and security are priorities, and there has been a lot of work to improve in these areas, which doesn't necessarily get written up in feature lists. (This is a factor in some of the regression bugs we've been seeing with the Tiki 3 releases — due to basic revisions to improve underlying methods, etc.)

    For specific bugs and other problems, if people post here to see if there isn't some site configuration issue involved and then if warranted file a bug report at dev.tikiwiki.org, then these can be addressed. It's well understood that not only new features but also squashing bugs and improving overall performance are necessary.

    I'm not especially knowledgeable about database performance so am not in a position to respond on a technical level about your experience there. But the people involved in the project do consider Tiki a serious tool, albeit one that needs to undergo and is undergoing continuous revision for improvement. While Tiki is being used successfully by many sites, it's unfortunate if the development process isn't addressing the specific needs of a particular site at any given point.

    -- Gary


    Posted by wimvincken posts: 60

    That's right, Gary. I understand.

    But the point I am making is that when there is a TW running, and there is an exploit as large as the moon, and that is a serious problem.

    You don't need to be a specialist to see what is going on. An example.
    1. Run phpMyAdmin and choose the tab processes.
    2. Log into TikiWiki and you see several processes to the database (including the SQL-statements).
    3. When you refresh, those processes are gone.
    4. Then go to the file gallery of the TW and download a file
    5. You see a process to the database and it stays like that
    6. When the file is finished downloading, the process disappeared
    7. When the user closes or cancels the download, the process still hangs there for hours! 😧😧😧

    The MySQL database engine is nice, but limited, just like any software. It is able to support a certain number of database connections.

    So, when I take a good download manager, and I download 30 files at the same time or more, and others do the same, the MySQL gives an error "Too many connections" and stops working ... for the server and all relevant websites will crash!
    When I try to restart the server, it refuses, because there are still connections towards the database. The only way (quick way) to continue is rebooting the server and we can continue.

    What I want to say is that this behavior makes it impossible to use the file- and image galleries in public (as are the attachments), which is so fantastic in the version 3. When I offer files for download, I will take the risk that the server will stop working. And it does not help to add memory, processors and the whole thing.

    I personally love the TW, but it is not possible to use the software in production environment. And it is absolutely not possible to use it in public!

    And it's a pity, because I managed to combine in a way forums and TW without any impact and no customizations.

    -

    What I am talking about is not a feature or an issue of performance, but I am talking about the fact that the TW keeps a database connection open to the database while a file is being downloaded. The programmer knows about databases, I assume, and he also knows that the number of connections are limited, and he also knows how more connections to the database, how slower the engine becomes!
    It does not show at the CPU load or any other performance number of the server, the end user detects it, it becomes too slow and takes too long to go from one page to another.

    When I take my TW, open the first page, then go to the File Gallery, I must wait 33 seconds before it is there.
    When there are about 40 database connections open, I must wait for almost 3 minutes before the page appear. But my CPU load is only 0.3!

    I can guarantee you that if you solve that issue with the database connections, the TW will fly for the user (maybe a bit more CPU, but you can do something about that. The database connections stops everything and there is nothing for me left to go to another system! Sorry about that.

    Now I have galleries, which are maybe not as useful as the TW one, but it is fast and does not need any database connections. Now I support up to 200 downloads at the same time without impact on anything. The TW supported about 30 downloads before the thing became so slow for everyone, that you hardly could load any page. And I'm talking about a 4Gb dual processor machine.

    -


    About the bug reports?
    I reported most of the bugs except the last one. The only reaction I saw that the developer acknowledged the report and his answer was that he could not repeat it.
    A week later the version 3.1 came out and there was no change in that bug. I can easily reproduce it with a test page, but your programmer seemed not to be able to do so. Even when I explained how to do it, I never heard from him again.

    Some other issues I also posted, but no reaction at all. After a while I give up.


    Posted by Jean-Marc Libs posts: 40 France
    wimvincken wrote:
    I can guarantee you that if you solve that issue with the database connections


    Are you storing your file galleries in the database or in the filesystem ?

    This is configured in "Admin Home" -> "File Galleries", or you can go directly to:
    tiki-admin.php?page=fgal

    I suggest you should set a file directory for file galleries, change this setting, create a new gallery (the old galleries will still work, but the files stay in database), look and tell us if the number of database connections still goes over the top.


    Posted by wimvincken posts: 60

    No, no, I use the file system, no database.

    But my previous TW used to store all the files in the database. In that version I had not the problem of the database, but the site was unbelievingly slow. The size of the file galleries were about 1.9 Gb large.
    With the new version I thought it would be better to use the file system. Well, I was right with importing and so, and it is indeed faster (with one user).