The only
thing that needs to be shared when scaling upward is the database.*
* Some would consider a shared database to be shared-something, but I digress.
174 | Chapter 6: Performance
Nevertheless, there are a few other concerns that you should be aware of when scaling
a Rails application. The biggest concerns are the other shared state besides the
application data: storage for sessions and cached data.
Sessions
The Rails session infrastructure is built on top of Ruby??™s CGI::Session from the standard
library.* CGI::Session takes care of the basics of CGI session management. It provides
the following session stores, each implemented as a class within CGI::Session:
FileStore
Stores data in a file as plain text. No attempt is made to marshal the data, so you
must convert any session data into a String first.
MemoryStore
Stores session data natively in the memory of the Ruby interpreter process.
PStore
Similar to FileStore, but marshals the data before storing it. This allows you to
store any type of data in the session. This is a good option for development, but
it is not suitable for a production environment.
Because these options are quite thin and not too suited for large-scale web applications,
Rails provides some session managers that are more helpful. In particular, all
of these options enable sessions to be shared between different application servers.
Pages:
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271