# Ruby Enterprise App Design Advice

**URL:** <https://www.ruby-forum.com/t/ruby-enterprise-app-design-advice/49141>\
**Category:** Ruby\
**Created:** [November 30, 2005, 5:27pm UTC](https://www.ruby-forum.com/t/ruby-enterprise-app-design-advice/49141 "2005-11-30T17:27:01Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![teslaomd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/7ba0ec/32.png) [@teslaomd](https://www.ruby-forum.com/u/teslaomd)\
**Post date:** [November 30, 2005, 5:27pm UTC](https://www.ruby-forum.com/t/ruby-enterprise-app-design-advice/49141/1 "2005-11-30T17:27:01Z")

</div>

I was wondering if anyone could give me some advice/thoughts/input  
regarding scaling/designing in Ruby for an enterprise level app. Mainly  
I am looking for suggestions for existing Ruby code/apps I can use to  
address my design and concerns. I would like a lot of feedback on  
FastCGI vs. running things the .NET or J2EE way. In a way I’m building  
a framework, but a project specific one for an enterprise app, not for  
the average personal dynamic website. I may release it after the  
project is complete.

Please excuse the length of this post but I think I should explain the  
situation a bit since scalability and design are broad and complex  
issues. I know that many do not consider Ruby to be an enterprise level  
language, but I am a believer in rapid development and scaling through  
good design/programming. Language does not matter to me. I’ll also  
mention that I know performance != scalability, though I will say it  
can help scalability, particularly vertically.

Background:

I’ll try to oversimplify this in the interest of this post not being  
more of a book than it already is. The software is actually a new idea  
that I’m not going to reveal for creative reasons, but it is probably  
closest to some of the existing social networking/dating apps. The app  
must support over a million users (yes, this is realistic if not a  
gross underestimate if all goes well). We expect to have several  
thousand concurrent users. AJAX and querying DB data will play a heavy  
role in the system. Users will have lots of preferences/settings to  
manage/configure, most of which will be stored to disk as xml  
(serialized objects perhaps?) rather than the database.

Our reason for selecting Ruby is because we want to continue to bring  
more attention to what we feel is a wonderful language (thank you Rails  
and others for contributing already) and also since we want to reduce  
our time to market as much as possible. We also want to try to give  
back some of our end results to the Ruby community in terms of code.

Our development team is very experienced in web apps, but new to the  
Ruby world as far as serious applications. We are trying to find out  
more about what is already out there, needs to be done, and what  
limitations we might face. We’ve done extensive research but I would  
like some opinions directly from rubyists, rubycons, whatever. We’d  
like to scale horizontally and vertically and leverage cheap hardware  
to start until the site gets going more.

Current Specs/Design:

Our design uses MVC/n-tier. Business logic should be able to run  
independently on its own servers and not care about the web. Some of  
our basic design/plans are as follows:

1. Web Server – Lighthttpd - seems to work well with FastCGI, very  
quick. Load balanced to send user to best server. Dedicated servers for  
things like serving images.

2. FastCGI or SCGI - We would like to replace FastCGI with something  
else if possible since we have concerns about all of our processes  
being constantly occupied by AJAX polling back to server code. We’re  
not entirely convinced FastCGI is a great architecture for us but if we  
do use it, we would like to scale it accross many servers and use a  
SessionID to bind a user to a server. I worry about running out of  
available FastCGI processes, even with multiple machines.

3. Database – MySQL or Postgres - We need transaction support and data  
integrity – doubts about MySQL in these areas. We also need good join  
performance - database is heavily normalized, may denormalize if  
needed. Separate DBs for things like Logging/Auditing vs. Content. Want  
to cluster DBs. We want connection pooling. Considering making some  
modifications to DBI. Use stored procedures in the database, no sql in  
the code/dynamic sql. I loathe O/R mappers for complex databases and  
they would likely bring our system to a screeching halt. Unfortunately  
we cannot afford to use Oracle right now.

4. Caching – We’ll cache user settings, DB data, etc. Need a good ruby  
caching solution. Considering using memcached or something else  
existing.

5. Templating – Not satisfied with anything. Considered Clearsilver  
but now developing our own system in mainly C++ that is more  
accomodating to the way our site works/AJAX.

6. Unit Testing and Performance numbers for every procedure. Is there a  
good code profiling tool for Ruby? Use both with makefile process.  
Where we identify bottlenecks, we may refactor or write in C++. We may  
move some of the critical components to C++ where possible. We’ve  
looked into using SWIG to help our C++ efforts.

7. Sessions - Separate server for managing Sessions if possible. I  
would like to persist things in memory and share if possible. If not  
possible, we’ll settle for persisting info to the database. Been  
looking at Session affinity for Ruby some.

8. AJAX - Polling and Queuing system for AJAX interactions in  
Javascript. Queing server side. Likely we will use and possibly extend  
an existing AJAX library such as Mochikit or base it off another  
existing one.

9. Remote - Looked at Drb for some remote things.

10. External Services - We may expose some web services in the future  
or have internal web services. We may also be providing RSS feeds from  
things like blogs or lists. We’ll use ReXML for our xml needs, but we  
may switch to c++. I’ve heard performance concerns about REXML but have  
yet to test for myself.

11. Events/Threading - I am worried about Ruby here, especially after  
reading about Myriad’s problems with libevent. We will definitely need  
something similar to delegates and events and some good queueing and  
threading functionality.

We looked at Rails like everyone else but after using it a bit, reading  
the author’s blog, and from previous experience in other languages it  
is clearly not suitable for the size and complexity of our application.  
I also will reiterate that I hate O/R mapping unless it’s for a quick  
personal app.

Concerns: Our main concern is of course scalability. Our AJAX controls  
(many already finished) will need to poll the server in some cases over  
a specified interval. We know that this is going to create some new  
demands that we did not have to worry about in the purely synchronous  
webpage development model. We have already seen these issues some in  
our .NET, J2EE, PHP, and Python apps, but none of them have to deal  
with this much traffic. We feel that many of our AJAX controls are  
going to create unique demands on the application, particularly given  
the environment Ruby runs in and its threading limitations.

For instance, a purely hypothetical example might be we have a control  
that lists online users along with status information.The controls  
would need to requery information every 20 seconds to obtain fresh  
information about the users (are they online? what is their current  
mood? what did they last do?). This means that our server is going to  
get hit a lot harder than your typical web application that serves up a  
dynamic page, then sits idle until the user moves on to a new page.

Final Thoughts:

I believe my greatest concerns are shared memory, caching, sessions,  
and the FastCGI dynamic. We need to support a lot of simultaneous users  
and I’m worried the process model needs to be perhaps replaced with a  
threadpool/queing model (one that responds quick though). Caching on  
all levels will have to take a lot of the pressure off of us. I’ve  
never been a fan of Session variables but we do need to manage a lot of  
session info. We need a lot of user to user interaction so this is  
another concern with the FastCGI setup.

The read-write ratio in the app is probably about 70% read 30% write.  
At any one time however we can expect the app is doing a significant  
amount of writes to the DB but not compared to the amount of reads, so  
keep this in mind. Our entire design needs to factor this into the  
equation.

I hope that even though I’m new here I can get some good suggestions.  
I’m excited to write something on this level in Ruby and get away from  
the .NET, PHP, and J2EE stuff I’ve worked a lot with in the past. FYI,  
I started doing C, Pascal, COBOL, etc. in desktop and client/server  
apps for many years before moving on to mainly web apps so forgive me  
if I’m naturally skeptical of everything.

Thanks and I would deeply appreciate any input no matter how big or  
small.

---

<div class="post-metadata">

**Author:** ![teslaomd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/7ba0ec/32.png) [@teslaomd](https://www.ruby-forum.com/u/teslaomd)\
**Post date:** [November 30, 2005, 6:11pm UTC](https://www.ruby-forum.com/t/ruby-enterprise-app-design-advice/49141/2 "2005-11-30T18:11:40Z")

</div>

I’ll insert my comments inline. Pardon any mangling I manage to do to  
your message.

On 11/30/05, TeslaOMD [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> In a way I’m building  
> a framework, but a project specific one for an enterprise app, not for  
> the average personal dynamic website. I may release it after the  
> project is complete.

This is a good idea in general, because it forces you to see the  
problem in an abstract way, and to make sure you have full test  
coverage. Rails is much better as an open project than as an in-house  
framework, from a code quality perspective.

> I know that many do not consider Ruby to be an enterprise level  
> language, but I am a believer in rapid development and scaling through  
> good design/programming.

I’ve been using Ruby in production in an enterprise environment for  
some time. Most enterprise (read, Java) experts like to ignore the  
amount of code tied up in “non-enterprise” languages like shell  
script. If Ruby isn’t an enterprise language, is Perl? It sounds  
like you’re not too worried about the viewpoint of CIO magazine, so I  
think you can go ahead and use Ruby if you want. Heh.

> Users will have lots of preferences/settings to  
> manage/configure, most of which will be stored to disk as xml  
> (serialized objects perhaps?) rather than the database.

Do you have a scalability plan for this? Databases are mostly a  
‘solved problem’, but persisting things to disk in a cluster is much  
harder. Are you worried about the overhead of the database for this  
task?

> We also want to try to give  
> back some of our end results to the Ruby community in terms of code.  
> Very cool.

> 1. Database – MySQL or Postgres - We need transaction support and data  
> integrity – doubts about MySQL in these areas. We also need good join  
> performance - database is heavily normalized, may denormalize if  
> needed. Separate DBs for things like Logging/Auditing vs. Content. Want  
> to cluster DBs. We want connection pooling. Considering making some  
> modifications to DBI. Use stored procedures in the database, no sql in  
> the code/dynamic sql. I loathe O/R mappers for complex databases and  
> they would likely bring our system to a screeching halt. Unfortunately  
> we cannot afford to use Oracle right now.

If your database is heavily normalized, isn’t that precisely where ORM  
systems shine? It’s usually with complex ‘legacy’ schema that you run  
into trouble. Object mappers save so much developer time, I’d rather  
spend the extra time writing better business logic, and optimizing the  
database design. Slogging through endless “stuff these fields into  
these properties” modules is a recipe for difficult refactoring.

Personally, I’ve really only used Oracle with Ruby. Between MySQL and  
Postgres, my choice would certainly be the latter. I much prefer  
sequences to autoincrements, and it’s nice to have subselects not be a  
recently-added feature. That being said, many huge systems are  
running on MySQL. You just need to be familiar with its limitations  
while designing your app.

> 1. Caching – We’ll cache user settings, DB data, etc. Need a good ruby  
> caching solution. Considering using memcached or something else  
> existing.  
> Rails comes with pretty slick caching. Even if you don’t want to use  
> Rails itself, you could at least borrow their caching code. Remember,  
> also, that you can use Rails without ActiveRecord, if you don’t like  
> ORM libraries.

> 1. Templating – Not satisfied with anything. Considered Clearsilver  
> but now developing our own system in mainly C++ that is more  
> accomodating to the way our site works/AJAX.  
> What exactly is ERb not doing for you? I’ve never been a big template  
> fan, myself, except maybe for what Wicket uses: (Warning: Java!)  
> [http://wicket.sourceforge.net/](http://wicket.sourceforge.net/)

> 1. Unit Testing and Performance numbers for every procedure. Is there a  
> good code profiling tool for Ruby?  
> Check out Ryan D.'s awesome work, in the form of ZenProfiler,  
> RubyInline, Ruby2c, etc.  
> [http://rubyforge.org/projects/zenhacks/](http://rubyforge.org/projects/zenhacks/)

> 1. Sessions - Separate server for managing Sessions if possible. I  
> would like to persist things in memory and share if possible. If not  
> possible, we’ll settle for persisting info to the database. Been  
> looking at Session affinity for Ruby some.  
> You can do this with DRb, which is extremely fast and handy.  
> Alternately, you can just store sessions in the DB, which is  
> convenient because it yields fewer ‘things’ to optimize and profile.

> 1. AJAX - Polling and Queuing system for AJAX interactions in  
> Javascript. Queing server side. Likely we will use and possibly extend  
> an existing AJAX library such as Mochikit or base it off another  
> existing one.  
> Have you taken a look at Zimbra? They have a very cool implementation  
> of this.  
> [http://www.zimbra.com/](http://www.zimbra.com/)

> 1. External Services - We may expose some web services in the future  
> or have internal web services. We may also be providing RSS feeds from  
> things like blogs or lists. We’ll use ReXML for our xml needs, but we  
> may switch to c++. I’ve heard performance concerns about REXML but have  
> yet to test for myself.  
> Even if ReXML didn’t serve your needs, you could use RubyInline to  
> re-implement slow parts of it in C, without tossing out all your  
> Ruby-ness.

> 1. Events/Threading - I am worried about Ruby here, especially after  
> reading about Myriad’s problems with libevent. We will definitely need  
> something similar to delegates and events and some good queueing and  
> threading functionality.  
> In my opinion, you should stay away from this kind of code in Ruby  
> until 2.0 is out. Luckily, it is easy to hook Ruby up to C code, and  
> you can write your performance-critical code in that language instead.  
> I’m glad that Myriad thread made it to the list. Very illuminating.

> We looked at Rails like everyone else but after using it a bit,  
> reading  
> the author’s blog, and from previous experience in other languages it  
> is clearly not suitable for the size and complexity of our application.  
> I also will reiterate that I hate O/R mapping unless it’s for a quick  
> personal app.  
> Well, the authors of Hibernate don’t agree with you. Heh. Are you  
> sure this personal preference is worth the development time cost?

> Concerns: Our main concern is of course scalability. Our AJAX controls  
> (many already finished) will need to poll the server in some cases over  
> a specified interval.  
> This is pretty much a non-issue in the CGI model. Just add more  
> webservers as needed. There are Rails sites doing 1M+ page requests a  
> day on only three cheap rackmount boxes. You should focus your  
> concern on the database. If your database can handle the load,  
> scaling Ruby / CGI is super easy.

> For instance, a purely hypothetical example might be we have a control  
> that lists online users along with status information.The controls  
> would need to requery information every 20 seconds to obtain fresh  
> information about the users (are they online? what is their current  
> mood? what did they last do?). This means that our server is going to  
> get hit a lot harder than your typical web application that serves up a  
> dynamic page, then sits idle until the user moves on to a new page.  
> Be very careful with this. There was a good article in ACM Queue  
> about this recently:  
> [http://acmqueue.org/modules.php?name=Content&pa=showpage&pid=337](http://acmqueue.org/modules.php?name=Content&pa=showpage&pid=337)  
> Google’s advice is to add as much delay between your client requests  
> as possible, and they use the auto-refresh concept as an example.

> We need to support a lot of simultaneous users  
> and I’m worried the process model needs to be perhaps replaced with a  
> threadpool/queing model (one that responds quick though).  
> Remember, Apache HTTPd uses the process model as well, and scales  
> pretty much as far as you want. In fact, I’d say that the process  
> model has in general been shown to be an easier scaling problem than  
> threading. It’s threads that I worry about. Processes are easy, and  
> can even be migrated to other systems at runtime, without stopping  
> them.

Let me leave you with the old adage: Don’t optimize prematurely.  
Developers are, in general, NOT good at predicting which pieces of  
code will end up being hit hardest. Don’t spend 6 months implementing  
an event queue only to find it using 1% of the total resources.  
Write the code in Ruby, profile it, rewrite the parts that are too  
slow.

Best of luck,  
–Wilson.

---

<div class="post-metadata">

**Author:** ![teslaomd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/7ba0ec/32.png) [@teslaomd](https://www.ruby-forum.com/u/teslaomd)\
**Post date:** [December 1, 2005, 11:44am UTC](https://www.ruby-forum.com/t/ruby-enterprise-app-design-advice/49141/3 "2005-12-01T11:44:09Z")

</div>

I have done web applications and I have done enterprise  
level  
apps but not enterprize level web apps of this scale. I do have quite  
some experience with databases though.

TeslaOMD wrote:

> I’ll try to oversimplify this in the interest of this post not being  
> more of a book than it already is. The software is actually a new idea  
> that I’m not going to reveal for creative reasons, but it is probably  
> closest to some of the existing social networking/dating apps. The app  
> must support over a million users (yes, this is realistic if not a  
> gross underestimate if all goes well). We expect to have several  
> thousand concurrent users. AJAX and querying DB data will play a heavy  
> role in the system. Users will have lots of preferences/settings to  
> manage/configure, most of which will be stored to disk as xml  
> (serialized objects perhaps?) rather than the database.

Did you consider writing user configs using YAML? It’s human readably  
and  
you don’t have to fiddle with XML mappings etc.

> 1. FastCGI or SCGI - We would like to replace FastCGI with something  
> else if possible since we have concerns about all of our processes  
> being constantly occupied by AJAX polling back to server code. We’re  
> not entirely convinced FastCGI is a great architecture for us but if  
> we do use it, we would like to scale it accross many servers and use a  
> SessionID to bind a user to a server. I worry about running out of  
> available FastCGI processes, even with multiple machines.

An architectural idea: since you want to use sessions to pin users to a  
certain instance and want to have a single session server (if I  
understand  
you correctly) you could set up your session server as DRB server that  
deals with login and logout and assigns an app server. App servers use  
DRB to register with the session server and also are DRB servers for  
FastCGI handlers. The FastCGI client programs are only small stubs that  
ask the session server for the app server and then connect to the app  
server and probably stream results back to the web client. There is  
room  
for optimization and tuning: mapping from session to app server can be  
cached to save one internal network communication. You are free to  
decide  
where to do the HTML generation - on the app server or more likely in  
the  
FastCGI program. To better utilize resources you can have several app  
servers per machine (i.e. several ruby processes that use different  
ports  
for DRB communication).

> 1. Database – MySQL or Postgres - We need transaction support and  
> data integrity – doubts about MySQL in these areas. We also need  
> good join performance - database is heavily normalized, may  
> denormalize if needed. Separate DBs for things like Logging/Auditing  
> vs. Content. Want to cluster DBs. We want connection pooling.  
> Considering making some modifications to DBI. Use stored procedures  
> in the database, no sql in the code/dynamic sql. I loathe O/R mappers  
> for complex databases and they would likely bring our system to a  
> screeching halt. Unfortunately we cannot afford to use Oracle right  
> now.

I don’t have experience with postgres and mysql. Given the fact that  
mysql is quite new and so are stored procedures and the way it deals  
with  
transactions I’d probably tend to use postgres.

> 1. Caching – We’ll cache user settings, DB data, etc. Need a good  
> ruby caching solution. Considering using memcached or something else  
> existing.

Difficult to comment on this without further detailing the app  
architecture. Just one remark: I would try to not cache DB content as  
databases do this already and they are usually quite good at doing this.

> 1. Sessions - Separate server for managing Sessions if possible. I  
> would like to persist things in memory and share if possible. If not  
> possible, we’ll settle for persisting info to the database. Been  
> looking at Session affinity for Ruby some.

see above.

> 1. AJAX - Polling and Queuing system for AJAX interactions in  
> Javascript. Queing server side. Likely we will use and possibly extend  
> an existing AJAX library such as Mochikit or base it off another  
> existing one.
> 
> 2. Remote - Looked at Drb for some remote things.

see above.

> 1. Events/Threading - I am worried about Ruby here, especially after  
> reading about Myriad’s problems with libevent. We will definitely need  
> something similar to delegates and events and some good queueing and  
> threading functionality.

If your FastCGI processes are lightweight then ruby threading is  
probably  
good enough.

Kind regards

```
robert
```

---

<div class="post-metadata">

**Author:** ![teslaomd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/7ba0ec/32.png) [@teslaomd](https://www.ruby-forum.com/u/teslaomd)\
**Post date:** [November 30, 2005, 6:56pm UTC](https://www.ruby-forum.com/t/ruby-enterprise-app-design-advice/49141/4 "2005-11-30T18:56:16Z")

</div>

Thanks for the reply Wilson. Pardon my mangled reply as well.

-I believe our plan is to just use MySQL and Postgres side by side for  
awhile. We’re going to be forced to double write things but that should  
not be too much extra work. We have some complex queries, for example  
we need to return 1-7 depths of a web network in a query (think  
friendster but a little more sophisticated. We’ve done the same thing  
in other projects, but the problem becomes tuning it to the database we  
select. I’m working on some scripts to start filling our tables with  
millions of rows so we can test this thing under a big data load from  
the start.

-We don’t want to use Rails though we may take ideas/parts where  
permission allows us to do so. I’ve looked a lot at Rails and would use  
it for a smaller app, but I don’t think it’s well suited to what we  
want to do. We’re experienced developers and prefer our own mess, plus  
we would like to show that there are alternative to Rails for using  
Ruby via the web. Others are doing the same. We also don’t like being  
tied into a framework – work with Spring, .NET, Struts, etc. has  
taught us that frameworks are great, but often too generic or generate  
too much work for specific tasks. Rails is no doubt a great framework,  
but not for us and I doubt it would scale to meet our needs rendering  
very complex templates and bringing back lots of DB data that an O/R  
mapper might choke trying to do.

-We don’t want to use an O/R mapper because of the complexity of a lot  
of our queries. I am a fan of SQL, and I’ve been certified in other DBs  
before so I know my way around the language. I like the idea of stored  
procedures (segregrating code in one place, reusing accross systems,  
assigning proper rights per procedure, caching, etc). Obviously some of  
this is dependent on our choice of DB, but regardless I prefer not to  
use stored procs. I’ve dealt a lot with O/R mappers in the past and  
performance tuning in Oracle and SQL Server 2000 and I can tell you  
that moving from stored procedures form an O/R mapper can make a world  
of difference. You spend a lot more time and maintenance, but you gain  
some more flexibility. Some people like the best of both worlds, but I  
prefer to keep set based operations to SQL in the DB server. I don’t  
want an O/R mapper touching my precious schema 🙂

-Our reason for not using ERb is a difficult one to understand without  
being involved in the project I admit. We need a system to allow users  
to upload their own themes. We also have a complex widget system (think  
portals) that may one day be nice to support on a thick client.  
Standard templating would be a lot of work per widget. I would rather  
design a templating system that works very fast and easy for what we  
need but requires more time up front. ERb reminds me of ASP days, no  
thanks. I’ve read David H.'s reasons for using ERb and I think they are  
valid, but not valid for us. I am not a fan of code in the template.  
That said, my developers and I are disciplined enough not to do  
anything bad in a template. ERb would be my third choice behind  
quicksilver.

-Thanks for the tip on Zimbra and the Zen profiler. Regarding the  
threading code and some of my fastcgi/ajax concerns, I think I could  
take a tip from Jetty and use Ruby continuations in conjunction with  
the response/request. Our group is very experienced with threading so I  
am not intimidated, but in the past I have dealt with the nightmares of  
deadlocks in particular as well as race conditions, memory bullying,  
etc. It seems to me like Ruby doesn’t have a lot of the nice things in  
Java and .NET to deal with some of the classic threading issues.

Thanks again for pointing me towards some projects I did not know  
about. Any other thoughts you have would be great because your feedback  
at the very least gets me questioning myself and new ideas flowing.  
FYI, like I think I mentioned we’ve used Ruby, just not in the context  
of a million user system.

---

<div class="post-metadata">

**Author:** ![teslaomd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/7ba0ec/32.png) [@teslaomd](https://www.ruby-forum.com/u/teslaomd)\
**Post date:** [December 1, 2005, 4:21pm UTC](https://www.ruby-forum.com/t/ruby-enterprise-app-design-advice/49141/5 "2005-12-01T16:21:22Z")

</div>

On Wednesday 30 November 2005 9:22 am, TeslaOMD wrote:

I’ve been doing web apps written in Ruby for businesses for years, now,  
based  
on the IOWA framework, and although none of them to date have been  
designed  
for the kind of scaling you describe, a couple are designed to scale  
across  
multiple machines. Now that you know where I am coming from…

> like some opinions directly from rubyists, rubycons, whatever. We’d  
> quick. Load balanced to send user to best server. Dedicated servers for  
> things like serving images.

I’m using it for an application used by a Fortune 500 company (lighttpd  
+  
fastcgi), and am very happy with it. Very fast, and reliable.

> 1. FastCGI or SCGI - We would like to replace FastCGI with something  
> else if possible since we have concerns about all of our processes  
> being constantly occupied by AJAX polling back to server code. We’re  
> not entirely convinced FastCGI is a great architecture for us but if we  
> do use it, we would like to scale it accross many servers and use a  
> SessionID to bind a user to a server. I worry about running out of  
> available FastCGI processes, even with multiple machines.

As others have mentioned, the multiprocess model does scale pretty well.  
My  
solution to the task of binding a user to a specific backend in a way  
that  
will scale across n machines is to use fcgi only as an intermediary.

The request hits lighttpd. lighttpd passes it along to the FCGI  
program.  
That program looks at the session ID, which has encoded into it the  
specific  
server/process that is handling that user’s session. The FCGI program  
passes  
the request on to the correct server/process for handling. If there is  
no  
session ID, it selects a server/process from the available pool. This  
can be  
a simple random selection, or there could be a more sophisticated  
technique  
employed that would try to do intelligent allocation.

The backend processes are themselves multithreaded using Ruby threads (I  
have  
abused Ruby threads pretty heavily while stress testing, and for this  
sort of  
thing, I have had absolutely no strange deadlocks or failures), and one  
can  
run n processes per server. Between the two layers one has a lot of  
flexibility for tuning. One can add more frontend machines (lighttpd +  
fcgi)  
or backend machines, or alter the number of fcgi or backend process  
independently. I am pretty confident that it is a cheaply scalable  
architecture that can handle large numbers of requests per second and  
concurrent requests, though this client is still using the app with only  
very  
modest traffic, so I don’t have anything more than speculation to offer,  
here.

> 1. Database – MySQL or Postgres - We need transaction support and data  
> integrity – doubts about MySQL in these areas. We also need good join  
> performance - database is heavily normalized, may denormalize if  
> needed. Separate DBs for things like Logging/Auditing vs. Content. Want  
> to cluster DBs. We want connection pooling. Considering making some  
> modifications to DBI. Use stored procedures in the database, no sql in  
> the code/dynamic sql. I loathe O/R mappers for complex databases and  
> they would likely bring our system to a screeching halt. Unfortunately  
> we cannot afford to use Oracle right now.

Depending on the OR mapper, it may work just fine with your db schema,  
but  
yeah, OR mapping has a runtime performance cost. It’s a matter for  
debate  
whether the performance cost is work the development time savings. In  
many  
(most, I think) cases, it is, but maybe on your app it is now.

As for MySQL/Pg, there are plenty of success stories with either. It’s  
mostly  
a preference/religious issue, unless one really needs a feature that  
isn’t  
available in both.

What modifications are you thinking about for DBI? We have a team in  
place  
now who will again be maintaining and working on DBI, and those I can’t  
speak  
for the others, I’d love to hear what you are thinking of doing. Maybe  
start  
a separate thread to discuss this?

> 1. Sessions - Separate server for managing Sessions if possible. I  
> would like to persist things in memory and share if possible. If not  
> possible, we’ll settle for persisting info to the database. Been  
> looking at Session affinity for Ruby some.

This is really completely dependent on how you do your backend. You can  
use  
Drb, but that does leave you with a single point of failure, and across  
your  
entire heavily used application, that single point could become a  
performance  
bottleneck.

You could keep each user’s session associated only with a specific  
server/process. No Drb bottleneck potential there, but if that process  
goes  
away, so does the session.

You could meet in the middle on that. Have all of your backends  
processes on  
a single machine store sessions in a Drb process, or have mini clusters  
of 2  
or 3 machines where all the backends on that mini cluster uses the same  
Drb  
process to store sessions.

> 1. Events/Threading - I am worried about Ruby here, especially after  
> reading about Myriad’s problems with libevent. We will definitely need  
> something similar to delegates and events and some good queueing and  
> threading functionality.

Ruby threading by itself really is solid. I have a _LOT_ of processes  
running  
which make use of threading, and since 1.8.x versions of Ruby, I have  
never  
had any problems with it. The Myriad/libevent issue with it boiled down  
to a  
simple implementation conflict, and isn’t an indictment of Ruby  
threading’s  
general usefulness.

> Concerns: Our main concern is of course scalability. Our AJAX controls  
> (many already finished) will need to poll the server in some cases over  
> a specified interval. We know that this is going to create some new  
> .  
> .  
> .  
> For instance, a purely hypothetical example might be we have a control  
> that lists online users along with status information.The controls  
> would need to requery information every 20 seconds to obtain fresh  
> information about the users (are they online? what is their current  
> mood? what did they last do?). This means that our server is going to

I’m looking at the logs for one of my apps that makes heavy use of AJAX.  
Most  
of them take between 2 and 6 thousandths of a second of time to run in  
the  
backend (IOWA) process. Your uses for AJAX might be slower than that,  
or  
they might not be, but the point is that AJAX type requests typically  
transmit and receive limited amounts of information, and trigger only  
very  
specific processing tasks. They are pretty fast. If you have 4000  
concurrent users, and each of their browsers is kicking of an AJAX  
request  
every 20 seconds, you’ll have around 200 requests per second. That does  
not  
seem like it should be too hard to support with a scalable architecture.  
Just keep your AJAX usage as efficient as possible, and pay attention to  
how  
that query interval affects performance. If 30 second intervals saves  
you X  
requests/second and thus Y machines, are 20 second intervals worth it?

> The read-write ratio in the app is probably about 70% read 30% write.  
> At any one time however we can expect the app is doing a significant  
> amount of writes to the DB but not compared to the amount of reads, so  
> keep this in mind. Our entire design needs to factor this into the  
> equation.

This may or may not skew your database selection. MySQL is particularly  
fast  
at reads, as opposed to writes.

Hope this helps.

Kirk H.

---

<div class="post-metadata">

**Author:** ![teslaomd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/7ba0ec/32.png) [@teslaomd](https://www.ruby-forum.com/u/teslaomd)\
**Post date:** [December 1, 2005, 4:37pm UTC](https://www.ruby-forum.com/t/ruby-enterprise-app-design-advice/49141/6 "2005-12-01T16:37:47Z")

</div>

On Thursday 01 December 2005 8:19 am, Kirk H. wrote:

Guh. Appologies for forgetting to trim the quoted sections of that  
post. Bad  
me. Bad.

Thanks,

Kirk H.

---

<div class="post-metadata">

**Author:** ![teslaomd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/7ba0ec/32.png) [@teslaomd](https://www.ruby-forum.com/u/teslaomd)\
**Post date:** [December 1, 2005, 5:49pm UTC](https://www.ruby-forum.com/t/ruby-enterprise-app-design-advice/49141/7 "2005-12-01T17:49:07Z")

</div>

Would XSLT be an option for templates? It is a webstandard, and you  
could do this in C/C++ or use an existing library.

---

<div class="post-metadata">

**Author:** ![teslaomd](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/7ba0ec/32.png) [@teslaomd](https://www.ruby-forum.com/u/teslaomd)\
**Post date:** [December 2, 2005, 4:07pm UTC](https://www.ruby-forum.com/t/ruby-enterprise-app-design-advice/49141/8 "2005-12-02T16:07:45Z")

</div>

Jules,

Unfortunately I don’t feel xslt is very human readable. Our current  
concept is a template system similar to XUL but much simpler. This way  
we can create a thick client and webpages without changing any of the  
controller code.