We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 1041
    • 51 Posts
    I have some threads in my Discuss forum with number of characters close to 30 000 in one post (`discuss.maximum_post_size` setting).

    I have to wait 30-60 sec when I'm trying to view one these threads (or even board with these threads). And it often gives me an error "504 Gateway Time-out". Occasionally I'm able to view these threads, but I still have to wait for server response for a long time.

    However I can view all other threads (with small posts) without such delay and errors.

    Also I can navigate all site pages, manager panel pages and forum threads with small posts while I'm waiting for server response on these threads with big posts.

    Error log after this issue:
    [2013-03-27 21:13:55] (ERROR @ /index.php) Error HY000 executing query: SELECT `modTemplateVar`.`id` AS `modTemplateVar_id`, `modTemplateVar`.`source` AS `modTemplateVar_source`, `modTemplateVar`.`property_preprocess` AS `modTemplateVar_property_preprocess`, `modTemplateVar`.`type` AS `modTemplateVar_type`, `modTemplateVar`.`name` AS `modTemplateVar_name`, `modTemplateVar`.`caption` AS `modTemplateVar_caption`, `modTemplateVar`.`description` AS `modTemplateVar_description`, `modTemplateVar`.`editor_type` AS `modTemplateVar_editor_type`, `modTemplateVar`.`category` AS `modTemplateVar_category`, `modTemplateVar`.`locked` AS `modTemplateVar_locked`, `modTemplateVar`.`elements` AS `modTemplateVar_elements`, `modTemplateVar`.`rank` AS `modTemplateVar_rank`, `modTemplateVar`.`display` AS `modTemplateVar_display`, `modTemplateVar`.`default_text` AS `modTemplateVar_default_text`, `modTemplateVar`.`properties` AS `modTemplateVar_properties`, `modTemplateVar`.`input_properties` AS `modTemplateVar_input_properties`, `modTemplateVar`.`output_properties` AS `modTemplateVar_output_properties`, `modTemplateVar`.`static` AS `modTemplateVar_static`, `modTemplateVar`.`static_file` AS `modTemplateVar_static_file`, `Source`.`id` AS `Source_id`, `Source`.`name` AS `Source_name`, `Source`.`description` AS `Source_description`, `Source`.`class_key` AS `Source_class_key`, `Source`.`properties` AS `Source_properties`, `Source`.`is_stream` AS `Source_is_stream` FROM `modx_site_tmplvars` AS `modTemplateVar` LEFT JOIN `modx_media_sources` `Source` ON `modTemplateVar`.`source` = `Source`.`id` WHERE `modTemplateVar`.`name` = ? ORDER BY `modTemplateVar`.`id` ASC  - Array
    (
        [0] => HY000
        [1] => 2006
        [2] => MySQL server has gone away
    )
    
    [2013-03-27 21:13:55] (ERROR @ /index.php) Error HY000 executing statement: 
    Array
    (
        [0] => HY000
        [1] => 2006
        [2] => MySQL server has gone away
    )
    
    [2013-03-27 21:13:55] (ERROR @ /index.php) Error HY000 executing statement:
    INSERT INTO `modx_session` (`id`, `access`, `data`) VALUES ('23d06d398e9e65f71efe09450af1fec2', 1364208025, 'modx.user.contextTokens|a:2:{s:3:\"mgr\";i:1;s:3:\"web\";i:1;}modx.user.0.resourceGroups|a:1:{s:3:\"mgr\";a:0:{}}modx.user.0.attributes|a:2:{s:3:\"web\";a:4:{s:16:\"modAccessContext\";a:1:{s:3:\"web\";a:1:{i:0;a:3:{s:9:\"principal\";i:0;s:9:\"authority\";s:1:\"0\";s:6:\"policy\";a:1:{s:4:\"load\";b:1;}}}}s:22:\"modAccessResourceGroup\";a:2:{i:1;a:1:{i:0;a:3:{s:9:\"principal\";i:0;s:9:\"authority\";s:1:\"0\";s:6:\"policy\";a:1:{s:4:\"load\";b:1;}}}i:2;a:1:{i:0;a:3:{s:9:\"principal\";i:0;s:9:\"authority\";s:1:\"0\";s:6:\"policy\";a:1:{s:4:\"load\";b:1;}}}}s:17:\"modAccessCategory\";a:0:{}s:28:\"sources.modAccessMediaSource\";a:0:{}}s:3:\"mgr\";a:4:{s:16:\"modAccessContext\";a:1:{s:3:\"web\";a:1:{i:0;a:3:{s:9:\"principal\";i:0;s:9:\"authority\";s:1:\"0\";s:6:\"policy\";a:1:{s:4:\"load\";b:1;}}}}s:22:\"modAccessResourceGroup\";a:0:{}s:17:\"modAccessCategory\";a:0:{}s:28:\"sources.modAccessMediaSource\";a:0:{}}}modx.user.0.userGroupNames|a:0:{}modx.mgr.user.token|s:52:\"modx50a65ac57f5327.42215688_15151c290ba78f8.81515876\";modx.mgr.session.cookie.lifetime|i:604800;modx.user.1.userGroupNames|a:5:{i:0;s:15:\"High Inquisitor\";i:1;s:13:\"Forum Members\";i:2;s:19:\"Ordo Templi Luminis\";i:3;s:9:\"Commander\";i:4;s:7:\"Council\";}modx.user.2.userGroupNames|a:1:{i:0;s:13:\"Forum Members\";}modx.user.20.userGroupNames|a:2:{i:0;s:13:\"Forum Members\";i:1;s:19:\"Ordo Templi Luminis\";}modx.user.23.userGroupNames|a:3:{i:0;s:13:\"Forum Members\";i:1;s:10:\"Inquisitor\";i:2;s:19:\"Ordo Templi Luminis\";}modx.user.24.userGroupNames|a:2:{i:0;s:13:\"Forum Members\";i:1;s:19:\"Ordo Templi Luminis\";}modx.user.21.userGroupNames|a:2:{i:0;s:13:\"Forum Members\";i:1;s:19:\"Ordo Templi Luminis\";}modx.web.user.token|s:52:\"modx50a65ac57f5327.41215388_151532e348578e9.18153524\";modx.web.session.cookie.lifetime|i:604800;modx.user.1.userGroups|a:5:{i:0;i:1;i:1;i:2;i:2;i:4;i:3;i:6;i:4;i:7;}')
    Array
    (
        [0] => HY000
        [1] => 2006
        [2] => MySQL server has gone away
    )


    I tried to search something about "HY000 2006 error", and I've found an advise to enlarge `max_allowed_packet` mysql setting. But when I tried to find out via phpmyadmin
    show variables like 'max_allowed_packet';

    it gives me max_allowed_packet = 335544320. This seems quite enough.. May be these errors in log are not about my issue. Can they be about failures in access to site pages (e.g. by search-bots) while MySQL server was overloaded by forum?

    And yes, I have shared-hosting. But I have never had any problems with forum software like phpbb or smf with tens of users logged in at the same time. Even with big posts. And, as I said above, I do not have problems while viewing other threads. Only threads with big posts.

    I looked resource usage details in my hosting back-end. I have close to 100% cpu usage. Processes and memory usage are barely reach 20% of allowed value.

    What causes such long and heavy processing of long posts? Is it just in my forum or somebody have the same issue?
    • Mark Hamstra Reply #2, 11 years ago
      Long posts can take some time to process. That's actually quite a flaw in the current version: posts are parsed (from bbcode to html) when they are requested. The benefit of that is that it's easy to switch parsers - it still has the original source. The downside is performance.. A lot of regex is used in the parsing process and I reckon that with such a long post, that can take a while to execute and would definitely be taxing the CPU.

      The best solution I'd personally recommend is a core fix where the parsed post is stored somewhere too.

      There's probably some optimisation that can be done on the parsing level too, but I'm not skilled enough in regex to find and fix that myself.
        Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

        Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
        • 1041
        • 51 Posts
        It's not probably, it's necessarily! smiley

        May be some developers have VPS or VDS, but most of us have average Shared Hosting for Modx. And it's more than enough for most of Modx-based projects. Also, as I said before, it's more than enough for third party forums (phpBB, smf, IPB etc.). So I see no other choice but to optimize Discuss performance.

        Unfortunately I can not say that this Discuss version is working. This is critical issue for me, and I suppose not only for me.



          • 1041
          • 51 Posts
          May be this will give the weight to my words wink It's not photoshop))
          • Yeah, I get those frequently when answering a post.
              Studying MODX in the desert - http://sottwell.com
              Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
              Join the Slack Community - http://modx.org
            • Mark Hamstra Reply #6, 11 years ago
              Quote from: sottwell at Apr 09, 2013, 12:38 PM
              Yeah, I get those frequently when answering a post.

              504's when replying come from the notifications - I've just (like, 15 mins ago) deployed a fix for that. We now use the Mandrill HTTP API for sending the notifications, which takes significantly less time on our end compared to sending over SMTP - one at a time. This is also coming to Discuss as an option; just need to document the possibilities for that.
                Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

                Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
              • Mark Hamstra Reply #7, 11 years ago
                Quote from: Alexus at Apr 09, 2013, 12:10 PM
                May be this will give the weight to my words wink It's not photoshop))

                Would've helped if you posted the link as well wink

                I'm not seeing a 504 there when viewing or posting. The issue on posting a reply (which boils down to notifications mostly) is different from the post parser leaving room for optimisation.

                That said.. I'm not sure why your MySQL server would go away on viewing a thread at all. How big is your user base / how many pageviews do you get on your forums?
                  Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

                  Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
                  • 1041
                  • 51 Posts
                  I think, in Discuss 1.2 this issue was resolved - now I don't see 504 error anymore and retrieving time quite good.

                  Thanks a lot!