WordPress.org

Ready to get started?Download WordPress

Forums

[Plugin: DB Cache] Queries are reduced but load time is not (13 posts)

  1. binaryeric
    Member
    Posted 5 years ago #

    The reduction in sql queries is impressive, but the load time actually increases in my case.

    SQL Queries Time
    Before After Before After
    Home 67 2 1.237s 1.482s
    Page1 29 2 0.5s 1.035s
    Page2 61 3 0.594s 1.259s
    Page3 31 2 1.477s 1.968s

  2. sclough
    Member
    Posted 5 years ago #

    This is one question I had about the plugin. Has anybody done some load testing with it? I like the theory behind it and I'm using it on two blogs without any problems. However, I haven't really spent a lot of time in the code and depending on how the queries are being cached, it may be possible that the cpu overhead of parsing the cache is equal to the i/o overhead of calling the database if you are dealing with small queries. I'd be interested to get some input from others on this. I do think db-cache is the best caching approach overall.

  3. Posterd
    Member
    Posted 5 years ago #

    it uses serialize/unserialize and fwrite/fread to operate with cache.

    i wrote this plugin special for one of my sites with much widgets that needed always actual information to be displayed. so with this plugin i've got 160 -> 2 queries and 4 second -> 0.5 seconds.

    at the moment i'm checking work of plugin with different plugins. possibly increasing of genereation time is because of not supporting one of plugins. so solving problems. hope that it will be fine on every instalation of wordpress soon

  4. stevemagruder
    Member
    Posted 5 years ago #

    I think the point of this kind of caching is dealing with moments of very heavy site traffic. Even if load times are slightly increased for normal traffic periods, these kinds of load times are preferable to the load times you would see if your site was Digg'd (or equivalent) and a plugin like this wasn't installed.

  5. sclough
    Member
    Posted 5 years ago #

    True, but what I was saying is it would be helpful to measure the cpu load of serializing and unserializing the query results. If it takes more cpu to perform that i/o than it does to query and parse the database results, then under load you still really wouldn't have a benefit and would still need something like super cache to survive a digg hit.

    I like the plugin, we just need someone to do some load testing to see how it performs under full load. I'm going to try if I get some time, but I'm certainly not an expert at it.

  6. Posterd
    Member
    Posted 5 years ago #

    Please wait till the evening - it will be new version of plugin - 0.6

  7. sclough
    Member
    Posted 5 years ago #

    Ok, I'll watch for the new version and try to do some really basic testing using ab.

  8. Rishi
    Member
    Posted 5 years ago #

    I'm really excited to see where this plugin goes in terms of optimization! I think the problem most of us have had using Super Cache has been its inability to deliver dynamic content (unless it's Javascript or some hooks are implemented). Using DBCache along with WP Widget Cache, I see great things for my site ( http://rk.md ) in terms of optimization. =)

  9. sclough
    Member
    Posted 5 years ago #

    Ok, I did some basic benchmarking. Keep in mind this is on a vps that doesn't have much power, but it suitable for a few low volume sites. I'd be curious to see where the numbers went on a machine with a lot more cpu and more memory. If I have time, I'll benchmark the site on my laptop and see what the numbers there are.

    My method:
    I ran the benchmark's twice. I first ran the site with no caching. Then I ran the site with db-cache involved. Then, just to get a comparison with one of the other caching techniques, I ran it with hyper cache. Apache was restarted between each run to clean out it's memory and worker processes. I also "primed the cache" between each run by navigating to a few pages.

    The summary is that db-cache 0.6 is better than no cache, but still trails hyper cache by a wide margin. Again, I'd be curious to see if the gap narrows on a machine with a lot of cpu. Db cache is being slowed down because it still has to execute the php scripts and serialize and deseriaze the data whereas hyper cache is basically serving pages without a database hit. I'm not being negative about db cache, just trying to account for the difference. It might be good to see if there is a way to optimize the saving and loading of queries. That might be a place for optimization. Having all the php scripts execute each time though is going to make it hard to match caching techniques that serve a written page like hyper or super cache (which obviously have their own downsides as well). I'm not being negative, I just think you have to be honest that db cache is never going to match the speed of something like super cache because of the php code that's still running. Still, db cache could be a good alternative for people that don't want the complexity of super cache.

    For the curious, here's the details:
    ******* No cache - first run:
    This is ApacheBench, Version 2.3 <$Revision: 655654 $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/

    Benchmarking http://www.samuelclough.com (be patient)
    Finished 108 requests

    Server Software: Apache/2.0.55
    Server Hostname: http://www.samuelclough.com
    Server Port: 80

    Document Path: /
    Document Length: 109441 bytes

    Concurrency Level: 10
    Time taken for tests: 30.468 seconds
    Complete requests: 108
    Failed requests: 0
    Write errors: 0
    Total transferred: 12433486 bytes
    HTML transferred: 12402598 bytes
    Requests per second: 3.54 [#/sec] (mean)
    Time per request: 2821.149 [ms] (mean)
    Time per request: 282.115 [ms] (mean, across all concurrent requests)
    Transfer rate: 398.51 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 34 59 44.1 45 321
    Processing: 797 2535 1294.5 2377 7395
    Waiting: 138 557 378.2 438 2338
    Total: 838 2594 1297.6 2416 7435

    Percentage of the requests served within a certain time (ms)
    50% 2416
    66% 2888
    75% 3102
    80% 3432
    90% 4356
    95% 5378
    98% 6016
    99% 6186
    100% 7435 (longest request)

    ******** No cache - second run:
    This is ApacheBench, Version 2.3 <$Revision: 655654 $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/

    Benchmarking http://www.samuelclough.com (be patient)
    Finished 129 requests

    Server Software: Apache/2.0.55
    Server Hostname: http://www.samuelclough.com
    Server Port: 80

    Document Path: /
    Document Length: 109441 bytes

    Concurrency Level: 10
    Time taken for tests: 30.168 seconds
    Complete requests: 129
    Failed requests: 0
    Write errors: 0
    Total transferred: 14707789 bytes
    HTML transferred: 14671357 bytes
    Requests per second: 4.28 [#/sec] (mean)
    Time per request: 2338.594 [ms] (mean)
    Time per request: 233.859 [ms] (mean, across all concurrent requests)
    Transfer rate: 476.11 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 35 47 13.8 44 181
    Processing: 663 2182 1641.6 1758 15478
    Waiting: 136 625 636.5 446 5012
    Total: 707 2229 1643.3 1804 15522

    Percentage of the requests served within a certain time (ms)
    50% 1772
    66% 2157
    75% 2564
    80% 2902
    90% 4266
    95% 4846
    98% 5059
    99% 6815
    100% 15522 (longest request)

    ********** db cache - first run:
    This is ApacheBench, Version 2.3 <$Revision: 655654 $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/

    Benchmarking http://www.samuelclough.com (be patient)
    Finished 159 requests

    Server Software: Apache/2.0.55
    Server Hostname: http://www.samuelclough.com
    Server Port: 80

    Document Path: /
    Document Length: 109577 bytes

    Concurrency Level: 10
    Time taken for tests: 30.286 seconds
    Complete requests: 159
    Failed requests: 0
    Write errors: 0
    Total transferred: 17969959 bytes
    HTML transferred: 17925607 bytes
    Requests per second: 5.25 [#/sec] (mean)
    Time per request: 1904.792 [ms] (mean)
    Time per request: 190.479 [ms] (mean, across all concurrent requests)
    Transfer rate: 579.43 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 35 53 35.0 44 318
    Processing: 685 1762 1069.8 1415 6025
    Waiting: 130 412 322.1 270 1827
    Total: 725 1815 1069.3 1462 6069

    Percentage of the requests served within a certain time (ms)
    50% 1446
    66% 1965
    75% 2210
    80% 2393
    90% 3463
    95% 3886
    98% 5333
    99% 5560
    100% 6069 (longest request)

    ********** db cache - second run:
    This is ApacheBench, Version 2.3 <$Revision: 655654 $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/

    Benchmarking http://www.samuelclough.com (be patient)
    Finished 174 requests

    Server Software: Apache/2.0.55
    Server Hostname: http://www.samuelclough.com
    Server Port: 80

    Document Path: /
    Document Length: 109577 bytes

    Concurrency Level: 10
    Time taken for tests: 30.068 seconds
    Complete requests: 174
    Failed requests: 0
    Write errors: 0
    Total transferred: 19443356 bytes
    HTML transferred: 19395836 bytes
    Requests per second: 5.79 [#/sec] (mean)
    Time per request: 1728.065 [ms] (mean)
    Time per request: 172.807 [ms] (mean, across all concurrent requests)
    Transfer rate: 631.48 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 35 49 70.3 42 967
    Processing: 667 1636 729.2 1508 4247
    Waiting: 127 401 234.3 352 1248
    Total: 746 1686 727.6 1570 4286

    Percentage of the requests served within a certain time (ms)
    50% 1570
    66% 1806
    75% 2023
    80% 2222
    90% 2710
    95% 3291
    98% 3730
    99% 3919
    100% 4286 (longest request)

    ************ hyper cache - first run:
    This is ApacheBench, Version 2.3 <$Revision: 655654 $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/

    Benchmarking http://www.samuelclough.com (be patient)
    Finished 302 requests

    Server Software: Apache/2.0.55
    Server Hostname: http://www.samuelclough.com
    Server Port: 80

    Document Path: /
    Document Length: 107579 bytes

    Concurrency Level: 10
    Time taken for tests: 30.038 seconds
    Complete requests: 302
    Failed requests: 0
    Write errors: 0
    Total transferred: 32768332 bytes
    HTML transferred: 32702922 bytes
    Requests per second: 10.05 [#/sec] (mean)
    Time per request: 994.629 [ms] (mean)
    Time per request: 99.463 [ms] (mean, across all concurrent requests)
    Transfer rate: 1065.34 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 38 126 113.9 105 1133
    Processing: 389 844 225.6 809 2246
    Waiting: 39 121 118.4 98 1197
    Total: 430 970 239.6 930 2289

    Percentage of the requests served within a certain time (ms)
    50% 930
    66% 974
    75% 998
    80% 1024
    90% 1195
    95% 1381
    98% 1804
    99% 1941
    100% 2289 (longest request)

    ************** hyper cache - second run:
    This is ApacheBench, Version 2.3 <$Revision: 655654 $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/

    Benchmarking http://www.samuelclough.com (be patient)
    Finished 298 requests

    Server Software: Apache/2.0.55
    Server Hostname: http://www.samuelclough.com
    Server Port: 80

    Document Path: /
    Document Length: 107579 bytes

    Concurrency Level: 10
    Time taken for tests: 30.075 seconds
    Complete requests: 298
    Failed requests: 0
    Write errors: 0
    Total transferred: 32393644 bytes
    HTML transferred: 32329289 bytes
    Requests per second: 9.91 [#/sec] (mean)
    Time per request: 1009.228 [ms] (mean)
    Time per request: 100.923 [ms] (mean, across all concurrent requests)
    Transfer rate: 1051.85 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 40 120 135.0 91 1164
    Processing: 508 862 214.8 806 1867
    Waiting: 40 122 110.1 95 936
    Total: 606 982 269.7 889 2362

    Percentage of the requests served within a certain time (ms)
    50% 889
    66% 958
    75% 1074
    80% 1188
    90% 1372
    95% 1503
    98% 1857
    99% 1942
    100% 2362 (longest request)

  10. deambulando
    Member
    Posted 5 years ago #

    the results are amazing, my blog performace is better than with wp-cache, and easier to mantain, excellent idea and work

  11. fher98
    Member
    Posted 5 years ago #

    Ok guys, I have a question. I undestand that hypercache and dbcache are tow different ways of fixinf the same issue.

    My question, can/should they be use together? or it will be like double effort to use them both?

    thanks

  12. ricardobeat
    Member
    Posted 5 years ago #

    I'm using DB Cache and Hypercache together. Hypercache creates static HTMLs, so all that DB cache will do is accelerate the page creation when the cached one has expired. Shouldn't be necessary unless it's a heavy load site. I'm not sure I'll keep both, as DB-cache is not having much of an impact on loading times (just 3s to 2s, around 100 queries).

  13. Pinoy.ca
    Member
    Posted 4 years ago #

    it may be possible that the cpu overhead of parsing the cache is equal to the i/o overhead of calling the database if you are dealing with small queries. I'd be interested to get some input from others on this.

    This is seen very easily with a define('SAVEQUERIES', true); (as per http://codex.wordpress.org/Editing_wp-config.php#Save_queries_for_analysis ) and a simple hack on db-module.php (and also to the copy in /wp-content/db.php). Add the following somewhere near line 720:

    if ( defined('SAVEQUERIES') && SAVEQUERIES )
    	$this->queries[] = array( $query, $this->timer_stop(), $this->get_caller(), "Cache hit" );

    (Posterd, you may like to commit this hack to your code.)

    Then load a page in two browser windows, one minute apart.

    It will be evident that DB Cache shaves milliseconds on some queries such as queries with JOINs.

Topic Closed

This topic has been closed to new replies.

About this Topic

Tags