[thelist] New Server Configuration

Phil Turmel philip at turmel.org
Tue Aug 8 11:07:09 CDT 2006


Hershel Robinson wrote:
> I wrote to MySQL support:
> 
>  > > The project we are working on now is a complete rewrite of an 
> existing web app. The app in question needs to support an average 200 
> internal users (that's this year's estimate) all logged on and actively 
> using the system with estimated average of 2000 visits a day from 
> clients, including spikes of up to 2000 clients simultaneously logged in.
>  > >
>  > > We have a new RedHat server box (Linux
>  > > devbox1.xxxxxxxxxxxxxxx.com 2.6.9-34.ELsmp #1 SMP Fri Feb 24
>  > > 16:54:53 EST 2006 i686 i686 i386 GNU/Linux
>  > > ) being setup.
> 
> plus other details and I asked them in particular about the MySQL 
> version they recommend and configuration / DB schema issues. One part of 
> the response was:
> 
>  > I think the biggest problem for you will be your 32 bit hardware.  It
>  > will be very difficult to handle 2,000 simultaneous connections because
>  > you have a 3GB per process addressing limit.  We will have to set the
>  > per connection buffers (read_buffer, sort_buffer etc.) very small while
>  > also keeping the global buffers pretty small to stay under 3GB in total.
> 
> Can anyone comment on this? I am aware of the 3GB limit for a 32bit 
> machine, but I am not aware of the issues this may imply with regards to 
> performance.

Hershel,

Serving 2000 simultaneous DB connections will kick 32-bit MySQL in the 
teeth.  However, the actual number of simultaneous connections can be 
managed to a much lower number with proper app design.  In particular, 
you need to pay carefull attention to connection pooling and/or 
persistent connections.  It is also important for each web script to 
perform all business logic DB requests, release the DB connection, then 
perform all output formatting.  Model-View-Controller frameworks help 
with this, but you can do it by hand if necessary.

One other consideration:  if you implement security for the 2200+ users 
via database permissions, you won't be able pool the connections.  If 
you roll your own security so only a single database login is required 
for the app, all connections can all be pooled.  Then, the number of 
connections required will follow the page hit rate, not the number of 
sessions.

Apache creates numerous child processes to handle requests, each of 
which gets a 3GB address space.  You shouldn't have any problems there, 
other than adjusting the corresponding config settings to allow enough. 
(I know, I shouldn't assume you're using Apache...)

If you can generate some numbers on page hits per minuter per user, and 
typical page execution times, the performance requirements will be more 
clear.

HTH,

Phil





More information about the thelist mailing list