Akelos Framework v1 forum archive. This forum is no longer maintained. To report bugs please visit https://github.com/akelos/akelos/issues
    • CommentAuthorsuthern

    Odd question to be sure, but here's my issue.

    I have two identical (or close to) PHP + mysql installations.

    On one machine, accessing the home page (aka http://{ip}/{app_name}/) takes very little time. On the other machine it takes 1-2 seconds, sometimes hangs for 20 secs.

    The router (on both setups) takes the url above and goes to /{app_name}/cp/index.

    This Index page has a tiny bit of html code on it, and the controller has nothing

    No other models are being called or loaded, and the CP model has no relations setup, so nothing else is being called.

    Once the page is loaded, hitting refresh on the faster host makes the page just blink. On the slower machine I get the 'loading' symbol for 1/2 a second. The slower host 'feels' slower while doing other actions.

    But the odd thing is, if I do strict PHP tests like loops and such, the 'slow' host actually performs faster.

    That is why I'd like to see some way to put timers (optionally enabled) to track akelos through it's proccess from the time the GET request is received, till the time it's able to write the last little bit to the file and send it back.

    This way I could isolate where the slowdown is occuring (mysql, custom selects, admin::authentication, what_have_you)

    What do you guys think?

    • CommentAuthorsuthern

    Ok, perhaps 'identical' is no the best way to describe the setups. :-)

    The 'fast' host is running CentOS 4, with an XAMPP stack (PHP4).

    The 'slow' host is running on a virtual machine, allocated 512MB ram, Ubuntu Server, fully updated. Funny thing is (as mentioned in last post), the 'slow' host runs strict PHP tests about 5% faster. :-)

    • CommentAuthorKaste

    Can you use the xdebug profiler?

    • CommentAuthorsuthern

    I'll look into it. Thanks for the link!

    • CommentAuthorsuthern

    Ok, I think this speed is a wee bit off. If anyone has WinCacheGrind (or the KDE Version), would you mind taking a look at this and confirming that it is the MySQL calls slowing things down?


    • CommentAuthormerindol

    I checked the profile. I'm far from a Xdebug expert but here is what I can see :

    It seams that nothing spend more time than needed. Mysql queries/fetches are ok. ADODB_mysql->MetaColumns is longer but it's only 5.71% of the whole process (MetaColumns is related to the fact that your models are RecordSets).

    I can't see anything that could load the system.

    Are you sure you gave us the cachegrind.out generated during a "hang" ?


    • CommentAuthorKaste

    I think you have to compare different result sets. Keep in mind that most probably it's all a configuration issue of the virtual server.

    [What you can see staright away is that most time is spent completely useless while including 6 models but in fact you need none. But thats another issue.]

    • CommentAuthorsuthern

    I'm installing xdebug on the other server (xampp stack) right now for comparison. Then I'll dig into the difference in mysql config files and php.ini files.

    I'll keep this thread updated.

    • CommentAuthorsuthern
    wow, there is quite a difference! Here are some comparisons.

    Function (cum.)-------------------- WebDev ------------- WWRI_Server
    _mysql-MetaColumns -------------- 7ms ------------------ 0.8ms
    AKActionCnt.-process ------------- 287ms --------------- 30ms

    I've dumped the database from one to the other, so they are exactly the same, and I've copied over all the akelos files and my project files (changing only the config paths) so all the code is identical.

    Attempts to change speed:
    --Compare and change the 'WebDev' mysql my.cnf file = very little change.
    --Dedicate 1GB of Ram to WebDev = very little change
    --Change priority of VirtualBox.exe (for WebDev) to 'High' = very little change
    --Confirmed that eaccelerator is installed on both = no change.
    Any suggestions as to where I should look next?
    • CommentAuthorsuthern

    Ok, I need some help. I've been experimenting by refreshing the page at various rates.

    There are two files in the attached zip file. I pressed 'refresh' a few times, and it was fast (cachegrind.out.8789). Then I waited a couple seconds and pushed refresh again (cachegrind.out.8691).

    There's a change inf execution speed from 19ms to 202ms. Why? Same code, same exact machine, but a few seconds later. And it's sticky. Now all my requests are in the 200-250ms range again. I think I've got a grimlin in there somewhere!

    • CommentAuthorsuthern

    Ok, I seem to have to do with having multiple /usr/sbin/apache2 -k start processes using CPU even when nothing is going on. (on WebDev)

    root      9090  0.0  1.1  43576 12040 ?        Ss   14:13   0:01 /usr/sbin/apache2 -k start
    www-data  9163  0.3  1.8  46100 18996 ?        S    14:18   0:03 /usr/sbin/apache2 -k start
    www-data  9164  0.3  1.6  45868 17208 ?        S    14:18   0:04 /usr/sbin/apache2 -k start
    www-data  9165  0.2  1.6  46104 16908 ?        S    14:18   0:03 /usr/sbin/apache2 -k start
    www-data  9166  0.0  1.6  45840 16764 ?        S    14:18   0:01 /usr/sbin/apache2 -k start
    www-data  9167  0.2  1.6  45580 16740 ?        S    14:18   0:02 /usr/sbin/apache2 -k start
    www-data  9168  0.2  1.6  46096 17012 ?        S    14:18   0:03 /usr/sbin/apache2 -k start
    www-data  9169  0.2  1.6  45864 16804 ?        S    14:18   0:02 /usr/sbin/apache2 -k start
    www-data  9170  0.3  1.6  45580 16740 ?        S    14:18   0:04 /usr/sbin/apache2 -k start
    www-data  9171  0.2  1.6  46104 16904 ?        S    14:18   0:03 /usr/sbin/apache2 -k start

    Now I'm curious. What are those processes doing when no one is requesting a page?

    On 'wwriserver', all the apache processes show 0.0 cpu usage. Well, I've got the 350ms down to loading in 33 - 40ms. How? I'm not entirely sure. Now I can start pruning models I don't need to load to speed it up even a bit more.

    • CommentAuthorKaste

    Now I'm curious how you did that.

    If its a static page, it's a no-brainer, just wait till arno merges the cache-functionality into the trunk. he said until monday. thats 6 hours ... counting.

    • CommentAuthorsuthern

    Hey, I'm curious too. The last things I modified were in apache config or php.ini that had to do with mysql connections. I really wish I knew what sped it up too. If I run into the problem again I'll do a more detailed fix log. :-)

    Cache-functionality in the trunk? sweet!

    • CommentAuthorarnoschn