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 -~----------~----~----~----~------~----~------~--~---
