Rails - Sep 2005 - Concurent users

I''m currently developing a web game, using rails and I am concerned
about
how fast the pages will be dispatched to the users.
I know everyone says rails scales, but right now I''m more interested in
optimizing it as much as possible, rather than adding more ram and more 
cpu''s ;)
Since this is my first real application in rails, I don''t really know
how it
will behave once it''s done.
Assuming you have over 150 concurent users at any given time, what should be 
the main concern regarding the speed?
At some point I was worried that for some pages the session had a size of 
several kb''s. Is that a real problem? 

Assuming you have the a Player and Player has_many :emails and has_many 
:girlfriends
I dont know how rails optimizes this, but is the session going to contain 
all the girlfriends and all the emails of the @player?
What if I know that for the next page, the player doesn''t need to
access his
emails and therefore I don''t need the session file containing that info

Bogdan


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

Ah, another person attempting to twist Rails into a game development 
platform :) I''m currently doing something similar.

First, there are two ways you can handle this. You can either store all the 
data in the session, and reload it as you need, which is actually quite 
fast, or you can store just an id for the Player. If you just store the id, 
you can just do a db lookup (optimized as you wish) on the parts of the 
model you actually need.

But always remember that performance isn''t a problem until performance
is a
problem, and never try to optimize without testing first. So, first write 
your code in well-structured form that works, then look into where 
performance can be tuned and work there. It''s been my experience (and
the
experience of many others) that performance bottlenecks are NEVER where you 
expect them to be, and you''ll find yourself heavily optimizing some
code
that is only being executed for, say, 1% of the runtime.

My current implementation in my game is to simply store the User object in 
the session data, and do @session[:user].reload() whenever I need up-to-date 
data. (basically, every page that uses the data at all, right now) Perhaps 
later I''ll store just the id and load only the data I need, or maybe
I''ll
just check the updated_at column for the cached data and see if it''s
been
changed since the cache. There are multiple methods, but I could spend hours 
just tinkering with that instead of doing the real work.

On 9/3/05, Bogdan Ionescu
<bogdan.ionescu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 
> I''m currently developing a web game, using rails and I am
concerned about
> how fast the pages will be dispatched to the users.
> I know everyone says rails scales, but right now I''m more
interested in
> optimizing it as much as possible, rather than adding more ram and more 
> cpu''s ;)
> Since this is my first real application in rails, I don''t really
know how
> it will behave once it''s done.
> Assuming you have over 150 concurent users at any given time, what should 
> be the main concern regarding the speed?
> At some point I was worried that for some pages the session had a size of 
> several kb''s. Is that a real problem? 
> 
> Assuming you have the a Player and Player has_many :emails and has_many 
> :girlfriends
> I dont know how rails optimizes this, but is the session going to contain 
> all the girlfriends and all the emails of the @player?
> What if I know that for the next page, the player doesn''t need to
access
> his emails and therefore I don''t need the session file containing
that info
> 
> Bogdan
> 
> 
> 
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
> 
> 
>

_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

>  Assuming you have over 150 concurent users at any given time, what should
> be the main concern regarding the speed?
There''s one cardinal rule in performance questions: Measurement. You
don''t have to wait until 150 concurrent users are knocking on your
door. It''s possible to simulate this well in advance. See the
Deployment chapter in the Rails book for some pointers, search the
list archieves, and look around the web. The techniques for putting
stress on a web application are more or less the same no matter which
environment you''re developing in.

And remember, the easiest way to get more performance is to buy bigger
iron. More often than not, it''s also the cheapest (if your project has
a business model).

So start measuring. Then act on the results. Acting before is not only
useless but often harmful as optimizations often sacrifice other
desireable attributes of software in the process (readability,
comprehension, size, etc)
>  What if I know that for the next page, the player doesn''t need to
access
> his emails and therefore I don''t need the session file containing
that info
It''s recommended that you just store the player id in the session and
then reload him from the database on each request. That way you avoid
big sessions and you don''t have to worry about getting stale data.

But you really shouldn''t be worrying about this point until you have
measurements that tell you that the bottleneck is there.
-- 
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework