• Resolved Hubert Nguyen

    (@hubertnguyen)


    Hello,

    I have a question for the W3 Total Cache (W3TC) community out there: what is considered as “good” performance for a site using W3TC?

    I get between 0.3 seconds to 1.3 seconds for a page creation. I have yet to try more settings combinations, but I’m curious to know how fast your setup gets.

    Let me know, I’m sure that a lot of webmasters are curious. Thanks!

    https://www.ads-software.com/extend/plugins/w3-total-cache/

Viewing 6 replies - 16 through 21 (of 21 total)
  • Because they are based on WP data, they would normally be taxing the system every time they appear in the templates, even if the data itself would change only once a day or week. Even if you cache the DB queries, it seems much slower than saving those block of data to the disk with a cron and use a phpinclude. Am I being too paranoid?

    This would be a perfect case for using WordPress’s built in Transient API

    Transients are small pieces of data that you set to expire. WordPress will cache the data in MySQL. If you have Memcached and Memcached server installed WordPress will serve the data directly from memory. It wouldn’t help any if you were serving a cached page but it would help for logged in users.

    Plugin Contributor Frederick Townes

    (@fredericktownes)

    The only reason transients are not always a fit is because a database call is slower than checking the disk even when comparing mysql’s query cache to the operating systems memory cache for frequently accessed files. Instead it would be better if the Object Cache API was used for widgets so that the behavior of the cached objects could be predictable and transparently supported by W3TC and the supported caching engines.

    Anyway, fragment caching in W3TC or WPSC currently uses a different policy, where everything is cached except the things that need to be executed each page view. The policy for caching the output of those objects and using that cache file to build templates until they’ve expired is not logic I’ve implemented yet.

    Thread Starter Hubert Nguyen

    (@hubertnguyen)

    @c3mdigital: I’m new to WP and did not know about this. Thanks for pointing out.

    @frederick: yes, I’d rather check the disk if possible.

    Plugin Contributor Frederick Townes

    (@fredericktownes)

    Ok.

    Hi, to enter the fairly old posting here.
    I had very bad results running on my VPS. Foir the initial base test, before starting caching.

    Failed requests 9 out of ten.

    And all so slow.

    Is there anything which should be adjusted, before starting to use caching?
    The AB test:

    [Test results moderated as per the Forum Rules. Please use the pastebin]

    But now, when I have the plugin Total Cache installed and save the cache to disk.
    I have better results.

    Server Software:        Apache
    Server Hostname:        www.zukunftszone.de
    Server Port:            80
    
    Document Path:          /
    Document Length:        55177 bytes
    
    Concurrency Level:      2
    Time taken for tests:   1.28341 seconds
    Complete requests:      10
    Failed requests:        1
       (Connect: 0, Length: 1, Exceptions: 0)
    Write errors:           0
    Total transferred:      556269 bytes
    HTML transferred:       551787 bytes
    Requests per second:    9.72 [#/sec] (mean)
    Time per request:       205.668 [ms] (mean)
    Time per request:       102.834 [ms] (mean, across all concurrent requests)
    Transfer rate:          528.03 [Kbytes/sec] received
    
    Connection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:        0    0   0.0      0       0
    Processing:     1  198 416.5      1    1028
    Waiting:        1  189 396.9      1     975
    Total:          1  198 416.5      1    1028
    
    Percentage of the requests served within a certain time (ms)
      50%      1
      66%      1
      75%      2
      80%    948
      90%   1028
      95%   1028
      98%   1028
      99%   1028
     100%   1028 (longest request)

    Now my questions:
    I have memcached installed and it gives out this result with everycache run through memcache:

    Server Software:        Apache
    Server Hostname:        www.zukunftszone.de
    Server Port:            80
    
    Document Path:          /
    Document Length:        55316 bytes
    
    Concurrency Level:      2
    Time taken for tests:   1.943700 seconds
    Complete requests:      10
    Failed requests:        9
       (Connect: 0, Length: 9, Exceptions: 0)
    Write errors:           0
    Total transferred:      555391 bytes
    HTML transferred:       551189 bytes
    Requests per second:    5.14 [#/sec] (mean)
    Time per request:       388.740 [ms] (mean)
    Time per request:       194.370 [ms] (mean, across all concurrent requests)
    Transfer rate:          278.85 [Kbytes/sec] received
    
    Connection Times (ms)
                  min  mean[+/-sd] median   max
    Connect:        0    0   0.0      0       0
    Processing:    19  387 773.7     20    1856
    Waiting:       18  378 756.2     19    1813
    Total:         19  387 773.7     20    1856
    
    Percentage of the requests served within a certain time (ms)
      50%     20
      66%     21
      75%     26
      80%   1855
      90%   1856
      95%   1856
      98%   1856
      99%   1856
     100%   1856 (longest request)

    Might it be, that my memcache is not correctly configured?
    Or isnt it mandatory, that the memcached cache will be better then to disc?

    My memcache config output by server info:
    memcache

    memcache support enabled
    Active persistent connections 0
    Revision $Revision: 1.80 $

    Directive Local Value Master Value
    memcache.allow_failover 1 1
    memcache.chunk_size 8192 8192
    memcache.default_port 11211 11211
    memcache.max_failover_attempts 20 20

    I have the feeling I did anything wrong, while I didnt configure memcache.

Viewing 6 replies - 16 through 21 (of 21 total)
  • The topic ‘W3 Total Cache: what is considered to be “good” performance?’ is closed to new replies.