Thanks for the response - the idea of 'minimizing data that PHP processes' as a design pattern for PHP web apps is an insight that I had totally missed, and appreciate your pointing it out. It also helps to explain why there isn't a whole lot on the internet about perf tuning/profiling CakePHP apps :)
I think I may have mis-architected my program. What I wanted to do is have a student visit a single page, where everything is available. Using the HTML fieldsets as visual panels, I wanted to have a panel that would let the student upload their homework (which requires a list of homeworks for the current course), another panel with a set of links to work that they'd previously uploaded (so they can see that it was submitted, and so that they can re-download it later), etc, etc. My hope was that I could ask Cake to get the user information for the current student, set recursive = 3, and then have Cake prune away any data that didn't pertain to the current student. After which, it's quick-and-easy to render all the stuff that I'm looking for :) I think that because of the way I've got my tables set up, recursive=3 and doing a find on the user account didn't quite go deep enough (I'm not quite sure if this is a bug in PHP, or my code, or what)(almost certainly my code, but I haven't debugged it enough to get beyond the initial stage of "This _should_ work" :) ) So I'm worried about scalability not because of trying to display 800 rows at once, but because I think that I'm mis-using Cake to get too much info & pruning it back once it's all in memory. Actually, if you don't mind - what sort of capacity should Cake/PHP have for pulling stuff into memory? I assume that anything less than 100 rows of data should be fine - what about 200? 300? 500? I don't know if anyone's done any sort of measurements about "CPU X, with memory Y GB, Cake can draw Z records into memory in A milliseconds", but it would be fascinating to see :) Thanks again for the quick, really helpful response! (And, for what it's worth, I'm loving Cake right back! :) ) --Mike On Sep 24, 8:17 am, Rafael Bandeira aka rafaelbandeira3 <[EMAIL PROTECTED]> wrote: > Mike, I think it's not "how much data is Cake intended to deal with" > is how much data your app is intended to deal with, > thousands of records is not something that should be dealed by php, > the database does it much faster and safer. > Having lots of data in database doesn't mean you have to deal with > them always - I would say ever - because you would rarely want users > stumbling their heads on to a 800+ rows report, I would say that > using a 30+ limit in a report/index is already annoying. > Now how do you intend to support thousands of records include in the > app database if not with a file upload? there's no way to make a user > fill more than three forms at once... And as the database can handle > files, al you have to do is parse the file if needed. > > Cake loves you and will do lots of things for you, but it's still php > and still uses memory, relies on cpu process and all this stuff. > > rafaelbandeira3http://rafaelbandeira3.wordpress.com > > On 24 set, 03:25, Mike <[EMAIL PROTECTED]> wrote: > > > > > Thanks for the tip! In the previous, non-Cake version of the app, I > > did that exactly, so it shouldn't be too too tough to get it up and > > running again. I was kinda avoiding SQL b/c it seemed like "the Cake > > way" should be to push it through the Cake layer & let CakePHP make it > > automagically happen. Hearing that raw SQL is actually the right way > > is actually really helpful :) > > > If you don't mind my asking a couple more questions - how does one > > know where the boundary should be? I mean, aside from exceeding > > max_execution time and/or running out of memory - how would I know > > where to draw the boundary between 'small enough for Cake' vs. 'needs > > raw SQL' when designing my app? (And what does a normal app do if a > > user happens to show up with an unexpectedly huge data set?) > > > Also, what sort of data sets is Cake intended to support? I'm writing > > the app to support my teaching, so having 30 people in a class, with > > 10-20 homeworks/exercise sets to hand in (each of which might have 2-3 > > versions stored), so it's conceivable that Cake might auto-magically > > pull 600-1,200 records (even if fairly few / none of them are used in > > any given view). One of the things I really liked about Cake was that > > I could set recursive = 2 (or 3), and have it magically pull > > everything I needed out of the DB (in my raw PHP app, I figured it was > > time to look at a framework when I started to move towards an OOP-y > > iterator approach for dealing with all my lists of data :) ) > > > Thanks again for the quick reply - I appreciate the 'ok' from someone > > who knows more about this than I do! :) > > --Mike- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to cake-php@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
