PW 2.5.3 very slow while saving

[bbeer]

I have severe problems on saving speed in a big PW page. We use close to 150 fields in the template, being that slow. When saving a document it can take up to 6 to 10 seconds to save. It happens quite often that CPU usage gets to the limit.

the page is hosted on a sharedHosting Account on a Linux Box.

Is there a possibility to speed put this process? 

Your help is much appreciated.

[WillyC]

150 felds ¿ mabe u sholud try.profelds

wat felds.types u use ¿ repetitors.or what

can postes screenshit.of tamplate sceen w.felds ¿

[3fingers]

can postes screenshit.of tamplate

 [OT ]     [/OT]

[bbeer]

OK here are the Screenshots.

I have my doubts that this is a project for repeater. however every good tip is welcome. 

[LostKobrakai]

One thing you could do is split all those tabs in different templates and use them in subpages. You could include them in a PageTable on this current page to allow easy access to all the subparts of the page. This would also allow you to reuse editor/image fields, when they are no more used in the same template.

Off Topic:

That's some piece of german engineering information

[ryan]

@bbeer that is a lot of fields to have in one template. I also see that it's not just a lot of fields, but most of them are also multi-language, which takes your quantity of fields and multiplies that by the number of languages (4 in your case). Plus take your quantity of individual files and multiply that by 4 as well. It's possible you could be hitting 800+ inputs here. 

While I don't think this quantity of fields is necessarily a problem, I do think that you should expect some overhead in trying to render and save that many fields at once. It's not just going to be server side, as that's a lot of markup for your browser to process, and a lot of DOM elements for the Javascript client side as well. So you will likely see both server-side and client-side overhead at this scale of fields. 

I also see some third party modules involved here, and I don't know to what extent they also add overhead. For instance, I see you've got Teppo's awesome version control module on most of your fields. I also use that on my sites. But I've always assumed there must be some significant overhead with it given all the great things it does, so I typically limit usage of it to only 1-2 fields on a template. Unless Teppo says otherwise, I would suggest doing a test and remove the version control from those fields just to see what difference it makes. In fact, the same goes for any 3rd party modules that you've got involved here (I see one active in your files). Remove or change them to non-third party temporarily just to see if you an find any bottlenecks. Sometimes certain bottlenecks only become apparent at larger scale like you have here.

One thing that could make a potentially huge difference here would be use of the Textareas ProField field. This is the perfect case for it, since you have so many similarly configured Text and Textarea fields. It looks to me like you could potentially reduce your quantity of fields by a factor of 10 or more, which may solve the overhead issues completely on their own. However, you may lose the version control (which I'm assuming either doesn't work with the Textareas ProField, or treats all the components of it as one block), and you would have to change your multi-language approach slightly by using the language alternate approach with separate language-specific Textareas field. But it would still drastically cut down on the field quantity and thus overhead. 

Another thing to consider is that it's possible you may be trying to accomplish too much with one page/template here. If you look at it from a database design perspective, it's kind of like having one giant god table that holds everything, rather than splitting it out into specific, more dedicated parts. However, if each of the pages like this is completely different in content (i.e. little to no repetition of what gets populated in the fields), then it may be completely fine. I can't really evaluate much from looking at the screenshots because it's just one page and I don't read the language. So I'd be inclined to see how you can reduce overhead with what you've got before you re-think the structure of it. 

Lastly, you may have to consider the PHP max_input_vars limit. With ~150 fields multiplied 4 languages, plus quantity of individual files multiplied by 4 languages, you could hit the default limit already. You will likely need your system administrator to bump that limit up from 1000 to 3000 to play it safe. Otherwise you could experience data loss when saving a page.