OK, So... I kind of need to apologize.

Wed, 24 Oct 2018 15:38:50 +0000

I've alluded to it, but never really said it very forcefully in any of the forums, but I've thought it VERY loudly. Until today, I have found myself frustrated by how "slow"/"sluggish" Hubzilla feels compared to, say Facebook.

I'm Sorry

I'm sorry, because it wasn't Hubzilla.  It wasn't the database queries.  It wasn't even that the default number of items requested with each update.

It was, me.  It was my fault.  Quite simply, I was running an incomplete and sub-optimal PHP configuration on my server.

I had honestly thought I had installed and configured php-opcache.  But I had not.

Now that I have done so, Initial page load is around 2 seconds (on a fixed wireless Internet connection -- I have NO access to high-speed wired connections like DSL/Fiber or Cable where I am), and item loading time is around 3-4 seconds.  This is almost exactly the same as the performance of Facebook in my environment.

I will still be monitoring for the traffic spikes of incoming deliveries that I had noted before that had my server crying "uncle" - but I suspect that will be very much improved and nearly non-existent as well.

So to @Mike Macgirvin  and everyone else whom I subconsciously or subvocally "yelled at" for turning out sluggish code, "I'm sorry."

To anyone else who is experiencing slowness and has control over whether or not opcache is running - consider turning it on.  It's a whole new world.

NOTE: If you choose to use OPCACHE - make sure you do your research and read up on what the options do and you understand clearly your configuration.  Because the opcache stores compiled code and reuses it on subsequent invocations of that code, updating your Hubzilla code either requires a few extra steps or at least a careful awareness of how OPCACHE works.  If you experience ANY weirdness after updating Hubzilla - make sure to do what is needed for your configuration to CLEAR the cache.  Usually that is just to restart the web server or php-fpm.  But that may not be the case depending on exactly how you configure it.  If you don't do the research to understand how it works, don't implement it.  Since this is VERY configuration specific, it is very unlikely that others will be able to offer much help.  When in doubt - when debugging a problem - turn off the cache and make sure the problem still occurs with the cache OFF before submitting any sort of bug report.

Wed, 24 Oct 2018 16:27:12 +0000

Rule #1 in software testing and evaluation: Double/triple and quadruple check your assumptions and your own configuration and implementation - basically, anything YOU may possibly have messed up - before attributing the problem to the code given to you by someone else.

Waitman Gobble

Wed, 24 Oct 2018 19:41:44 +0000

I only recall a slowness years ago, when there were a gadzillion redundant SELECT * queries. It was probably friendika back then.

Facebook is slow to load. Sometimes 30 seconds or more. They do have a 'free version' which looks like 1990s (of course way before fb). Its OK. I don't see how to convince fb to load the free version on a desktop.

Mario Vavti

Wed, 24 Oct 2018 20:06:12 +0000 last edited: Wed, 24 Oct 2018 20:15:37 +0000

If you experience slow pageload on the channel page this could be due to the fact that we load the page content twice on the initial pageload. Once for the seo optimized noscript tag and then again when you see the page spinner.

Set system.noscript_content = 0 to disable the noscript content if you do not want/need it at your hub.