Re: [WebDNA] Apple Server

This WebDNA talk-list message is from

2013


It keeps the original formatting.
numero = 110357
interpreted = N
texte = --Apple-Mail=_4DE6DDCB-93A3-4794-8103-8C57275FD793 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 25 Apr 2013, at 16:41, Alex McCombie wrote: > On Apr 25, 2013, at 11:20 AM, Paul Willis wrote: >=20 >> 1) MySQL would dump the expired query cache for a query that got a = lot of requests (as it should the data had been updated and the cache = was old) but it took too long to process and a queue of the same big = query quickly built up from which it could not recover, just as you = describe. >>=20 > Interesting, but how did you resolve this if it was indeed causing a = slowdown? We changed the way the site worked for the panel that called that query, = it was a while ago now so my mind is a bit hazy but it was something = like a 'most viewed articles' panel. Instead of being 'live' we made it = cache for a day or similar. >> Another option which might help (which we did) is to split the MySQL = off onto it's own server >> Paul >>=20 > Also interesting, but if the problem was squarely on MYSQL, then I'm = not sure how having it separated would help all that much. Maybe free up = a few CPU ticks from apache. The web server was tweaked to be better for apache, serving lots of = small files and the db server configured to be better for MySQL, more = RAM etc. > The move to OSX was as much about getting me into something I had more = experience with admittedly as anything else.=20 We found that with old versions of Apple Server (don't know what it's = like in later versions) we ended up having to learn terminal stuff to = bypass the limitations of the GUI tools. Once we got the hang of it and = became terminal geeks we found we actually preferred it that way. All = the stuff we learned in OS X terminal transferred over to Ubuntu nicely. > I am intrigued though that you were having similar issues.=20 >=20 > What was your ultimate resolution? Did you find a bad query? Was it = the cache dump primarily? Or an overtaxed server? > Chasing this thing has been like chasing shadows. You think you got it = and then 3 hrs later its back. It wasn't one solution it was an ongoing combination of things. We = changed the way queries worked, we eliminated slow queries by rewriting = them properly, we took the load off the server by splitting it. I do feel for you though. We had the same thing, thinking you had nailed = the issue but then it suddenly reappearing a few days later. As you = eliminate one issue the next one rears it's head and all the time the = goalposts are moving as traffic increases and new features are added to = the site. Paul --Apple-Mail=_4DE6DDCB-93A3-4794-8103-8C57275FD793 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 25 Apr 2013, at 16:41, Alex McCombie <info@adventureskies.com> = wrote:

On Apr 25, 2013, at 11:20 AM, Paul Willis <paul.willis@me.com> = wrote:

1) MySQL would dump the expired query cache for a query = that got a lot of requests (as it should the data had been updated and = the cache was old) but it took too long to process and a queue of the = same big query quickly built up from which it could not recover, just as = you describe.

Interesting, = but how did you resolve this if it was indeed causing a = slowdown?

We changed = the way the site worked for the panel that called that query, it was a = while ago now so my mind is a bit hazy but it was something like a 'most = viewed articles' panel. Instead of being 'live' we made it cache for a = day or similar.


Another option which might = help (which we did) is to split the MySQL off onto it's own = server
Paul

Also = interesting, but if the problem was squarely on MYSQL, then I'm not sure = how having it separated would help all that much. Maybe free up a few = CPU ticks from apache.

The = web server was tweaked to be better for apache, serving lots of small = files and the db server configured to be better for MySQL, more RAM = etc.


The move to OSX was as = much about getting me into something I had more experience with = admittedly as anything = else. 

We found that = with old versions of Apple Server (don't know what it's like in later = versions) we ended up having to learn terminal stuff to bypass the = limitations of the GUI tools. Once we got the hang of it and became = terminal geeks we found we actually preferred it that way. All the stuff = we learned in OS X terminal transferred over to Ubuntu = nicely.


I am intrigued though = that you were having similar issues. 

What = was your ultimate resolution? Did you find a bad query? Was it the cache = dump primarily? Or an overtaxed server?
Chasing this thing has = been like chasing shadows. You think you got it and then 3 hrs later its = back.

It wasn't one = solution it was an ongoing combination of things. We changed the way = queries worked, we eliminated slow queries by rewriting them properly, = we took the load off the server by splitting = it.

I do feel for you though. We had the same = thing, thinking you had nailed the issue but then it suddenly = reappearing a few days later.  As you eliminate one issue the = next one rears it's head and all the time the goalposts are moving as = traffic increases and new features are added to the = site.

Paul



= --Apple-Mail=_4DE6DDCB-93A3-4794-8103-8C57275FD793-- Associated Messages, from the most recent to the oldest:

    
  1. Re: [WebDNA] Apple Server (Paul Willis 2013)
  2. Re: [WebDNA] Apple Server (Alex McCombie 2013)
  3. Re: [WebDNA] Apple Server (Paul Willis 2013)
  4. Re: [WebDNA] Apple Server (Alex McCombie 2013)
  5. Re: [WebDNA] Apple Server (Paul Willis 2013)
  6. Re: [WebDNA] Apple Server (Alex McCombie 2013)
  7. Re: [WebDNA] Apple Server (Paul Willis 2013)
  8. Re: [WebDNA] Apple Server (Alex McCombie 2013)
  9. Re: [WebDNA] Apple Server (Donovan Brooke 2013)
  10. [WebDNA] Apple Server (Alex McCombie 2013)
--Apple-Mail=_4DE6DDCB-93A3-4794-8103-8C57275FD793 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 25 Apr 2013, at 16:41, Alex McCombie wrote: > On Apr 25, 2013, at 11:20 AM, Paul Willis wrote: >=20 >> 1) MySQL would dump the expired query cache for a query that got a = lot of requests (as it should the data had been updated and the cache = was old) but it took too long to process and a queue of the same big = query quickly built up from which it could not recover, just as you = describe. >>=20 > Interesting, but how did you resolve this if it was indeed causing a = slowdown? We changed the way the site worked for the panel that called that query, = it was a while ago now so my mind is a bit hazy but it was something = like a 'most viewed articles' panel. Instead of being 'live' we made it = cache for a day or similar. >> Another option which might help (which we did) is to split the MySQL = off onto it's own server >> Paul >>=20 > Also interesting, but if the problem was squarely on MYSQL, then I'm = not sure how having it separated would help all that much. Maybe free up = a few CPU ticks from apache. The web server was tweaked to be better for apache, serving lots of = small files and the db server configured to be better for MySQL, more = RAM etc. > The move to OSX was as much about getting me into something I had more = experience with admittedly as anything else.=20 We found that with old versions of Apple Server (don't know what it's = like in later versions) we ended up having to learn terminal stuff to = bypass the limitations of the GUI tools. Once we got the hang of it and = became terminal geeks we found we actually preferred it that way. All = the stuff we learned in OS X terminal transferred over to Ubuntu nicely. > I am intrigued though that you were having similar issues.=20 >=20 > What was your ultimate resolution? Did you find a bad query? Was it = the cache dump primarily? Or an overtaxed server? > Chasing this thing has been like chasing shadows. You think you got it = and then 3 hrs later its back. It wasn't one solution it was an ongoing combination of things. We = changed the way queries worked, we eliminated slow queries by rewriting = them properly, we took the load off the server by splitting it. I do feel for you though. We had the same thing, thinking you had nailed = the issue but then it suddenly reappearing a few days later. As you = eliminate one issue the next one rears it's head and all the time the = goalposts are moving as traffic increases and new features are added to = the site. Paul --Apple-Mail=_4DE6DDCB-93A3-4794-8103-8C57275FD793 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 25 Apr 2013, at 16:41, Alex McCombie <info@adventureskies.com> = wrote:

On Apr 25, 2013, at 11:20 AM, Paul Willis <paul.willis@me.com> = wrote:

1) MySQL would dump the expired query cache for a query = that got a lot of requests (as it should the data had been updated and = the cache was old) but it took too long to process and a queue of the = same big query quickly built up from which it could not recover, just as = you describe.

Interesting, = but how did you resolve this if it was indeed causing a = slowdown?

We changed = the way the site worked for the panel that called that query, it was a = while ago now so my mind is a bit hazy but it was something like a 'most = viewed articles' panel. Instead of being 'live' we made it cache for a = day or similar.


Another option which might = help (which we did) is to split the MySQL off onto it's own = server
Paul

Also = interesting, but if the problem was squarely on MYSQL, then I'm not sure = how having it separated would help all that much. Maybe free up a few = CPU ticks from apache.

The = web server was tweaked to be better for apache, serving lots of small = files and the db server configured to be better for MySQL, more RAM = etc.


The move to OSX was as = much about getting me into something I had more experience with = admittedly as anything = else. 

We found that = with old versions of Apple Server (don't know what it's like in later = versions) we ended up having to learn terminal stuff to bypass the = limitations of the GUI tools. Once we got the hang of it and became = terminal geeks we found we actually preferred it that way. All the stuff = we learned in OS X terminal transferred over to Ubuntu = nicely.


I am intrigued though = that you were having similar issues. 

What = was your ultimate resolution? Did you find a bad query? Was it the cache = dump primarily? Or an overtaxed server?
Chasing this thing has = been like chasing shadows. You think you got it and then 3 hrs later its = back.

It wasn't one = solution it was an ongoing combination of things. We changed the way = queries worked, we eliminated slow queries by rewriting them properly, = we took the load off the server by splitting = it.

I do feel for you though. We had the same = thing, thinking you had nailed the issue but then it suddenly = reappearing a few days later.  As you eliminate one issue the = next one rears it's head and all the time the goalposts are moving as = traffic increases and new features are added to the = site.

Paul



= --Apple-Mail=_4DE6DDCB-93A3-4794-8103-8C57275FD793-- Paul Willis

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

Problems getting parameters passed into email. (1997) Date problems-more (1997) MOOOOOO (2000) Trouble with carts (2000) [WebDNA] lists opinion (2009) return two fields w/ [lookup] (1998) WAP (2000) Running _every_ page through WebCat ? (1997) Follow-up to listfiles bug report ... (2003) Saving Text Areas with Orders (1997) Formating found categories (1997) Netscape 3.01 can't see db in form (1997) Problem with CC problem ? (1997) Problems with SELECT MULTIPLE (1999) unsubscribe (1997) carriage returns in data (1997) unique ascending numbers (2003) Expert tech support -- a fast and simple solution (long) ... (2000) (1997) Databases inside [SHOWIF] (1998)