Support

Hello Nicola,

First let me address your issue and question.

The log analyzer uses an engine similar to the backup engine. It tries to parse the log file by breaking the process in many steps, each one being a separate page load. I believe that in both cases the process is interrupted because the server is blocking requests from your IP address because it believes that you are using too many resources. There is no solution for that. In the end of the day there is an absolute minimum of work which has to be performed, an atom of work if you want. If your server cannot process this absolute minimum amount of work when we are parsing the log file there's nothing we can do on our end.

Regarding the Configuration Wizard, it is designed to detect hard, deterministic limits imposed by the server. Resource usage-based IP blocking, which is what you're experiencing, is stochastic in its nature. The non-deterministic way Linux kernel, the virtualization layer and automatic resource usage-based IP blocking works on your server makes it impossible to reliably identify the exact conditions that cause an automatic IP block. Moreover, the same non-deterministic processes involved in getting this result make it impossible to reliably reverse the problem to a set of time settings which will definitely work on your server. The best way to deal with that is trying three different sets of timing options (max/min/bias): 10/1/75 (fast), 5/3/50 (slow-ish) and 3/5/50 (snail pace, the one you used). If neither works then you need a very experienced developer with a system administration background (me) to take a look.

Even though I could go on and on about this, I don't think it makes sense. If you want a taste of how complicated things are, when you are using a virtualization layer (all modern servers do) the rate at which you read files may cause memory exhaustion despite having a hard limit of the filesystem cache size because the garbage collection process which clears the RAM used by filesystem cache doesn't have the time to run. Even though that sounds like something straight out of Simon's (the infamous, fictional Bastard Operator From Hell) calendar I can assure you that it's totally true and took me a good half day to debug two months ago. In the end of the day adding a half second delay between backup steps and shortening the backup step length to under 5 seconds gave the damned server enough time to clean the filesystem cache and not run out of RAM while taking a backup. It also improved the performance of the server during the backup. That's the level of non-determinism we are talking about.

Now, regarding your complaint about tickets. I am always alarmed when I hear that our clients think that they didn't get adequate assistance, so I went looking through all your tickets from the past year. I can't find one which is closed without resolution. Every ticket of yours I read from the last year ends up with you telling us that the solution is accepted, or us telling you that your suggestion will be discussed (it was not a ticket about a problem) or me telling you to contact Watchful about an issue that was on their end (and they subsequently told me they fixed). If you have a ticket which you believe was closed in error please tell us. All the tickets automatically closed after 30 days of inactivity send you an email reading "This ticket has been automatically closed. All tickets which have been inactive for a long time are automatically closed. If you believe that this ticket was closed in error, please contact us". Tell us which ticket you believe was closed in error so we can understand where the communication problem was.

Hi Nicola,

If you are on a Rochen shared host or if you have dozens of sites on a fairly standard managed virtual server (MVS) then you do have some very strict resource usage limits. All shared hosting / virtual server platforms do that by necessity. It doesn't help that WordPress lacks any kind of sensible caching, unlike the latest versions of Joomla! 3.

WordPress performance is, indeed, not very spectacular. Especially when compared with Joomla! 3.8 on a modern server (PHP 7.0 or later) I can see how WordPress is lagging behind. The myth that WordPress is faster mostly comes from the era of PHP 5.2 and Joomla! 1.5 where, indeed, WordPress was much faster owning to its much simpler internal architecture. However, as newer versions of PHP are optimized for running more complex code and Joomla! gets much more serious about its internal architecture the scales have tipped.

I would argue that as far as clients go, it's our job as technologists to guide them to what is best for their use case. If they have a blog and they want to own the comments WordPress is a must have. If they want a simple shop then maybe WordPress with WooCommerce is better than Joomla! and VirtueMart or HikaShop. If they want a simple business portfolio with no interactivity, no maintenance burden and seldom updates something like Grav or even an off-line static generator like Jekyll (with the site possibly hosted on Amazon CloudFront) would make more sense to them. If they want something more complex and extensible Joomla! is the right tool for the job. If they want a big, complex e-commerce site then PrestaShop or Magento are worth the hassle. If they want a forum and nothing but a forum phpBB3 is a much better fit than Joomla! and Kunena. It's all about specifications and expectations. If your clients demand WordPress remind them what Henry Ford (allegedly) said about faster horses.

Regarding the tickets it was not clear that on the log analyzer ticket you were expecting a reply about the log analyzer. Both me and Davide thought your goal was to get the backup running. Now it makes sense. Please accept our apologies. The other one is indeed a suggestion that's why there was no further reply :)

Now, regarding the backup. You could try some different settings and see if we can get it to run. Always talking about max/min/bias settings, I'd first try 10/2/50. If my suspicions are right it will die very fast. Then try 5/4/60. If that fails go for 5/5/50. If that still fails, sorry, you'll have to use the snail pace settings.