Live data from Hacker News

Performance and Speed Optimizations of WordPress [pdf]

lamosty.com

21–25 of 25 posts

Re: Performance and Speed Optimizations of WordPress [pdf]

#21
post #6
post #5

WordPress is slow by design! I have managed to create a blogging engine (in PHP) that it only takes 2ms to create the page dynamically (without caching) from the database + ~20ms for Nginx to serve it. One might argue that my engine does not have as much features... and you are right. Incase you are interested: SunSed.com

WordPress is rather big, having more than 200K function calls on a typical request to a blog post. However, when using the default Twenty Fifteen theme, the performance is not that bad, as you can see from http://ldr.io/1cbbomp (VPS server with 3CPUs and 4GB of RAM). I've just checked your blogging engine and it looks very minimalistic. I like it.

Thank you! Yes you are right! WordPress is huge! but not everyone need all the functionality... let's just say 10% of current WordPress users just need a simple blogging platform without all the widgets... then I think 1K function calls should be enough!

Anyway, I love WordPress and do not compare my hubby project with 10 years of 1000+ developers time!

Re: Performance and Speed Optimizations of WordPress [pdf]

#22
post #5

WordPress is slow by design! I have managed to create a blogging engine (in PHP) that it only takes 2ms to create the page dynamically (without caching) from the database + ~20ms for Nginx to serve it. One might argue that my engine does not have as much features... and you are right. Incase you are interested: SunSed.com

It's a bit like saying "I've done something completely different and it's much faster". Anyway, sunsed looks cool.

You are right! Thank you for the complement!

Re: Performance and Speed Optimizations of WordPress [pdf]

#23
post #19

Earlier quoted context omitted.

templates are mostly not the problem, even on python, when you use jinja templates getting generated really fast. However the problem mostly comes through the database. A single page view could hit like 10 queries.

Yeah. Avoid the database, just read from RAM :)

That's it the main bottleneck is Database calls!

Re: Performance and Speed Optimizations of WordPress [pdf]

#24
post #18

Earlier quoted context omitted.

It wasn't that configuring opcode caches is complicated or difficult. It's that they locked up every few days, no matter which one I used or how I configured them. At the point where I wrote a cron script to kill PHP every 24 hours, I realised the extra few percent weren't worth it. Maybe it's improved, but: four times bitten, twice shy. > Nginx stores the pages in RAM in a tree-like structure with pretty fast access…

> Maybe it's improved, but: four times bitten, twice shy. I see, happens all the time. > On disk caching delegates this to the OS, which is pretty good at it. Yeah, it's just a matter of preference and convenience. > It seems as though very few plugin authors know what O-notation means (so many nested loops), what EXPLAIN QUERY is or that tinkering and and firing up a copy on your laptop isn't really testing. This is…

Well in the old days, the operating system was there to help you. If plugins were standalone processes, they could be resource-constrained. But they all have to run in-process because of the LAMP architecture.

Hence -- cooperative multitasking.

I've been complaining about it for years. Eg: http://clubtroppo.com.au/2008/07/10/shared-hosting-is-doomed...

Re: Performance and Speed Optimizations of WordPress [pdf]

#25
post #18

Earlier quoted context omitted.

> Maybe it's improved, but: four times bitten, twice shy. I see, happens all the time. > On disk caching delegates this to the OS, which is pretty good at it. Yeah, it's just a matter of preference and convenience. > It seems as though very few plugin authors know what O-notation means (so many nested loops), what EXPLAIN QUERY is or that tinkering and and firing up a copy on your laptop isn't really testing. This is…

Well in the old days, the operating system was there to help you. If plugins were standalone processes, they could be resource-constrained. But they all have to run in-process because of the LAMP architecture. Hence -- cooperative multitasking. I've been complaining about it for years. Eg: http://clubtroppo.com.au/2008/07/10/shared-hosting-is-doomed...

Thanks for the article, it's insightful and I & history agree completely with you. Nowadays, people are using prebuilt VPS images or automation scripts to provision their servers and shared hostings are becoming more of a VPS hostings with a good UI around these tools.

I see that you are a WordPress veteran, nice to hear your opinions :)

Post reply on HN