faster

tomu

New Member
Hi,
I would like to kindly ask for some help - I run a site based on joomla and have fabrik component. My problem is that when I click on the site to browse the data, I have to wait really long time. I have checked that it's not joomla fault. Do you have any idea how to make it work faster?

My server data:
Fabrik 3.0.9.1 paid version
Joomla 2.5.20
php version 5.5.13
Database driver: mysql

Thank you in advance for your help.
 
Normalize the table. Make sure less element and database join for each table. With normalization you can load your data faster even your data over 2 million row. I have tested by my self.
 
I'm not sure what you mean by "paid version". We don't charge for Fabrik, period. We only charge for subscriptions to the support forums.

If you'd like to enable J! debug (so the profiling shows at the bottom of the page), and make sure Fabrik debug is enabled (in Fabrik's global options), and give an example URL that has problems, I'll take a quick look.

-- hugh
 
Paid version has been add by mistake - sorry for that we have other components and some of them are commercial - thats a reason.
No problem I can give you access to Joomla you help us already with previouse installation some time ago so trust level in your case is 200%
If you still use the same skype nick, I still have it and we can communicate that way regarding access details.
 
Apologies about the slow response, but this thread was in the Community forum, which I rarely have time to check in. Just saw your email, and have moved this thread to Pro.

Yes, I still have the same Skype login. But the best way to give us access to is too in you My Sites details (link to th eleft of any of your posts), so other support staff can get access as well, not just me.

-- hugh
 
Thank you for the advice. Info in My Sites details is already completed. Please remember that this is really urgent, we wait for your help.
 
The login credentials you have given us don't work:

sername and password do not match or you do not have an account yet.

-- hugh
 
I need to enable J! debugging, so I can see the profiling for page loads, but your configuration file is unwriteable.

"Could not save data. Error: Could not write to the configuration file"

Can you fix your site so I can make configuration changes. Enabling the ftp layer may do it, or you may have to temporarly change permissions on the ./configuration.php file.

-- hugh
 
We really need to make it done. You can make changes , so there shouldn't be a problem any more. Let's be in contact today - I will often look in here... just in case.
 
We talked on Skype today. As per conversation, I think there is something strange going on with your server. The only thing I can think of to do next is see if I can replicate the issue by installing an Akeeba clone of your site on my test server.

I tried doing the Akeeba backup after you left, but there's a JS error on your Akeeba backup page, and I can't kick one off, the JS error is in the Akeeba page loading code, and the Backup Now button just doesn't work. I googled the error being logged (look in the Akeeba log tab), and their only suggestion is re-install Akeeba.

-- hugh
 
Strange, i still get that JS error when I try and generate one. Anyway, attempting to download it now.

-- hugh
 
OK, took a while, but I got it downloaded, installed and an Eclipse project built around it.

Unfortunately, as I expected, I can't replicate the results you are seeing. The slowest I can get that list to load is about 7 or 8 seconds, which is about what I'd expect on a table of that size, rendering that many rows:

http://screencast.com/t/NBLdNU3lg3V

As you can see in the debug profile, there are none of those big 20 0r 30 second logjams we see on your site, the longest single operations are a couple of seconds formatting things like the date column, which is expected (date formatting is a pain). And my copy is running on a VirtualBox guest VM, a Centos image with just 2GB of memory, on a Windows 7 host running on a little TS140 server (Intel i3). Which is also running a half dozen other VM's, and is my (fairly busy) Torrent server, and my media server (Plex). So it's competing with a lot of other stuff for resources.

So as I said, there is something on your server which is causing more or less random bottlenecks in processing. If you recall, when I worked on this on your site, there are big pauses were moving around between profile checkpoints, it wasn't consistent. Which if it was a Fabrik specific issue, wouldn't happen.

To make any more progress, I'll need to get ssh access to your server, so I can do some command line performance monitoring, see if I can spot anything.

-- hugh
 
Just FYI, that screencast was the first time I displayed the list, immediately after getting the site up and running. So nothing was cached, anywhere.
But ... it looks like you have removed some of the pre-filters you had on the list before. Can you remind me of what those were, so I can add them back on my copy?

-- hugh
 
OK, here's a peek at your process usage as I load the list on your machine:

http://screencast.com/t/kowK6L21

And here's mine:

http://screencast.com/t/wsup8fOs8zl

As you can see, you are running the FastCGI (php-fpm) process manager, and the PHP pool for that request is going nuts for many seconds, consuming up to 90% of your CPU, and takes ages to load the page.

On the other hand, my machine, not running php-fpm, hardly busts a sweat, and loads the page in a few seconds.

My machine is running the Akeba clone you made for me. Both of the tests I cast above were run as the 3rd of three consecutive loads, all of which displayed the same behaviour.

This is clearly not a Fabrik issue, it's a server setup issue. I suspect some deliberate pool restriction / limit, or bug in FastCGI / php-fpm.

-- hugh
 
You also appear to be running 'SurveillanceStation' on the same machine, which is an NVR (network video recorder) system, which is locking up the CPU for long periods of time, and is very probably causing I/O bottlenecking, through high write load. Along with that are CloudStation, MediaStation and VideoStation, all using up metric pooploads of CPU and memory.

I did ask you several times if you had anything else running on the machine which might be holding things up, and you said "No"!! An NVR, doing realtime video recording, along with media serving, are EXACTLY the sort of thing that can throw long, blocking wait states on a server.

-- hugh
 
OK, I'm out of ssh now. Nothing further I can do. It's not a Fabrik issue.

The list you are displaying may never load super fast, as you are displaying "all" rows, and the more rows you display, the longer it takes us to format all the rows for display. But the longest I could make it take on mine was about 6 seconds. If you want to add the pre-filters back in - I don't know what they were when we started, although I think there was at least a user ID filter in there - I can apply those here and see what difference that makes, and see if I can optimize that query at all.

But there's no point me doing anything till you've resolved your overall server performance issue, which is going to mean moving that NVR service elsewhere, or moving the web site on to it's own server.

-- hugh
 
Thank you for careful check. According to your advice, I will move the NVR.

Anyway, there is still another issue, which I already mentioned on Skype - when the cache is on, the loading of the rows is quite fast (enough fast), BUT then the search doesn't work (search field is also very important). Do you know the reason?
 
Which cache? There are three possible cache options affecting how lists load.

The standard J! page cache, in the J! global settings.
The J! system cache plugin.
The Fabrik List setting (under Advanced tab)

-- hugh
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top