Jump to content

p4guru

Members
  • Posts

    74
  • Joined

Reputation Activity

  1. Like
    p4guru reacted to Adlago in First byte - analysis   
    In this topic, @ASTRAPI made a detailed description of what is and what the first byte contains, for which I thank him.
     
    For a few months now, I've been doing a lot of first byte analysis and testing in my installation.
    Here are the results I get - pay attention, these results are when tested with a Chrome browser developer tool and I only look at the waiting time, ie. real time in which the server started to work after request, and produces source code.
    Sorted as my stats, the results (probably over 1000 test) look like this:
    70% - waiting time in the interval 90 - 150 ms
    20% - waiting time in the interval 150- 400 ms
    8% - waiting time in the interval 400- 1000 ms
    2% - waiting time in the interval over 1 second, often over 2 seconds
    I created a ticket for my host company because my host plan is expensive and with good parameters guaranteed.
    The guys from the host company have done more than 24 hours of analysis and here's what they found
    Below I post their response.
    ======================
    In one of the many checks that it develops, we notice that "sleep" during loading and run all that are generating source code scripts. To look at the sleep effect of the application, apply a sample of the command that checks all file calls (at system level) during site loading:
    16:03:15.969084 open("/home/database/public_html/system/Session/Front.php", O_RDONLY) = 4 16:03:15.970734 open("/home/database/public_html/system/Session/Session.php", O_RDONLY) = 4 16:03:15.971749 open("/home/database/public_html/system/Theme/Theme.php", O_RDONLY) = 4 16:03:16.983086 open("/home/database/public_html/system/Node/Model.php", O_RDONLY) = 4 After executing the /home/database/public_html/system/Theme/Theme.php file, we see that it is almost a second before the next script is loaded and /home/database/public_html/system/Node/Model.php. For more precision, we see that Theme.php started its implementation at 16: 03: 15.971749, and a second later, at 16: 03: 16.983086, the Model.php implementation started. This second delay is due to the following snippet of Theme.php code:
    /* If we don't have a compiled template, do that now */ if ( ! $cachedObject and !isset( \IPS\Data\Store::i()->$key ) ) { /* It can take a few seconds for templates to finish compiling if initiated elsewhere, so let's try a few times sleeping 1 second between attempts to give the compilation time to finish */ $attempts = 0; while( $attempts < 6 ) { if ( $attempts === 5 ) { /* Rebuild in progress */ \IPS\Log::debug( "Template store key: {$key} rebuilding and requested again ({$app}, {$location}, {$group})", "template_store_building" ); /* Since we can't do anything else, this ends up just being an uncaught exception - show the error page right away to avoid the unnecessary logging */ \IPS\IPS::genericExceptionPage(); } $built = $this->compileTemplates( $app, $location, $group ); if ( $built === NULL ) { $attempts++; sleep(1); } else { break; } } /* Still no key? */ if ( ! isset( \IPS\Data\Store::i()->$key ) ) { \IPS\Log::log( "Template store key: {$key} missing ({$app}, {$location}, {$group})", "template_store_missing" ); throw new \ErrorException( 'template_store_missing' ); } } This part of the code checks whether a compiled template is already available and if not, compiles. Several attempts are made in the compilation process, which according to the code comment may take a few seconds. In our opinion, the presence of sleep (1) is the specific reason for the delay sometimes occurring.
    For our part, we might recommend that you consult the developers who assisted with the site's construction. From our many attempts to reproduce the delay, we see that to a large extent the site is well optimized, but rebuilding templates is a functionality that needs to be discussed with developers.
    In our view, this part of the code is the reason for the TTFB indicator's unconscious state, since it directly depends on the time it takes to process all the functionality involved in generating the source code.
    ==================================
    Whether these guys from the analysis department of my host company are right - I don't know.
    I share it here and look forward to clarification.
    Thanks.
     
  2. Like
    p4guru reacted to Grumpy in Tools & commands to diagnose problems   
    Well, I've seen quite a few requests for help in this forum now and I thought I'd gather a number of tools you can use to report your status. This will help others help you faster. :D That and additional ability to help yourself as well.

    Helpful information
    The following are information that's often crucial to diagnosing problems.
    What is the environment you are running your website from? IPB Hosting / Shared hosting / VPS / Cloud / Dedicated Server? If VPS/Cloud/Dedi, what are your cpu, ram and disk availability?

    Tools
    The following are tools you can run in order to gather further data. These can be run from ssh and is only accessible for vps, cloud and dedicated servers for linux distributions.

    top - Top processes (very useful for any scenario) | top is usually available in all linux OS distros by default.

    top (this will constantly output your server's general status as well as top processes, default in CPU usage order) top n -1 (same as above, but will output your first stat instead of constant loop) If you'd like more colourful version. There is also htop (usually not available by default. Can get here: http://htop.sourceforge.net/ or rpmforge ) iostat - Input/Output Statistics (very useful in diagnosing disk usage) | iostat is part of sysstat package.

    iostat (this will output general stats regarding IO) iostat -x 10 5 (this will output extra information for 5 times total with 10 second intervals. First stat is always "since boot" and after is since last report) sar - System Activity Reporter (Displays system performance over time) | sar is part of sysstat package

    sar mpstat - Multiprocessor Usage (Displays system stats in relative to CPU) | mpstat is part of sysstat package

    mpstat Apache Status (Outputs the apache status) | apachectl status, as name suggests requres apache to get the stats. You will also need to have a shell browser to run.

    apachectl status (This outputs the simplified current status) apachectl fullstatus (This outputs the detailed current status. Please be warned that this will list all users and their requests. So, you will want to remove any IP address and further private information) Connections

    netstat -an | grep :80 | wc -l (This lets us know how many people are connected to your server on port 80 [http]) Uptime (How long you've been up)

    uptime vmstat - virtual memory statistics (This is actually not related to virtualization. This is about your swap)

    vmstat free (Shows your memory statistics)

    free free -m (In megabytes) free -g (In gigabytes) beancounters (Shows your limits) | Only for those with VPS/Cloud systems

    cat /proc/user_beancounters ifstat (Gives live information about network usage on each network interface)

    ifstat iftop (Similar to ifstat, but per user and top behavior)

    iftop mysqltuner (Gives information and suggestions about your current mysql configuration) | Available at below address Available at: http://mysqltuner.pl/ You can run the mysqltuner with perl (chmod to 755 and run or call with perl) and type in your administrative mysql user id/pass. mysqlmymon Available at: http://mysqlmymon.com/ Similar to mysqltuner, but lot more information about everything else too! This is mostly meant to serve as an all-in-one tool. MySQL Workbench http://www.mysql.com...ucts/workbench/ This is a GUI tool that helps you administer, diagnose and plan. (Complete) Monitoring Solutions Nagios (Everything - heavy learning curve) http://www.nagios.org/ Cacti (Network) http://www.cacti.net/ vnstat (Much more simple network usage logger) http://humdi.net/vnstat/ Useful to Know Settings MySQL settings | Only if you have mysql The settings are often found at: /etc/my.cnf Outputting your current information will help others identify problems. Apache/HTTPD settings | Only if you have apache The settings are often found at: /etc/httpd/conf.d/httpd.conf If you have WHM/cPanel, please look inside WHM instead. Outputting your current information will help others identify problems. Nginx Settings | Only if you have nginx The settings are often found at: /etc/nginx/nginx.conf Outputting your current information will help others identify problems. PHP Information (information regarding your current php build) | Available only to PHP users... for obvious reasons. To get full php information, there are 2 easy ways. One, make a php file with the below contents and save.

    <?php phpinfo(); ?> Or via shell

    php -i



    I'll add more if people suggest other tools.
×
×
  • Create New...