WordPress.org

Ready to get started?Download WordPress

Forums

WordPress Slow Performance (Shared Hosting) (8 posts)

  1. aberglas
    Member
    Posted 1 year ago #

    Hello All,

    WordPress is taking between 1.5 and 10 seconds to render pages on a shared host. A little application that I had written always runs blindingly fast. The problem seems to be the vast amount of .php code that needs to be loaded and parsed/compiled for each an every request.

    The host runs suPhp, like most shared hosts, which means no code cache. Timings below sugest that the host is well resourced.

    I am thinking of writing a microWordpress which just contains the bits I need to integrate my form application with WP. That would be wpdb, basic user/capability loading, and a crude template. It would be small, and thus fast. Has anyone already done this?

    These are my timings:-

    SLOW: Total Time used 7.94470310211 load 6.05444192886 wp 0.00354599952698 template 0.325224161148 burn 1.56150388718

    FAST: Total Time used 1.72696900368 load 0.174858093262 wp 0.00763082504272 template 0.0830750465393 burn 1.46141815186

    Total time is real time in seconds on the server, add a second or so to see in the client.

    "load" is the time wp takes to read and parse all of its .php files -- (wp-load.php). I'm pretty sure nothing else much happens here.

    "wp' and "template" is the time wp takes to think about and render.

    "burn" is the real time that it takes a tight loop of 20,000,000 iterations to execute. (PHP is slow!)

    First you will note the variance in total time, from slugish (1.7 seconds) to Slow (7.9 seconds).

    The burn time does not vary very much. That suggests that there is plenty of CPU, and the CPU is also about as powerful as my local one.

    The big time difference is the load time. Run twice in a row and it is normally fast, but wait a few seconds between runs and it is very slow.

    There are two possible explanations. One is that all the .php files would normally be cached in *nix's kernal memory disk cache. But wait a bit and they will fall out. Reading files from cache is very fast.

    The second is that the PHP process is in fact being reused by Apache in some way, and is caching the compiled op codes. Parsing all that code in just 170 ms (fast time) seems too fast to me.

    For the first either kernal parameters or just more memory would keep the cached files in memory longer. For the second, if true, some Apache tweaking may help. Not my area, but is there some time to live while idle parameter for spawned processes?

    Certainly, my raw forms (outside the /wp) always run blindingly fast, and 8 seconds is unnacceptably slow.

    This must be a common issue with WP. Even just concatenating all the .php files into one big one might help, but I have not tried that.

    Ideas?

  2. aberglas
    Member
    Posted 1 year ago #

    If anyone has experience linking form applications to just the core WordPress libraries please let me know. The current performance overhead of loading all of WordPress's code is unacceptable.

  3. bcworkz
    Member
    Posted 1 year ago #

    If you define the constant SHORTINIT as true before your page requires wp-load.php, the template and theme stuff is not loaded, but still enabling core functionality. Not sure how much time it saves, but it's gotta help if you don't need theme and template stuff.

    BTW, I don't think combining files will help much and would be a big headache. I believe most of the time is spent parsing the endless lines of code, not the multiple file access times.

  4. yakbrother
    Member
    Posted 1 year ago #

    Have you looked into using Cloudflare? It's a free semi-CDN. I use that with W3 Total Cache and it definitely sped things up.

  5. aberglas
    Member
    Posted 1 year ago #

    I'm 95% certain that the problem is the time it takes to read the files, rather than the time it takes to parse them, which is surprising. That's because the load gets much slower when the system has been left idle for a few minutes, so gone out of cache. And my Burn Cpu test always runs about the same speed, so plenty of CPU available.

    So I tried combining all the 30 odd core files in wp-settings into a single file, which came to 1.6 meg of source. The theory is that the O/S will try to put this contingously on disk and so be faster to load. Experiments showed no real improvement.

    I did see SHORTINIT in the code, thanks. It would be faster, and may be a part of my solution.

    Have not looked at Cloudflare etc. Should not need to. Simple Php programs run blindingly fast, it is just the frameworks that kill it.

    The problem is Php and WordPress's bad architecture. To have to load all that code every time a page is touched. (This will not be an issue on WordPress.org because it all runs from the same code base which will always be in cache.)

    I have nw discoverd, too late, the importance of useing a small package if using PHP on a shared host. There are a couple of simple non-database solutions that might have done. But not changing now!

  6. aberglas
    Member
    Posted 1 year ago #

    One final test, I copied my agregate .php file and made the comment into one huge comment (/*...*/). When cached, the comment reads 0.03 vs 0.21 for the code, the difference would be the teim to parse. When not cached, they both take about the same -- 1.7 when the machine is unloaded (more if it is busy).

    So the time is not parsing. It is reading the disk.

  7. Noisie
    Member
    Posted 1 year ago #

    I would look for a bit more expensive CDN host. WordPress can be really slow on some hosting company's.

  8. bcworkz
    Member
    Posted 1 year ago #

    So the time is not parsing. It is reading the disk.

    Now that I actually think about it instead of just typing random thoughts, this makes sense. Thanks for setting me straight. I really need to think more before typing :)

Topic Closed

This topic has been closed to new replies.

About this Topic

Tags

No tags yet.