Talk:GameZone

CS290F Fall 2006 - UCSB Computer Science - Thorsten von Eicken

Project Comments

The project looks good. The data models are appropriate, but the controllers are more like specific pages than they should be. Remember, the controller methods are the web pages, not the controllers themselves. Using the standard CRUD model, the controllers tend to correspond to the major data models in your application, and the pages are all some way of viewing or editing each of those data models.

Stefan 02:03, 31 October 2006 (PST)

• I can't get to your site, I only get the Fedora Core Test Page. PLease fix and email me when ready.
• For string search, use prefix search (blah% not %blah%), not as nice interface, but allows you to create an index.
• Be sure the user queries matter before storing user object in session. You'd need to invalidate anytime user obj changes too...
• You will probably need to use some EXPLAIN statements to see where you need indices.

TvE 00:10, 18 November 2006 (PST)

• Very nicely done! Love it.
• When I create a review, the catalogid should be a pre-populated hidden field. And I got confused by the title field, thought it was the title of the game, maybe you should call this "subject"? I'm unable to enter a review: Mysql::Error: Cannot add or update a child row: a foreign key constraint fails: INSERT INTO reviews (`catalogid`, `con`, `posting`, `pro`, `title`, `createtime`, `reviewer`, `overallrating`) VALUES(1, ' ', 'Yadda yadda', ' ', 'dfgdfg', ' ', 'egfggee', 0)
• For the game listing page, you should truncate the descriptions a bit, many are too long. I'd much rather see a summary of the rtings displayed so I can make a better buying decision.

TvE 08:42, 18 November 2006 (PST)

• Very good description of your thought process and analysis! Keep that going!
• Time to reorganize your wiki pages a bit so it's easier to browse and find the various parts of your project.
• It's great that you found your DB problem spot! Could you add the relevant code snippets to your wiki so I can really understand what produced the problem?
• You should use a better range for the --rate parameter. You are starting too high and so all your graphs are flat. Start at --rate 1, or even at --rate 0.2 so you see the unloaded server to which load gradually is applied. Once it maxes out, there not much point in going higher.
• It seems that now that the DB is no longer the bottleneck you can scale to multiple servers!

TvE 18:35, 2 December 2006 (PST)

• Web site looks a lot better now!
• Results up to 3 servers look good, scale nicely. Time to try for more.
• I don't understand why you claim that the DB is the bottleneck. Yo have no data for this. Did you look in the production.log to see what fraction of time is spent on DB versus rendering? You should, however, increase the DB size to make the whole test more realistic.
• You need to reduce the number of instances you have running all the time. Can't leave 5 running like that. For that you have to have the deployment automated so it's a minor effort to get 10 servers going...
• Keep up the good work!

TvE 07:50, 4 December 2006 (PST)