Re: Migrating to static structure?

[vladb]

There's a quick solution and that is in buying more actual hardware to boost your server performance. Things such as faster HD and larger (also faster) memory chips. Another option is to purchase another server and set up a 'round robin' system. In such a system, you'll have 2 main servers and one extra PC to serve as a load balancer. All request to your sites come through that load balancer. It's job is simply to monitor the loads on both supporting 'web' servers and direct traffic where it will be accomodated the best.

Aside from this, you've got to have a close estimate of specific components involved in your system and their cost in terms of overall performance. mod_perl could generally be optimized pretty well to handle even 100 symultaneous sessions. Check out this mod_perl: Performance Tuning article for example. You should find quite a few things that you might of missed from your existing set up. Just add those ones and see your performance improve! ;-)

_____________________

# Under Construction

[Anonymous Monk]

Thanks for your reply.
Load balancing is not a solution as we already have it (done with F5 directing traffic to 4 PIII/600Mhz www Dell machines and 3 similiar MySQL servers).
mod_perl tuning is also not a solution - giving these SELECTS manually from mysql client takes similiar ammount of time (up to 2 seconds for 1 SELECT), so probably it won't speed us up too much :-(
Redesiging the MySQL structure? Hmm, maybe, but I'm not in the mood of rewriting 3MB of Perlcode right now.
Another solution that comes to my head is some kind of cache, but as for now no idea how it should look...


Thanks, Peter

[ignatz]

3MB??!!

It's bloated size ( /. 3k, PerlMonks 6k, Salon 1.3MB ) is all the more reason to refactor. If it is not worth it, it should be scrapped all together. No matter what, it sounds like a cache is the only thing that would really help in the mean time.

()-()
 \"/
  `                                                     

[pit]

Yeap,

[pit@tux devel]$ du -s cgi-local
3032 ./cgi-local

Ok, probably some scraps are there too, but it's at least about 2.5MB (I'm counting here all the scripts, custom modules and libraries)

Peter

[Tomte]

As a polite question from someone fallen in this pit once: Are you sure the indexes/indices(sp?) set for the tables are used in your queries?
It seems unbelievable how well a database can operate if the indices set match the queries made. (From >10sec to <0.02 in my case for )

another option is to look, if you can optimize the database-server itself, if not alreday done, to better accomodate to your special circumstances.

Maybe a look into the slashcode or everything helps you find a cache solution.

regards,
tomte

[pit]

Yeap, all the indices are set for the tables.
The problem is, that some of these selects are making joins from 3-5 tables and that's probably slows MySQL down.
DB servers are also kinda full-blown (as for current budget, running at PIII/600Mhz and 1GB of memory (this "slow" db is about 150MB big)).
We were concidering switching to PostgreSQL as it was slighty faster with these "5-lines-long-SELECTS" but on the other hand we're using the same MySQL servers with great MySQL preformance for our search engine (Postgres was not so good at fulltext search).

Peter