This removes a
server-side obligation to keep track of sessions, but it introduces some minor security
issues. The issues surrounding the cookie session store were discussed in detail
in Chapter 5.
Session management
Of course, the ultimate performance enhancement to sessions is not having to use
them at all. The session class method allows you to specify actions for which sessions
are not needed at all. This can save a decent amount of processing power for
actions that are viewed often but do not require the use of a session.
class PersonController < ApplicationController
session :off, :only => [ :list, :show ]
end
Caching
Database caching via cached_model and acts_as_cached has been discussed earlier in
the book. If your bottleneck is in retrieving records from a database, memcached and
those solutions will help.
There is another significant bottleneck in most applications, though, and this one
requires more thought. Many applications have rendered pages or parts of rendered
pages that, while dynamic, can be cached to some extent. Rails has a few different
types of caching methods that allow various levels of granularity when deciding what
to cache.
By default, caching is only enabled in production mode, so as not to complicate the
debugging process. You can enable caching in development mode with the following
line in config/environments/development.rb:
config.
Pages:
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275