Loading...
 
Skip to main content

Features / Usability

Forum List Topic List

Forums » Features / Usability » Problems displaying wiki pages that contain many images - error 508
 
Thread actions
Print this page
  • Print all pages

    • Problems displaying wiki pages that contain many images - error 508

    Posted by mbeewik posts: 11 Australia

    I look after a small wiki for a vintage computer interest group. We’ve been running Tiki successfully for a few years now and we’re currently using Tiki 15.4. Our wiki has been slowly but surely growing over that time but a new problem has now started to emerge that I’m hoping this group may be able to help with.

    Our problem is that images are failing to display correctly if we have more than about 20 images on a single wiki page. There are no problems if the page contains fewer images than this, but we do have a few pages with more than 20 or so images and they consistently give problems. The underlying server error for each failed image retrieval is “508 - Resource Limit Is Reached”.

    Our site is hosted on a shared server running cpanel. We have a low-end plan that’s limited to 22 “entry processes” and this is the resource that’s being exhausted by visiting the problem pages. A single user visiting a single page containing more than about 20 images is enough to cause the problem – its not related to other server users or load as far as I can tell. The limit of 22 processes seems to be fairly typical for low-end hosting plans.

    Our images are all stored in the File Gallery and are referenced within pages using similar syntax to this:
    img type="fileId" fileId="36" thumb="box" rel="boxg" max="250" responsive="y"

    Tiki then turns each of these image references into an html img statement similar to this:
    img src="tiki-download_file.php?fileId=36&display&max=250" …(remainder removed)

    From some research and testing, the problem seems to be that each php call within a page consumes a cpanel “entry process”. So, when we have too many images on a page we’re simply generating too many outstanding php calls and exceeding the server entry process limit. The issue may be related to the amount of time it takes to fetch and process each image, leading to an accumulation of outstanding php calls until we hit the limit but I’m really just guessing at this point.

    One possible solution that does work is to split the problem pages into multiple smaller pages with less images on each. This isn’t ideal though as the information does logically fit on a single page in most cases. I have also tried resizing the gallery images to avoid having to dynamically rescale them at display time, and so hopefully improve processing time, but this didn't have any effect on the problem. Moving to a larger hosting plan with higher limits is not really an option for the group unfortunately.

    Does anyone have any other thoughts on what might be causing this problem and/or how it might be fixed?

    Reads: 3514
    Posted by Bernard Sfez / Tiki Specialist posts: 8654 France

    Mmm... Optimising Tiki to work per your hosting plan requirement is "always" possible but it will require time and skills (both = money). This is not something that can be easily fixed and it seems specific to your environment.

    Most of us (I do) have pages with more than 20 images or 22 processes and no problem.

    Did you try to display you images a different way.
    The plugin img has an option to display ALL the images from a file gallery.

    Posted by mbeewik posts: 11 Australia

    I've just tried displaying all images in a gallery using fgalId. Unfortunately this doesn't work either.
    The reason I think is that Tiki expands the single plugin img statement into multiple separate calls to tiki-download_file.php in the html, one call for each image in the gallery. So the html result is essentially the same as using multiple plugin img statements to display each image separately.


    Posted by Rick Sapir / Tiki for Smarties posts: 3665 United States

    First, I would review the error log to confirm that the tiki-download_file.php scripts are causing the problem. I have several sites running "basic" hosting plans (from Bluehost, Hostgator, etc) with many images on a single page and have never encountered this issue.

    Then, I would review the resource limits from the Tiki Server Check and confirm that your settings are correct.

    Finally, take a look at the Performance items to see if you can offload some of the server functions.

    HTH,

    - Rick | My Tiki Blog | My Tiki UserPage

    Why be a dummy? Get smarty! TikiForSmarties.com
    Tiki for Smarties, your source for the best (and only) Tiki books, guides, and tutorials.

    Posted by John Morris posts: 758 United States

    I had this happen to my own tiki awhile back. The issue was not enough memory, my php.ini was set really low, it's a wonder anything worked.
    As Rick said, check to make sure your ok with the Tiki Server Check, if you have any issues accessing your hosting configurations, your hosting company will do if for you.
    Hope you get it squared away!
    If you do, please report back on what the issue was, and the solution.

    Posted by mbeewik posts: 11 Australia

    Server Check shows the PHP "memory_limit" to be 756M and marks it as "good" so I guess we can rule that one out as a possible cause.

    I can't see much of concern in the other parameters either. There are no "bads" at all. There are a few "uglies" for MySQL related to character set and collation. The Apache section is empty which I guess has something to do with this being a shared server configuration because the Server Information section says we are running a version of Apache. The PHP section has 2 "uglies" for max_execution_time and max_input_time but it seems happy with everything else.


    Posted by mbeewik posts: 11 Australia

    Thanks guys, some great pointers there - much appreciated 😊
    I will work through them over the next few days and post back.

    Rick, just quickly re your first point, attached is some output from Chrome showing which specific page elements are failing. These are the only failures shown in the full log for that page. All failures are php scripts and most are tiki-download_file.php, but not all of them as you can see.

    The other thing I should probably mention is that a browser page refresh will usually result in the page being displayed correctly. What seems to be happening in this case is that the elements that downloaded successfully when the page was first accessed are held in the browser cache so are not re-fetched during a refresh. The refresh only has to fetch the failed elements from the server, which works OK because there's much less work to do (ie less images etc to fetch). The page can be made to fail every time by disabling the browser cache.

    Chrome errors.png (116.08 Kb)
    Posted by John Morris posts: 758 United States
    is your website open to the public, that we may visit it?
    Posted by mbeewik posts: 11 Australia

    I haven't been able to access the server logs yet (the site admin is busy), but I have done some more experimenting. One interesting thing I've found is that if I run 2 concurrent browser sessions the first session behaves as normal (ie, some images fail to display), but the second session fails to display the page at all, giving error 508 instead. Pretty sure this is because the first session uses up all 22 entry processes trying to retrieve the images for itself which leaves no processes free for the second session and so it just fails at the start.

    A few potential solutions that I've been looking at over the last few days:

    1. Move to a hosting plan that doesn't limit entry processes. Pretty sure the group has no interest in this unfortunately.

    2. Store the images as plain files rather than as objects in the File Gallery. If I do this then PluginImg doesn't need to run any PHP scripts to retrieve them and so shouldn't consume any entry processes. This also means that I'd probably have to store a couple of different resolutions for each image to avoid downloading the full resolution image each time. A pretty ugly solution.

    3. Somehow "lazy load" the images so that we're not trying to retrieve every image on the page via PHP at the same time. I have tried a few experiments with this but haven't met with much success. The only thing I did get to work required using embedded HTML rather than PluginImg, together with a small Java script to do the lazy loading but that was also starting to look really ugly and hard.

    So, unless I find something unexpected in the server logs I'm at the point now where I think the best solution will be to just split the pages so that each contains less than the problematic number of images.

    BTW, apologies for not posting my earlier site links message into the right part of the thread - a newbie mistake. Is there a way for me to move it?



    Posted by luciash d' being 🧙 posts: 2432 Czech Republic

    Do you store the files in database or in the filesystem? (see your File Galleries control panel)
    There might be performance and other issues with lot of images if you store them in the database.

    Posted by mbeewik posts: 11 Australia

    They are (or were) stored in the database, but over the last week I have been moving all the problem page images out of the File Gallery entirely and they're now just ordinary filesystem files. In other words, I've been implementing solution #2 from my earlier post and I'm happy to report that the problem is now fixed as a result. 😎

    As a bonus, the pages also now render much faster than they did before. I haven't converted all pages yet, just the ones that had too many included images to display correctly, but the solution is working well for those so I will be applying the same change to the remaining pages over time. Another advantage of storing the images as files is that the pages can refer to them by name instead of by ID number. This makes it easier to keep my separate test system in sync with the main server.

    Anyway, the issue is now fixed from my perspective so I think we can call this one closed. Thanks everyone again for your help on this, much appreciated 😀