4 ms·

Seeing it from the point of view of a company with a few hundred Wordpress deployments: Definitely usability (if you want laypersons to be able to author conten

by creshal 11y ago

Seeing it from the point of view of a company with a few hundred Wordpress deployments: Definitely usability (if you want laypersons to be able to author content, there's little competition), largely availability of plugins, a bit ease of administration (it's getting better), but definitely not speed. Wordpress is so mindbogglingly slow that we have to use excessive amounts of caching for anything even remotely resembling medium traffic.

sbarre 11y ago
Honest question: do you not consider caching to be a normal part of a dynamic web application? I've never worked with a CMS or web app - in any language - that didn't include caching as a core part of the performance layer once it reaches a certain amount of load.. I'm sure it's possible, with enough money to throw at hardware, to scale without it, but why would you? Caching is a completely valid optimization approach in my view..
- mschuster91 11y ago
  Well Wordpress long came without any caching at all, dunno if that's changed by now. Drupal in contrast comes with its own DB caching. Both can be plugged into memcache and friends, and if done right you can put in Cloudflare or other frontend caching systems in front. Biggest performance +1, though, is enabling php opcache.
- creshal 11y ago
  > Honest question: do you not consider caching to be a normal part of a dynamic web application? We should not be needing bare metal servers with 4 GHz CPUs to serve a non-interactive site with ~4000 visitors a day. Yet, without full-page caching (i.e., bypass Wordpress/PHP entirely and serve .html files straight from nginx), the servers would melt under the load. Rendering twenty images and forty text fields out of database should not take several seconds on a modern server. Yet, Wordpress has no problems taking a dozen seconds even under light load conditions – mind you, that's time purely spent in PHP, for rendering, not on the database.
  - sbarre 11y ago
    Wow.. So I work with Wordpress on a day to day basis as well and we don't see anything like this.. We have pretty DB-heavy sites (lots of ACF Pro fields and lots of relationships) and we're handling bigger loads than that, on much smaller virtual hardware.. I'm not making any specific value statement about your setup here, I'm just surprised by what you're seeing on your end.
    - mschuster91 11y ago
      I guess it's a lack of opcache plus no SSD and no mysql tuning. Debian/Ubuntu defaults are not really nice. Sidenote: why doesn't the mysqld configure script suggest various performance levels upon setup, based on detected hardware (RAM, disk, CPU cores)?
      - creshal 11y ago
        Opcache is enabled, SSDs are in hardware raid and the whole time is spent inside PHP, MySQL finishes all queries after 0.02 seconds. The usual suspects are all dealt with.
    - creshal 11y ago
      It could just as well be our ACF+CPT fuckery that leads to this – I'm not that involved in the actual application side of things; I just provision the hardware and OS stack. Still, we're usually seeing a lot better performance with everything that's not wordpress – be it our in-house PHP framework, or node, Rails or Python apps.

by creshal 11y ago

sbarre 11y ago

Honest question: do you not consider caching to be a normal part of a dynamic web application? I've never worked with a CMS or web app - in any language - that didn't include caching as a core part of the performance layer once it reaches a certain amount of load.. I'm sure it's possible, with enough money to throw at hardware, to scale without it, but why would you? Caching is a completely valid optimization approach in my view..

mschuster91 11y ago
Well Wordpress long came without any caching at all, dunno if that's changed by now. Drupal in contrast comes with its own DB caching. Both can be plugged into memcache and friends, and if done right you can put in Cloudflare or other frontend caching systems in front. Biggest performance +1, though, is enabling php opcache.
creshal 11y ago
> Honest question: do you not consider caching to be a normal part of a dynamic web application? We should not be needing bare metal servers with 4 GHz CPUs to serve a non-interactive site with ~4000 visitors a day. Yet, without full-page caching (i.e., bypass Wordpress/PHP entirely and serve .html files straight from nginx), the servers would melt under the load. Rendering twenty images and forty text fields out of database should not take several seconds on a modern server. Yet, Wordpress has no problems taking a dozen seconds even under light load conditions – mind you, that's time purely spent in PHP, for rendering, not on the database.
- sbarre 11y ago
  Wow.. So I work with Wordpress on a day to day basis as well and we don't see anything like this.. We have pretty DB-heavy sites (lots of ACF Pro fields and lots of relationships) and we're handling bigger loads than that, on much smaller virtual hardware.. I'm not making any specific value statement about your setup here, I'm just surprised by what you're seeing on your end.
  - mschuster91 11y ago
    I guess it's a lack of opcache plus no SSD and no mysql tuning. Debian/Ubuntu defaults are not really nice. Sidenote: why doesn't the mysqld configure script suggest various performance levels upon setup, based on detected hardware (RAM, disk, CPU cores)?
    - creshal 11y ago
      Opcache is enabled, SSDs are in hardware raid and the whole time is spent inside PHP, MySQL finishes all queries after 0.02 seconds. The usual suspects are all dealt with.
  - creshal 11y ago
    It could just as well be our ACF+CPT fuckery that leads to this – I'm not that involved in the actual application side of things; I just provision the hardware and OS stack. Still, we're usually seeing a lot better performance with everything that's not wordpress – be it our in-house PHP framework, or node, Rails or Python apps.