On Wednesday, June 26, 2013 10:14:21 PM UTC+9, NSC wrote: > > I'm late to the conversation but if I'm understanding, I did something > like this last year. > > I built a reporting front end on MySQL, served by web.py. Basically, every > report had a distinct URL, and the server would perform the SQL and > generate the page. I wanted to deliver a cached report until the > underlying data changed. > > So, I actually did two things: first, for data that was only updated once > a week, I built a daemon process that created static HTML files. In my app > I made sure to append a random number to any links to this report to bust > the browser caching. So, the user would get a fresh page from the web > server each request, but it was a straight file serve so very fast. > > Second, for reports that might update randomly, I made a compromise. Saved > a cookie with a timestamp on the browser, and used that on the server to > only do the db query once an hour. Put a button on the page so the user > could do a "live refresh" if they felt the data was stale. This translated > to much faster pages overall, with the occasional lag once an hour. > > Not sure if any of this helps at all. > > Finally, as a best practice note regarding serving SQL query results via a > web server - I *never* build a report with a live query if there's any > chance the SQL will take more than 3 seconds to complete. Waiting on a > server translates to user unhappiness. In cases where queries might be > long (I've had some oracle queries that run for several hours!), I always > build a daemon process that aggregates the data into flat and fast summary > tables that can be quickly served. > > S >
Thanks! you are right! that's what I want to do. I was thinking of cookie too... But hey, the question I asked on reddit has got answers. It turns out that it is really the data which is saved in cache not the final html page. That is much easier to manage and more flexible to implement than caching final html. Though the app still has to render page on every request, but it doesn't have to hit the database every time because it goes to cache first, if cache doesn't have the key then it will go to database. I think that's good enough. Now the only problem remained to me is how to cache data properly. I was so stupid...didn't thought about that, only keep thinking of how to cache the final html. What a fool I am. sigh... Thank all people in this post who tried to help me, especially Tomas. Thank you guys. -- You received this message because you are subscribed to the Google Groups "web.py" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/webpy. For more options, visit https://groups.google.com/groups/opt_out.
