[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