Re: DB calls vs Session solution

Curt Zirzow wrote:

On Mon, Mar 13, 2006 at 03:30:18PM +0100, Jochem Maas wrote:

I just realized I must be evil ;-)

Arn't we all :)

more so for the random switch to inline+bottom posting :-)

...

Ah, see this is a bit different, and goes along the theory of a cost has to come from somewhere, and in this case you have memory to use and abuse. The problem with relying on a third party solution, whether it be APC's cache or MySQL's cache, you end up having your application dependent on them to work under heavy load.

I had loads running up to 25+. the server remained responsive but felt slow. bit like Dell when there is a 'good' deal on ;-).

But then again, if a site is rather busy custom solutions will be needed, and requirments to run the site become greater. I'd like to see google/yahoo ported to some server(s) easily :)

out of interest, Curt when you say 25 requests a second exactly what kind of requests? I mean 25 request each second on a php file that queries a DB with lots of LEFT JOINs, etc is going to require a pretty heavy piece of iron no? (at least more powerful than anything I can get my hands on in general.)

Yes, 25 requests per the webserver, aka each php file. Since you evily top posted i would guess that one of my suggestions, in the thread, was to try to design something that didn't have a left join. If I had relied on left joins to join the data i need to get the site working my apache's 'current request being processed' of 182 would be bringing any P4 with hyperthreads to its knees :) I think as this topic is enfolds, the key thing is either to make your queries as fast as possible (using good indexing), flatten a structure to provide speed, or use a cache system.

the nice thing about programming with my 'data framework' is that its very generic, flexible and interspective (generating abitrarily complex sql/html/? from objects) ... which comes with a great cost. so I have code that is really very very heavy but if you consider the (complete|discount|standard|bundeled) price calculation routines for the site I was speaking of, are 1000's of lines in themselves you might agree that a more structured apporach to the code bear fruits in maintainability/extensability (which has been my finding overall). bottom line is [they] have to buy a bigger box. :-) actually my real problem lies in not being [cap]able of using the Smarty cache (I can't figure out how it works/how to use it) :-\ I can do very dynamic, I can do very fast. both together is whole different ballgame.