Community @ The Turning Gate

Support community for TTG plugins and products.

NOTICE

The Turning Gate's Community has moved to a new home, at https://discourse.theturninggate.net.

This forum is now closed, and exists here as a read-only archive.

  • New user registrations are disabled.
  • Users cannot create new topics.
  • Users cannot reply to existing topics.

You are not logged in.

#1 2016-09-16 01:11:17

gwlco
Member
From: Pensacola, Fl.
Registered: 2012-10-24
Posts: 337
Website

worked 3 hours with bluehost technician and...

It appears that when there is 1 or 2 process going the site responds well. but when there are 4-16 processes or more going the site slows almost to a stand still. He advised me to pass on that the database seriously needs optimizing. Not something I can do, i don't think. I used GTmetrics.com and got allot of information. If you are interested I will provide it in an email, since the length would be too much for this. area.

Offline

#2 2016-09-16 01:16:34

rod barbee
Moderator
From: Port Ludlow, WA USA
Registered: 2012-09-24
Posts: 17,830
Website

Re: worked 3 hours with bluehost technician and...

all of your problems are things Ben will need to look at. Consider sending him Backlight admin and FTP credentials


Rod 
Just a user with way too much time on his hands.
www.rodbarbee.com
ttg-tips.com, Backlight 2/3 test site

Offline

#3 2016-09-16 09:46:24

Ben
Moderator
From: Melbourne, Australia
Registered: 2012-09-29
Posts: 4,399

Re: worked 3 hours with bluehost technician and...

Are you using cloud hosting or shared hosting? If the former then this is a Bluehost issue.  What constitutes a process? What tasks did you or Bluehost run in order to come to that conclusion?

Offline

#4 2016-09-16 10:51:54

Ben
Moderator
From: Melbourne, Australia
Registered: 2012-09-29
Posts: 4,399

Re: worked 3 hours with bluehost technician and...

A longer reply.

I have previously come across one case where a customer was on non-shared hosting with Bluehost, and experienced major performance issues.  The time taken to render a page varied from 50 milliseconds to tens of seconds.  In that case, I found a single line of code that on one page view would be fast to run, but on subsequent page views would be slow to run.  That single line isn't itself the problem.  It just happens to be the line that accesses the database when the database is running slowly.

That customer downgraded to shared hosting, so we didn't pursue it any further.  If you too are on non-shared hosting, then I will try to find a performance bottleneck in the code, then pull out the minimum code needed to reach that performance issue and put it into a single PHP file.  You should then be able to take that to Bluehost to demonstrate that the complexity of the database or queries is not the issue, that the issue can be replicated by nothing more than connecting to the database and running a single select query.

To see the performance on your site, add the performance parameter to the URL. This lists a set of timings for the main database tasks and page loading as a whole.  The debug statements clash with your stylesheet (becoming white-on-white), so you'll need to either Ctrl-A the page to have the text highlighted, or view the page source. 

To make the backend work harder, add skipCache as well, so that you can see the performance of the full rendering process.  Example URLs are then:

http://garylittle.com/galleries/?performance

and

http://garylittle.com/galleries/?skipCache&performance

In my limited testing on your site, the final timing at the very end of the page ranges from 30 milliseconds to 25 seconds.  30-50 milliseconds without skipCache and 100-150 milliseconds with skipCache are the kinds of figures you should be seeing for a well-running site.
This thousand-fold variation of timing suggests other issues at Bluehost.  Our code certainly shouldn't have such a huge variance in execution time from one request to the next.

Offline

#5 2016-09-21 13:06:34

Ben
Moderator
From: Melbourne, Australia
Registered: 2012-09-29
Posts: 4,399

Re: worked 3 hours with bluehost technician and...

Looking at the SQLite documentation, one possible performance issue is accessing the SQLite database over a network.  I am not familiar with the architecture of Bluehost's VPS hosting, and wonder whether the web files are hosted on a network drive.  Only their support will be able to tell you that.
Of course, I don't know whether you're using shared or VPS hosting.

With days between replies on this, so far, can I ask in advance for FTP access to your server so that I can try and run some performance tests?  Please provide it via email.  I am currently overseas with limited Internet access, but will be home by the weekend to look further into this.

Offline

#6 2016-09-21 18:43:48

Ben
Moderator
From: Melbourne, Australia
Registered: 2012-09-29
Posts: 4,399

Re: worked 3 hours with bluehost technician and...

Can you confirm whether you are using the VPS plan at Bluehost?

According to the Bluehost site, the VPS plans house files over a Storage Area Network.  This could explain all of the issue you have been facing.  I have found some database settings that will likely solve the performance problems.  Can you edit the file backlight/framework/dao/SQLiteHandler.php so that the entire file looks like this (make sure to select all of the text in the scrolling box):

<?php defined('APP_DIR') or die('No direct script access allowed in ' . __FILE__); 

class SQLiteHandler extends PdoExtended
{
	public function __construct($args=array())
	{
		//parent::__construct(SQLITE_DSN, null, null, array(PDO::ATTR_PERSISTENT => true));
		$dsn = isset($args['DSN']) ? $args['DSN'] : SQLITE_DSN;

		if (!is_file(preg_replace('/^sqlite:/', '', $dsn))) {
			die('Backlight is not yet configured.  Please login to Backlight at /backlight/ to continue.');
		}
		
		parent::__construct($dsn, null, null, array());

		if (isset($_GET['pragmaSynchronous']) && $_GET['pragmaSynchronous'] !== '') {
			$_SESSION['pragmaSynchronous'] = $_GET['pragmaSynchronous'];
		}

		if (isset($_GET['pragmaJournalMode']) && $_GET['pragmaJournalMode'] !== '') {
			$_SESSION['pragmaJournalMode'] = $_GET['pragmaJournalMode'];
		}

		if (isset($_SESSION['pragmaSynchronous'])) {
			$this->query('PRAGMA synchronous = '.$_SESSION['pragmaSynchronous']);
		}

		if (isset($_SESSION['pragmaJournalMode'])) {
			$this->query('PRAGMA journal_mode = '.$_SESSION['pragmaJournalMode']);
		}

		if (isset($_GET['performance'])) {
			echo 'PRAGMA synchronous = '.$this->query("PRAGMA synchronous")->fetchColumn().'<br/>';
			echo 'PRAGMA journal_mode = '.$this->query("PRAGMA journal_mode")->fetchColumn().'<br/>';
		}
	}
}

?>

Once done, I'll run some performance tests to see whether the settings make a difference. 

The settings can be enabled for your current browser session by visiting:

http://garylittle.com/galleries/?pragmaSynchronous=off&pragmaJournalMode=persist

And disabled by visiting:

http://garylittle.com/galleries/?pragmaSynchronous=full&pragmaJournalMode=delete

Offline

#7 2016-09-27 00:27:27

gwlco
Member
From: Pensacola, Fl.
Registered: 2012-10-24
Posts: 337
Website

Re: worked 3 hours with bluehost technician and...

Thanks for the work. I have been out of the country for a few days, hence no reply.  I will be back on home turf Wednesday evening.
Regards, Gary

Offline

#8 2016-09-27 09:13:16

Ben
Moderator
From: Melbourne, Australia
Registered: 2012-09-29
Posts: 4,399

Re: worked 3 hours with bluehost technician and...

Hi Gary, good news.  The settings appear to have fixed the performance issues on your host.  In particular, the synchronous setting alone looks to solve the problem.  We have added these as settings to our working code for 1.0.5.  In the mean time, you can apply these settings for all users by again replacing the contents of SQLiteHandler, with that below.

<?php defined('APP_DIR') or die('No direct script access allowed in ' . __FILE__); 

class SQLiteHandler extends PdoExtended
{
	public function __construct($args=array())
	{
		//parent::__construct(SQLITE_DSN, null, null, array(PDO::ATTR_PERSISTENT => true));
		$dsn = isset($args['DSN']) ? $args['DSN'] : SQLITE_DSN;

		if (!is_file(preg_replace('/^sqlite:/', '', $dsn))) {
			die('Backlight is not yet configured.  Please login to Backlight at /backlight/ to continue.');
		}
		
		parent::__construct($dsn, null, null, array());

		$this->query('PRAGMA synchronous = off');
		$this->query('PRAGMA journal_mode = persist');
	}
}

?>

Offline

#9 2016-09-27 12:11:48

gwlco
Member
From: Pensacola, Fl.
Registered: 2012-10-24
Posts: 337
Website

Re: worked 3 hours with bluehost technician and...

I found out that I have shared NOT VPS on Bluehost.

Offline

#10 2016-09-27 12:37:41

gwlco
Member
From: Pensacola, Fl.
Registered: 2012-10-24
Posts: 337
Website

Re: worked 3 hours with bluehost technician and...

I found out that I have shared NOT VPS on Bluehost.
IT APPEARS THAT THE PROBLEM HAS SOLVED ITSELF.


However, now after replacing the code here is what is happening after replacement:
search page

and this when pressing Galleries: search page

this is what I replaced:

<?php defined('APP_DIR') or die('No direct script access allowed in ' . __FILE__); 

class SQLiteHandler extends PdoExtended
{
	public function __construct($args=array())
	{
		//parent::__construct(SQLITE_DSN, null, null, array(PDO::ATTR_PERSISTENT => true));
		$dsn = isset($args['DSN']) ? $args['DSN'] : SQLITE_DSN;

		if (!is_file(preg_replace('/^sqlite:/', '', $dsn))) {
			die('Backlight is not yet configured.  Please login to Backlight at /backlight/ to continue.');
		}
		
		parent::__construct($dsn, null, null, array());

		$this->query('PRAGMA synchronous = off');
		$this->query('PRAGMA journal_mode = persist');
	}
}

?>

BTW I think this did drastically improve the response time.  THANK YOU VERY MUCH
On GTMETRIX.com i am now getting 1.1 - 1.3 seconds!!!!!!!!!!!!!
http://garylittle.com

Last edited by gwlco (2016-09-27 14:58:48)

Offline

Board footer

Powered by FluxBB