Jump to content

Welcome to 1Emulation.com
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account
Photo

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

- - - - -

  • Please log in to reply
13 replies to this topic

#1
Kloplop321

Kloplop321

    Proud Fan

  • Premium Members
  • 215 posts
  • Gender:Male
  • Interests:I Unintentionally the internet.
Click to view battle stats
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.

#2
emsley

emsley

    Meow - meow - meow

  • 1Emu Veteran
  • 6,706 posts
  • Gender:Male
  • Location:England.
  • Interests:Yelling.
Click to view battle stats
Thats exactly what I was thinking. :moptop:

#3
miskie

miskie

    Ambassador

  • Admin
  • 183 posts
  • Gender:Male
Click to view battle stats
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.

#4
Kloplop321

Kloplop321

    Proud Fan

  • Premium Members
  • 215 posts
  • Gender:Male
  • Interests:I Unintentionally the internet.
Click to view battle stats
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?

#5
miskie

miskie

    Ambassador

  • Admin
  • 183 posts
  • Gender:Male
Click to view battle stats

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.

#6
Kloplop321

Kloplop321

    Proud Fan

  • Premium Members
  • 215 posts
  • Gender:Male
  • Interests:I Unintentionally the internet.
Click to view battle stats
Yeah and translations lose information and use assumptions.

So, what's keeping 1emu on IPB?

#7
Alpha

Alpha

    Your Ayatollah of Rock N' Rolla!

  • Admin
  • 7,384 posts
  • Gender:Male
  • Interests:Face to face interaction, women, and some old games.
Click to view battle stats
To the most frequent visitors: lately, how have the loading speeds (slow, medium, fast) been here on 1emulation?

#8
Hard Core Rikki

Hard Core Rikki

    Proud Fan

  • Staff Members
  • 230 posts
  • Gender:Male
  • Location:Perpetual Hawaii
  • Interests:Emulation. Among others.
Click to view battle stats
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.

#9
Alpha

Alpha

    Your Ayatollah of Rock N' Rolla!

  • Admin
  • 7,384 posts
  • Gender:Male
  • Interests:Face to face interaction, women, and some old games.
Click to view battle stats

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.

#10
Alpha

Alpha

    Your Ayatollah of Rock N' Rolla!

  • Admin
  • 7,384 posts
  • Gender:Male
  • Interests:Face to face interaction, women, and some old games.
Click to view battle stats
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.

#11
Alpha

Alpha

    Your Ayatollah of Rock N' Rolla!

  • Admin
  • 7,384 posts
  • Gender:Male
  • Interests:Face to face interaction, women, and some old games.
Click to view battle stats
Fixed the glitchy forum category box bug for the 1Emu v5 skin... if any of you know what I'm talking about :lol: ...
Still looking for an efficient way to fix the scrolling speeds. :)




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users