Jump to content

Processwire performance, serverload and server settings


recyclerobot
 Share

Recommended Posts

Hi everyone,

let me first start off by expressing how much I love Processwire, I've succesfully integrated it with about 8 sites now and I'm just so in love with the simplicity (we love you ryan :D)

I was wondering how processwire scores on the performance/serverload front, how much processwires can I run on my VM with how much ram and are there any recommoned server apache settings?

currently I'm running an ubuntu with 4GB ram and 3 cores (1,6Ghz each),

I'm using php 5.1 with mod_cgi and the 8 processwire sites use about 1,6GB of RAM, having about 50k visitors/month across these sites I'm wondering how processwire will perform in case of 100k - 200k - 500k - 1M visitors, will the session system last (I noticed it's writing a cached file to the filesystem)?

also: what's the limit with the "new Page();" command, is it creating a new directory for every created page, what's the limit (the filesystem? the amout of ram?)

Link to comment
Share on other sites

Good questions RecycleRobot. This is really is going to vary from environment to environment, so my recommendations would be more general. Though awhile back Soma reported that some of his colleagues had run a stresstest called a "proxy sniffer load curves report", and the report came back quite good. But I don't know what all that entailed.

I recommend giving it 128M memory (the PHP 5.3 default) or more, in your php.ini. If you need to deal with lots of traffic, it's a good idea for your server to have a PHP opcode cache like APC or eAccelerator.

Beyond the server configuration, other performance factors depend on how you use ProcessWire. If you are doing anything heavyweight with the API towards markup generation, or just need to handle lots of traffic, it's a good idea to make use of PW's various caching options. From the template settings, you can tell it to use a cache from the 'cache' tab. Choose settings that maximize the lifetime of the cache, clearing only what you need to cleared when a page is saved. You'll also want to get familiar with the MarkupCache module, which enables you to cache individual pieces of markup in your templates. This is really handy for caching markup that may be expensive to build on every request, like larger navigation trees... or anything you want.

You'll also want to look at these best practices for long term scalability, as well as the field autojoin option. If you need to work with a lot of pages in memory at once during the same request, the $pages->uncacheAll(); function can clear memory when you need it (at the expense of having to reload any pages you try to access again).

also: what's the limit with the "new Page();" command, is it creating a new directory for every created page, what's the limit (the filesystem? the amout of ram?)

How much memory a Page takes up depends entirely upon how many fields it has and how many are loaded/populated. ProcessWire generally tries to keep Page objects as lightweight as possible, and doesn't load fields until you actually access them. As a result, you could feasibly get thousands of pages in memory if all they had were short 'title' fields. But you might only get a few hundred if those pages have their fields loaded and all in memory at once.

PW does create a new directory for each page at present. That behavior will become on-demand in the near future. But at present, this would mean your maximum quantity of pages (at least, pages that can also store files) could be limited by the file system and any hard limits present there.

I'm using php 5.1 with mod_cgi

ProcessWire is not compatible with PHP 5.1. If you are running it, I'm not sure how because 5.1 lacks some things that PW depends on. I'm guessing 5.1 was a typo, but if not, let us know as I may have missed something. I recommend running PHP 5.3 if possible to maximize performance. Also, I may be wrong about this, but I had thought that there was some overhead with running PHP as a CGI as opposed to running it as a module. If that's still the case (?), you may benefit from running PHP as an Apache module, but I'm out of area of knowledge on this one. :)

  • Like 2
Link to comment
Share on other sites

Hi Ryan,

Thanks for your answer, php 5.1 was a typo, I'm using 5.3.2 :)

I've done some tests running processwire as mod_cgi and running processwire as mod apache, both running a bare bone github install (main repo from today) and called a execution time and you're right: mod_cgi is a tiny tiny bit faster but uses alot more RAM while doing so (after 1000 refreshes, mod_cgi spiked at almost 300Mb in cycle, while mod_apache stayed at a steady 68Mb)

runtimes (after 1000 calls)

mod_cgi:
page runtime: 0.0476528 sec
mod apache:
page runtime: 0.0479234 sec

so I'm switching my server to mod apache, and looking into APC :)

Love your markupCache, I've been succcessfully using it on 2 projects now (caching large header elements)

Looking forward to the new Page > write to filesystem or not :)

again, thanks for everything!

  • Like 1
Link to comment
Share on other sites

Thanks for the testing and followup recyclerobot. Interesting about mod_cgi using up all that memory relative to mod_apache. Most servers I work on actually don't have an opcode cache, but I think it's a good thing to have for any PHP app that needs to handle large volumes of traffic. I'm running eAccelerator on this server, though don't think we needed it, but figured it can't hurt.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...