Re: WebCatalog Eating 200% of the CPU

This WebDNA talk-list message is from

2002


It keeps the original formatting.
numero = 44857
interpreted = N
texte = Someone discounted this earlier but I thought I'd post a tid-bit. (since the maker of our software now works for blueworld).There has been a long and on-going thread about CPU cycling (CPU hog) on the webStar list. Lasso has come up in the thread quite often. Here is what CJ (lead programmer) last said about it. ______________________________________________________________ On Monday, November 4, 2002, at 04:10 PM, Stephen Lewis wrote:> When WSWebServer process was hogging (by looking at TOP), lsof > revealed a > few oddities, perhaps they mean something, perhaps not: > > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > > There were a couple of these: > WSWebServ 9788 webstar 51u inet 0t0 TCP no > PCB, > CANTSENDMORE, CANTRCVMORE > > But more interestingly there were SEVERAL of these: > WSWebServ 9788 webstar 43u inet 0x060c3a4c 0t0 TCP > localhost:51297->localhost:14550 (CLOSE_WAIT) > WSWebServ 9788 webstar 54u inet 0x062114cc 0t0 TCP > localhost:51059->localhost:14550 (CLOSE_WAIT)Our current theory, which seems to be confirmed by the folks at BlueWorld, is that there's a problem with the loop that Lasso uses to read data from HTTP client connection. (The usual didn't break from loop when 0 bytes are received issue.) This is causing some infinite loops in multiple threads. Meanwhile, connections to the Lasso server are still outstanding. I'm guessing that either the server is timing out these connections, or the communication with Lasso server is already finished and the plug-in is just reading extra data off of the connection (which is the proper thing to do). Either way, you get these cpu hogging threads on the one hand, and half-closed connections on the other.We have a new build for our beta testers, and we'll let people know as this progresses. We changed our API to let Lasso know explicitly when the HTTP client connection closes, and BlueWorld says they'll change the loop on their end, too.cjh ______________________________________________________________Hope this helps, DonovanScott Anderson wrote:> TIME > ELAPSED-TIME > AVAILABLE MEMORY > CLIENT ADDRESS > PATH ARGUMENTS > PHYSICAL TEMPLATE PATH > CLIENT AGENT > USERNAME > PASSWORD > REFERRER > TEMPLATE NAME > DOC ROOT PREFIX > FORM DATA > COOKIE DATA > MIME HEADERS > > There is a bug with the ELAPSED-TIME data, it is tracked globally and is > therefore not accurate when running in multithreaded mode. > > You should also enable the 'Error Logging' pref. This will log any WebDNA > errors that occur during template processing.-- Donovan D. Brooke Administrator of IT/ Assc. Art Director Epsen Hillmer Graphics HG Professional Forms ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/ Associated Messages, from the most recent to the oldest:

    
  1. Re: WebCatalog Eating 200% of the CPU (Dale LaFountain 2002)
  2. Re: WebCatalog Eating 200% of the CPU (Aaron Lynch 2002)
  3. Re: WebCatalog Eating 200% of the CPU (Scott Anderson 2002)
  4. Re: WebCatalog Eating 200% of the CPU (Donovan Brooke 2002)
  5. Re: WebCatalog Eating 200% of the CPU (Donovan Brooke 2002)
  6. Re: WebCatalog Eating 200% of the CPU (Dale LaFountain 2002)
  7. Re: WebCatalog Eating 200% of the CPU (Alain Russell 2002)
  8. Re: WebCatalog Eating 200% of the CPU (Scott Anderson 2002)
  9. Re: WebCatalog Eating 200% of the CPU (Jesse Williams-Proudman 2002)
  10. Re: WebCatalog Eating 200% of the CPU (Scott Anderson 2002)
  11. Re: WebCatalog Eating 200% of the CPU (Alain Russell 2002)
  12. Re: WebCatalog Eating 200% of the CPU (Jesse Williams-Proudman 2002)
  13. Re: WebCatalog Eating 200% of the CPU (Alain Russell 2002)
  14. WebCatalog Eating 200% of the CPU (Jesse Williams-Proudman 2002)
Someone discounted this earlier but I thought I'd post a tid-bit. (since the maker of our software now works for blueworld).There has been a long and on-going thread about CPU cycling (CPU hog) on the webStar list. Lasso has come up in the thread quite often. Here is what CJ (lead programmer) last said about it. ______________________________________________________________ On Monday, November 4, 2002, at 04:10 PM, Stephen Lewis wrote:> When WSWebServer process was hogging (by looking at TOP), lsof > revealed a > few oddities, perhaps they mean something, perhaps not: > > COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME > > There were a couple of these: > WSWebServ 9788 webstar 51u inet 0t0 TCP no > PCB, > CANTSENDMORE, CANTRCVMORE > > But more interestingly there were SEVERAL of these: > WSWebServ 9788 webstar 43u inet 0x060c3a4c 0t0 TCP > localhost:51297->localhost:14550 (CLOSE_WAIT) > WSWebServ 9788 webstar 54u inet 0x062114cc 0t0 TCP > localhost:51059->localhost:14550 (CLOSE_WAIT)Our current theory, which seems to be confirmed by the folks at BlueWorld, is that there's a problem with the loop that Lasso uses to read data from HTTP client connection. (The usual didn't break from loop when 0 bytes are received issue.) This is causing some infinite loops in multiple threads. Meanwhile, connections to the Lasso server are still outstanding. I'm guessing that either the server is timing out these connections, or the communication with Lasso server is already finished and the plug-in is just reading extra data off of the connection (which is the proper thing to do). Either way, you get these cpu hogging threads on the one hand, and half-closed connections on the other.We have a new build for our beta testers, and we'll let people know as this progresses. We changed our API to let Lasso know explicitly when the HTTP client connection closes, and BlueWorld says they'll change the loop on their end, too.cjh ______________________________________________________________Hope this helps, DonovanScott Anderson wrote:> TIME > ELAPSED-TIME > AVAILABLE MEMORY > CLIENT ADDRESS > PATH ARGUMENTS > PHYSICAL TEMPLATE PATH > CLIENT AGENT > USERNAME > PASSWORD > REFERRER > TEMPLATE NAME > DOC ROOT PREFIX > FORM DATA > COOKIE DATA > MIME HEADERS > > There is a bug with the ELAPSED-TIME data, it is tracked globally and is > therefore not accurate when running in multithreaded mode. > > You should also enable the 'Error Logging' pref. This will log any WebDNA > errors that occur during template processing.-- Donovan D. Brooke Administrator of IT/ Assc. Art Director Epsen Hillmer Graphics HG Professional Forms ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://search.smithmicro.com/ Donovan Brooke

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:

[sendmail] on NT? (1997) [searchString] (1997) 2.0 Beta (1997) Generating Report Totals (1997) select multiple 2 more cents (1997) Taxes shipcost (2003) Mac: [ListFiles] bug alert (1997) Loss in form (1998) using webdna to determine pixel parameters (2000) PCS Emailer's role ? (1997) Great product and great job ! (1997) Table Loop Hoops (2000) Reversed words (1997) Access Denied! But why? (1997) price formula (1999) More on the email templates (I like it) (1997) ShowNext - HELP! (2000) Alternating BGColors in Table Rows (1998) UPS online tools assuming one package per item no matterthequantity. (2003) [WebDNA] OT: WebDNA Host required (2008)