Railpage

 

Recent software issues causing speed problems

About this thread
 
    •   Search thread   Image gallery
      bevans Site Admin

    Location: Melbourne, Australia
    Guys, now the changes have been made and a new database server installed the speed of the site appears to have been dramatically upgrade.

    What is the continued experience in user land?

    Regards
    Brian
    Posted: 25 Nov 2013 16:33

    Sponsored advertisement

      railblogger Chief Commissioner

    Location: At the back of the train, quitely doing exactly what you'd expect.
    Guys, now the changes have been made and a new database server installed the speed of the site appears to have been dramatically upgrade.

    What is the continued experience in user land?

    Regards
    Brian
    bevans
    Speed has improved quite significantly. Nice work, guys.
    Posted: 25 Nov 2013 16:40
      sydnytrains Chief Commissioner

    Location: McDonalds Front counter serving customers
    Speed has improved quite significantly. Nice work, guys.
    "railblogger"


    I concur. My speed has also increased significantly.
    Posted: 25 Nov 2013 16:42
      YM-Mundrabilla The Ghost of George Stephenson

    Location: Mundrabilla but I'd rather be in Narvik
    Well done - much appreciated!
    Posted: 25 Nov 2013 17:09
      s3_gunzel Not a gunzel developer

    Location: Western Sydney, AU
    Load time: 0.474s 39 database queries in 0.28s
    Footer


    Purrrrdy...
    Posted: 25 Nov 2013 18:04
      wanderer53 Sir Nigel Gresley

    Location: front left seat EE set now departed
    Works well from the Uk:D
    Posted: 25 Nov 2013 19:54
      Graham4405 The Ghost of George Stephenson

    Location: In exile
    Excellent at present, thanks.

    Load time: 0.654s 45 database queries in 0.44s 20.2mb RAM Web server load: 1.92% DB server load: Unknown 1 calls to Railpage API

    Perhaps you would care to share with us the nature of the problems discovered?
    Posted: 25 Nov 2013 20:23
      X'Trapolis-904M Deputy Commissioner

    Location: Melbourne
    Works fast
    Thanks

    Appchaty:)
    Posted: 25 Nov 2013 20:32
      bevans Site Admin

    Location: Melbourne, Australia
    Excellent at present, thanks.

    Load time: 0.654s 45 database queries in 0.44s 20.2mb RAM Web server load: 1.92% DB server load: Unknown 1 calls to Railpage API

    Perhaps you would care to share with us the nature of the problems discovered?
    Graham4405

    fine tuning of the new database server helped.  Ensuring all the database was in memory and not on disk.

    Michael found some slow queries in the code which helped a lot.  I am sure he can provide further information.

    Regards
    Brian
    Posted: 25 Nov 2013 20:36
      s3_gunzel Not a gunzel developer

    Location: Western Sydney, AU
    Out of curiosity; is the DB backed up to disk, in the odd chance that your "intern" restarts the DB server to see what happens?

    Just wondering.
    Posted: 26 Nov 2013 07:11
      bevans Site Admin

    Location: Melbourne, Australia
    Out of curiosity; is the DB backed up to disk, in the odd chance that your "intern" restarts the DB server to see what happens?

    Just wondering.
    s3_gunzel

    The database has a backing store which writes out the transactions logs and also writes out the data.  If the DB crashes jt can be rebuilt using the BINLOG.

    Obviously being in memory it is very fast.

    Regards
    Brian
    Posted: 26 Nov 2013 08:22
      michaelgreenhill Administrator That's Numberwang!

    Location: Melbourne
    Out of curiosity; is the DB backed up to disk, in the odd chance that your "intern" restarts the DB server to see what happens?

    Just wondering.
    s3_gunzel
    The database tables are all InnoDB, not MEMORY. MEMORY tables do not store data on disk.

    What Brian's saying is that MariaDB has been configured to keep table indexes and query results in RAM. It still commits changes to disk.
    Posted: 26 Nov 2013 08:37
      bevans Site Admin

    Location: Melbourne, Australia
    Perhaps I should have said "in memory"

    In any case, there is now enough memory allocated to ensure the entire database "as at today" can be moved into memory over a period if that makes sense.

    Regards
    Brian
    Posted: 26 Nov 2013 10:05

    Last edited by bevans on 26 Nov 2013 10:06; edited 1 time in total
      michaelgreenhill Administrator That's Numberwang!

    Location: Melbourne
    Well now that everything's back in order I can get back to working on the next version...
    Posted: 26 Nov 2013 10:09
      s3_gunzel Not a gunzel developer

    Location: Western Sydney, AU
    Thanks guys; that makes sense
    Posted: 26 Nov 2013 11:11
      David Peters Dr Beeching

    Location: "With Hey Boy".
    Yes a lot faster than it used to be. I now have to make a cup of tea before getting on, a while back I could make one while the next thread loaded. Good work to all involved though and keep up the good work as well.
    Posted: 26 Nov 2013 22:17

    Sponsored advertisement

    •   Search thread   Image gallery
    Display from:   

    Quick Reply

    We've disabled Quick Reply for this thread as it was last updated more than six months ago.

      Reply