Search the Community

Hello, I am loving using _init.php to set stuff up and keep some constant info DRY. However I think I ran into a situation while I was working with Form Builder where I was (legally/sensibly) editing a file the Module uses to send emails and cheerfully went about referring to a var that I knew I had established in _init.php only to find it was not being found. I quickly realized this was because the file in question was not a regular PW Template file (but a Form Builder support file). But it left me wondering which is the best approach for globally defining vars: set them all in config.php so I am guaranteed that from *any* file I can access them by `wire("config")->myVar` set them all in _init.php and for those I can't access in rare cases like Form Builder files do something special like for those vars define them in config.php and have _init.php set a var so all normal Templates can access the same way set them all in config.php then in _init.php read them all from config.php and re-declare them as named vars (i.e. same as 2. but for all vars not just those that are needed by non-Template files)? I'm leaning toward 3. but any thoughts (particularly to do with not wanting to inadvertently bog down PW by doing something silly) would be most appreciated.

I have activated the Cache module and then configured the cache in Setup -> Templates -> Cache, where I have set the expiration to 3600 seconds for all my templates. When I run ApacheBench to stress the server, I am seeing exceptionally high load. My throughput is only ~10 requests/s despite the page being cached, and I can see high MySQL traffic, even though cache is supposedly activated. Is this expected behaviour? Are there any high-performance cache options available? (That preferrably don't query the DB at all when a cached page is requested.)

We encountered a performance problem with a custom search today, finding out that one particular database query lasted seconds. Digging deeper revealed it has to do with repeaters when there are enough of them. The site has pages for companies (about 1500 of them) each of which has repeater items attached. Most of them have one single item, total amount of repeater items being under 2000. This leads to about 3500 extra pages in the tree as a penalty for using repeaters (yes, there would have been other possible approaches as well). So, the amount of pages isn't anything massive. Now, when a find("parent=/companies/, title%=keyword") is executed, the repeater fieldtype catches the use of title field (used in the repeaters as well) and tries to ensure no repeater pages get returned by adding !has_parent=<repeaters-page-id> to the selector string. While this is logically right, the resulting SQL query becomes slow due to the extra join used to filter out repeater pages. With those 1500 + 1500 + 2000 = 5000 pages there are about 9000 rows in the pages_parents table (which is used for implementing has_parent selector). This isn't that much either, but it becomes a problem when there's a join between pages and pages_parents. I'm not saying it wouldn't be possible to optimize the query, but as I'm not certainly skilled enough to do it, I went down another road. And the solution is dead simple - actually it's possible to catch it by just looking at those bolded selector strings above . Ready? Ok, if we're searching for pages whose parent is /companies/ why should pages under /processwire/repeaters/ be explicitly filtered out? There's no way they'll match, so we'll just skip the extra repeater filter. And if you we're actually trying to find pages under /processwire/repeaters/ you didn't want the filter to kick in either (well, don't do that anyways, they're internals). Here's a little diff showing the change I made to fix this thing for us (there's a pull request on the way Ryan): $ git diff diff --git a/wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module b/wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module index 20bb52c..ab9db28 100644 --- a/wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module +++ b/wire/modules/Fieldtype/FieldtypeRepeater/FieldtypeRepeater.module @@ -138,6 +138,10 @@ class FieldtypeRepeater extends Fieldtype implements ConfigurableModule { // ensure that the repeaters own queries work since they specify a templates_id if($name == 'templates_id' && in_array($selector->value, $templatesUsedByRepeaters)) $includeAll = true; + // optimization: if parent (or parent_id) is given, there's no need to explicitly exclude repeaters + // TODO: has_parent with values other than parents of repeaters-page could be catched as well + if($name == 'parent' || $name == 'parent_id') $includeAll = true; + if($includeAll) break; } } Another performance issue solved. Not a very common one I think, but still worth a fix. Edit: Ryan, no pull request this time. Didn't manage to do it right. Next time there'll be a branch before any changes, maybe that'll do it.

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 ) 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?)