1Emulation: Site Speed & Load Times (Server responsiveness)

[Kloplop321]

Some of you may have noticed that after the most recent update, the site seems to be less responsive.

I'm getting wait times between 1.4 seconds to 2.9 seconds.

I should only be waiting for the RTT + 160 ms, which for me is around 350ms for a server response.

 

I've done a little profiling with the tools I know, but I can tell that Apache is not at fault here.

 

The causes would therefore be somewhere like in too much execution, such as something very heavy, (an example I can think of is ZenCart with PHP), or there's a problem with the MySQL server, or socket between PHP and the MySQL server.

 

I would suggest, temporarily using xdebug to grab a callgrind in a controlled environment

 

So, what I mean is that you have a subdomain with any random highly unguessable name, which runs a different version of php.ini

 

So, add something like ilikewafflesandbaconwbbq.1emulation.com as an entry as a virtual host in the apache configuration files, and then make a duplicate of the production php.ini, and make a new directory for debug uses.

Then inside that virtualhost entry.

<virtualhost 1.2.3.4:80="">
[...]
PHPINIDir /var/debug/php
[...]
</virtualhost>

where there's a php.ini inside of the /var/debug/php/ folder.

In this php.ini, the entry for xdebug would be enabled.

 

Make sure to set xdebug.profiler_output_dir to a directory where it can be grabbed via ftp

More information can be found at http://xdebug.org/docs/profiler

 

I wish you the best in this endeavor, but having a graphics which shows where the most time takes place really can help you find the cause.

[emsley]

Thats exactly what I was thinking.

[miskie]

Ive already been down this road - its specifically IP.Board 3x - Its full of AJAX. , and IPS are entirely unapologetic for it. While we were upgrading, I shut down this domain, and server load fell to an average of .13 - and during quiet moments, it fell to .00 - And 1emu is far from being the only active hosted site on this box.

 

The second problem is the database itself. The 1Emu you see now, is the same 1Emu from the very beginning, which means the database has been changed and upgraded dozens of times, to accommodate all of the changes made to IP.Board - so the database is quite a bit less structured than an fresh install of IP.Board would be, and it queries more slowly as a consequence. But thats the price to be paid to keep all the history. Oh, and IPS provides no utility to migrate the data from one database to another.

 

If you bang ' Ip.Board 3x slow' into google, you'll find dozens of complaints about the performance of this software. IPS' answer is 'get a bigger server' :/ - So, Ive done what I could to optimize the server, and have the load hovering at about .8 so, things are running well on the server itself, but because of the AJAX and other CPU costly technologies, your browser will still struggle somewhat.

[Kloplop321]

Well, I wasn't testing AJAX actions, only a fresh page load, something you can do with wget or curl.

 

the SMF running on the Final Burn group(which I've been told is running on the same server) is very responsive, so IPB would be where the problem lies.

 

Does IPB not have any built-in optimizations/clean ups routines?

 

I don't mean like with SQLite Vacuum(), but the kind that gets rid of the overhead that the forum put in there for temporary reasons.

Secondly, is it the exact same binary of the database from all these ages, or a restored dump?

[miskie]

Well, I wasn't testing AJAX actions, only a fresh page load, something you can do with wget or curl.

 

the SMF running on the Final Burn group(which I've been told is running on the same server) is very responsive, so IPB would be where the problem lies.

 

Does IPB not have any built-in optimizations/clean ups routines?

 

I don't mean like with SQLite Vacuum(), but the kind that gets rid of the overhead that the forum put in there for temporary reasons.

Secondly, is it the exact same binary of the database from all these ages, or a restored dump?

 

Yeah - that SMF is on the same box as is mine, and they both fly by comparison. And although I have yet to finish skinning The Society, I have modded the bejeesus out of it, and it still performs excellently. Personally, SMF is kind if a homecoming for me - I starter with YaBB, then YaBBSE - then YaBBSE was discontinued, and I switched to Invision, when it was free - and I did intend to buy a license for it - but everytime I had the money together to do so, either the price changed, or the terms and conditions did. So, I ran with the last free Invision for years, and converted it to SMF when I could no longer deal with the security issues the old Invision presented - And SMF is based off of YaBBSE.

 

So I'm back where I started

 

Database -- yeah I am pretty sure that this database has bits and pieces dating back to 2002 in it. I suspect finding a way to build a fresh database and dumping the current data into it would go a long way in aiding this site performance-wise. Repairing and upgrading tables only goes so far... I am certain that the current database is full of cells, columns and rows that are either entirely unused now, or contain data that is irrelevant to Ip.Board 3X. I am also certain that the methodologies used to store useful data has changed, and now MySQL needs to do lots of extra grinding to fetch/write data because of it.

 

Database clean/rebuild utilities - none that I am aware of, unfortunately. At times I wonder if using a forum converter to move 1emu to another platform, followed by a conversion back to IP.Board will help - but then I figure the result may be like using Google's translator to translate something out of English, then back into English. The result is interesting, but not the same as what you started with.

[Kloplop321]

Yeah and translations lose information and use assumptions.

 

So, what's keeping 1emu on IPB?

[Alpha]

To the most frequent visitors: lately, how have the loading speeds (slow, medium, fast) been here on 1emulation?

[Hard Core Rikki]

Regular interface render lag in browsers and heavy page loads (especially for first visits), unrelated to server/app settings. All within reasonable bounds, except the heavy background perhaps.

[Alpha]

Regular interface render lag in browsers and heavy page loads (especially for first visits), unrelated to server/app settings. All within reasonable bounds, except the heavy background perhaps.

The background for the 1Emu Default skin is going to be changed soon, as I am certain that's slowing the site down just a tad more than it already is.

[Alpha]

After various tests with different backgrounds... seems like the slowdown isn't coming from the backgrounds, but the CSS used in the template... my guess is that it's the transparency.

[Alpha]

Fixed the glitchy forum category box bug for the 1Emu v5 skin... if any of you know what I'm talking about ...

Still looking for an efficient way to fix the scrolling speeds.