You might want to convert it to C or Perl and compile the PERL code or etc -
that would be an easy way to decrease some of the loadup time for the PHP
code--additionally I believe there is an option in teh php3.ini file so you
can turn off the debugging in the parsing since you know all of your scripts
currently work- It makes it so you can't really develop on the server too
well since it won't have the debugging parsing giong on - but if you know
the code works it will decrease the parse time a bit
Eric
----- Original Message -----
From: Adam Powell <adam@stripped>
To: <mysql@stripped>
Cc: Gurbaksh Chahal <gurbaksh@stripped>; Tajinder Chahal
<tajinder@stripped>
Sent: Tuesday, June 22, 1999 11:31 AM
Subject: Re: 3.23
>
> Yes I agree, it is a question of looking at the system, and finding the
> problems and eliminating these bottlenecks... however we are severely
short
> staffed at the moment, and we are looking for somebody to spare some time
to
> telnet to the server, learn about our system and help reduce the load on
the
> server and hopefully make it scalable for the future... I spoke to Monty
> about this, but the support is kinda expensive... would anybody be
> interested in this kind of thing, and what kind of prices are we looking
at?
>
> Basically, what we have is a banner rotation script written in PHP (v3.0.6
> to be exact), this is connecting to the database server with information
> about the banner, the site it is on, and retrieving a shortlist of banners
> to be displayed and selecting one at random. There are many factors about
> banner availability, subject area and hits/clicks per day to take into
> accounts... its a 250 line script and not easy to understand by any
means..
>
> However this script was running half a million times a day, and it was
> fine... now its running 7 million times a day and causing no end of
> problems!
>
> If anybody is interested in helping, or knows about this kind of thing
then
> please get in touch!
>
> Thanks,
> Adam Powell,
> CTO - Click Agents Corp.,
> Web : http://www.clickagents.com
> Email : adam@stripped
> Tel : (408)-453-3577
>
> ----- Original Message -----
> From: Sasha Pachev <sasha@stripped>
> To: Adam Powell <adam@stripped>
> Cc: Chris Unger <cunger@stripped>; <mysql@stripped>
> Sent: Tuesday, June 22, 1999 4:59 AM
> Subject: Re: 3.23
>
>
> > Adam Powell wrote:
> > >
> > > I have a mission-critical application that is basically COMPLETELY
> > > overloaded... the load on the server is 12 and I need to do something
> about
> > > it. I am currently using mySQL 3.22.20a - do you think upgrading to
the
> > > latest version is a good idea or not? Is 3.
> > > 23 safe enough to start using?
> > >
> > > Adam
> > >
> >
> > Adam:
> >
> > There are certain issues that cannot be resolved with just an upgrade.
> > For example, if your tables are set up in such a way that majority of
> > your queries do a full table scan, an upgrade will help only if it will
> > help you get rid of having to scan the table.
> >
> > I would recommend a careful system analysis to determine the bottlenecks
> > and remove them one by one. Some common problems:
> >
> > - Not having an index
> > - Using varachar when you could have used char
> > - Using char when you could have used int ( eg. for an IP address)
> > - MySQL buffers either too big or too small
> > - Poorly written queries
> > - Not having your tables normalized
> > - Inefficient algorithms in the application code
> >
> > Aside from that:
> >
> > - Your system could be running out of RAM
> > - You may not have enough bandwidth to deal with your traffic
> >
> > Good design and well-written code can keep you from having to upgrade.
> > Remember that a O(exp(n)) algorithm will not run well even on the most
> > powerful system in the world for reasonably large values of n.
> >
> > --
> > Sasha Pachev
> > http://www.sashanet.com/ (home)
> > http://www.direct1.com/ (work)
> >
>
>
> ---------------------------------------------------------------------
> Please check "http://www.mysql.com/Manual_chapter/manual_toc.html" before
> posting. To request this thread, e-mail mysql-thread5643@stripped
>
> To unsubscribe, send a message to the address shown in the
> List-Unsubscribe header of this message. If you cannot see it,
> e-mail mysql-unsubscribe@stripped instead.
>
