> > I'm using expects(), it's pretty handy. My problem might be loading > lot of models but still 'pages' doesn't load any models. Do you know that for sure? If you lets say load the Users model in AppController, then it is more then likely that *all* of your other models are loaded b/c they are somehow associated with User.
My suggestion is to not work / rely on benchmark solutions that just hammer at your server too much - its very complex to create a realistic scenario that way (i.e. 20 users holding down on your front page or some other action is very different from each of them doing different things). The best way to make your app faster should be to get some profiler going and see what functions / parts of your app take the longest to load and then optimize them. From there I'd keep an eye closely on the server load during traffic peaks which you can use to generate yourself some statistics to estimate when your current horse power will not be enough anymore. Then it is time to cluster and scale your architecture. Anyway, I'm not an expert on the matter and you may be able diagnose things with your current benchmark setup as well - however I think its not the easiest path. Good luck and success with your app! -- Felix -------------------------- My Blog: http://www.thinkingphp.org My Business: http://www.fg-webdesign.de thequietlab wrote: > thanks for your answers, > > @Simon > > >> ab -n 1000 -c 20 >> means that you have 20 concurrent users making 1000 requests. The >> important part here is the concurrent bit. >> > > ok, sorry I said it wrong - I know what does it mean but I'm not sure > what should be the values to simulate traffic at a range like 100,000 > users per day. I know it depends on the peak hours etc. but is there a > way to estimate some values to know what to expect ? > > >> There's a wide variety of things you can do to optimise your >> controller, which are way beyond the scope of a single post, >> especially since you don't really say anything about what your >> controller is doing. >> >> Turning on caching might help. >> > > These are mostly pages you view after authorization so traditional > cake views caching is not of any use. I use memcache to save on > database queries and it seems like mysql is not a bottleneck here. I > can imagine my controller can be optimized - it's just a first phase > of the deployment - but the same (or almost the same) happens with > "static" pages which don't use any models. > > > >> The key to this is most likely memory based. Is your 70% usage just >> cpu, or is there wait time? Is memory swapping? You can do all sorts >> of things to cap rates, reduce linux's aggressive swapiness, or >> improve the use of disk. If memory's not the problem, maybe you could >> move cake's cache into ram. >> > > ok, I'll take a look on the memory but it doesn't seem to be a > problem, at least memory is not swapping. > > > >> Cake can be very memory greedy if you use reconnect on datasources, or >> load a lot of models, or have a lot of relations. Lookup the expects() >> function on the bakery or look at bind(), unbind() if you want to deal >> with that the hard way. >> > > I'm using expects(), it's pretty handy. My problem might be loading > lot of models but still 'pages' doesn't load any models. > > > >> Other than that, it's probably a close investigation of you controller >> code and some optimisation there. >> > > What controller does is nothing complicated - just takes data from db > - 2 queries cached with memcached so they don't even get called (cache > is dynamically changing on updates) > > > >> Note also that ab will not provide a good test, since it does not >> download embedded resources (images / scripts / css etc) since it does >> not have any html parsing. You might do well to look at something like >> jakarta Jmeter, which is very good, if a little daunting for the >> beginner, or some of the dodgy cheap windows stuff like Website >> Optimizer (I think). >> > > Sure but I just wanted to stress the application itself. > > > >> Just some ideas. Hope they help. It's all a bit open-ended but I may >> be able to help more with a better description of the controller. >> > > THANKS for it Simon! I know it's a pretty big area and lots of things > matters. I will be checking things one after another and will try to > optimize it. > > One thing I noticed.. when I'm doing debug($this); and it dumps > everything there's a lot of *RECURSION* at many points.. objects just > holding themselves at many points.. I'm not sure but it might be quite > a bottleneck. > > > @majna > yeah.. I was planning to use xdebug, could you maybe provide any links > on how to set it up properly ? > > I'll take a look at var $persistModel, debug is 0. > > As I already noticed var $uses is a point to optimize. > > What do you mean by : "do not use mod_rewrite" ? Cake url's are based > on mod_rewrite. > > > Thanks, > Andrzej > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
