On 24 Mar 2010, at 19:35, Rene Veerman wrote: > > take this example, sorry for the crosspost; > > my main concern atm is my own cms (50-100k lines of my own); it's > graphics-heavy, does fairly complicated db based logic, and if it ever > is to be used for a site like facebook, it'll get large dataflows that > have to be distributed over the servers used to generate html and > accessoiries for end-users. > i've built a layer into it that caches the output of oft-used pages > (like articles and their comments). > but adding many comments / minute to an article would result in quite > a bit of overhead, to update the html for that page and distribute it > (fast enough) to the relevant servers. > > i'm worried about php's single-threaded nature; each request has to > fetch html updated in the last few seconds, or generate it from a list > of comments. that's also a big query from a big table for every > end-user.. :( > i'd rather keep them comments for an article in shared memory..... Shared memory in PHP generally means memcached. Look it up - it does exactly what you need here, and with the right usage strategy it's more than capable of handling data that changes many times a second. I think I'll need to spell this out, and I really hope you'll read this one properly. Use memcached to store data in the format in which you need to access it, update it when something changes not when requested and use the DB as permanent storage only. I've written highly scalable systems using this strategy, and the possibility that threading could improve the performance of said systems has never spent longer than a few seconds crossing my mind. And, if you don't mind me asking, when you say graphics-heavy do you mean it uses a lot of images? And if so, how the hell does that affect the scalability of PHP? -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
