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.
You are not logged in.
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
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
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
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
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
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
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
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:
and this when pressing Galleries:
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