Huge performance problem: 1 months work down tubes?

Next topic

Author	Message
Willie Seabrook	Tuesday 04 November 2003 9:19:14 pm Hi, I've been developing search functionality for a site for about a month and I just switched it on to a staging server to prepare to go live next week. To see what I did see: http://www.ez.no/developer/ez_publish_3/forum/developer/http_post_get_hack_instead_of_ezenv The problem is that all this while I've been developing with viewcaching off (very slow... anywhere from 0.5 to 2 seconds to load a normal page and 2 to 6 seconds on the search). Obviously this isn't practical for a live site and after I switched on viewcaching to speed things up I realised that it disables the use of post variables somehow. Anyone have any ideas of what to do? I was thinking of pushing a major hack in having one page write http post vars to a file, redirect to the search page which uses a template operator to load those variables from their files. Would this get around my viewcaching problem? Is this 1972? Why is such a crippling design flaw built into such a good product like ezpublish? And don't say its problems with my design - all my design is is using http post variables and thats not that outrages. Well maybe in 1990 it was but now?? Please help! Ezpublish? Regards, Willie Seabrook
Tom Couwberghs	Wednesday 05 November 2003 12:46:29 am Hi Willie, I don't know about whether viewcaching disables your POST-data or not. But you could always install a caching engine on the PHP-level. This will improve general performance without hacking your ezpublish-code. I have some very good experience with Turck MMCache on this matter; easy to install and it gives a significant performance boost. About the Postvariables in the templates: have you looked at cache-blocks yet? These are template instructions that tell eZPublish which elements to cache. Putting your POST-variables outside these cache-blocks could help. HTH, Tom
Paul Forsyth	Wednesday 05 November 2003 12:52:25 am Hmmm, i don't understand how post/get variables can be disabled. PHP will still have them. Maybe the loading of the cached files ignores any attempt to retreive them? Can you use cache blocks around the slow areas and leave the other areas open? Does a php accelerator help here? Im wondering if there are ways of building small amounts of cached areas rather than cache the while lot, and if that will help. We had a similar problem, i think, where we wanted to pass a variable between templates. When templates were cached the variable became static and wouldn't changed. By making a small module we got around this: http://www.pobox.co.uk/services/hosting/sun/sun_cobalt_raq On this page the 'call me' allows us to pass information through to another template with details of the item in question, so we could populate that template with the right information. paul
Tom Couwberghs	Wednesday 05 November 2003 1:17:43 am Hi, I'm just guessing with the cache-blocks thing. Like you, I can't think of any reason why PHP would lose it's postdata. A caching engine improves the overall performance of a site, so it sure is applicable here, as it would allow Willie to run his site with viewcaching disabled and still have reasonable performance. Greets, Tom
Paul Forsyth	Wednesday 05 November 2003 1:27:58 am The only plausible reason for ez losing its access to post/get data would be that its loading from cache instead, by passing the need to use the php files at all. Sometimes i find cache-blocks dont work the way i expect. This in part led to the development of the callme module i mentioned. We simply could not get the variable to pass between templates uncached. paul
Paul Forsyth	Wednesday 05 November 2003 2:02:09 am Did a quick site search to find the thread where we discussed this: http://ez.no/developer/ez_publish_3/forum/developer/preventing_cache_on_a_piece_of_code_on_a_site_that_needs_cache_on_other_pages It doesn't really help here but gives some history. paul
Willie Seabrook	Wednesday 05 November 2003 2:27:45 pm Temporary solution I'm going to use is putting {set-block scope=root variable=cache_ttl}0{/set-block} in the relevant page. I've tested it with that and it works and view caching is still enabled for the rest of the site. Thanks for the tip I had no idea about the cache_ttl variable. Thats not a long term solution however cause on the search page, the worst searches can last up to 14 seconds but It will have to be like that to begin with. I've got a 1.8GHz server lying around which isn't doing anything so I'll run it on our old server (600mhz PIII) for a few weeks while I build the new one up with Turuk Cache included and perhaps rewrite it as a module. That should have a big effect on performance :-). Paul could you explain in a little more detail what you did with that module? Why can you use get vars in that? Why would it make any difference to what the cache engine does? Regards, Willie
Paul Forsyth	Thursday 06 November 2003 1:51:42 am I'll try and sort out publishing that module later today on pubsvn. I have to clean the code up with comments and put a gpl licence on it. Im not 100% on the ins and outs of cache, im afraid. I do know we didn't try the cache expirary method you have used. It might have worked with out problem but im not sure. Back then we were using 3.0. As for why our solution wasn't cached im not 100% sure either. It worked for us probably due to the fact it was an independant module with its own template. Cache expirary may be a better solution now. paul
Paul Forsyth	Thursday 06 November 2003 4:44:36 am willie, i've added the callme module to pubsvn.ez.no. take a look. hope it helps. paul