<div dir="ltr"><div dir="ltr">Thanks. Paul.<br clear="all"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><br></div><div>Indeed, we've been improving a lot around block complexity, especially when iterating through large collections. Our code is often just not optimally written and this is where significant gains are. The system is big and it will take time to fix all these issues. In the meantime, we would just like to handle the situation better and avoid requests routed to the wrong upstream (GS session).</div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 20, 2023 at 3:48 PM Paul Baumann <<a href="mailto:plbaumann@gmail.com">plbaumann@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir="auto">Use VSD to see if tempObjSpace improvement coincides with the delay (by a reclaim). Even if your application code isn't creating and disposing of many objects, it is a traditional GS issue that iteration of a complex block will. GS since 3.0 is supposed to have made improvements to this, but I've never verified that. My experience was more with building a framework that allowed application code to be changed to use only simple blocks, often with over a 90% reduction in execution time (and no occasional slowness) once ALL complex blocks are eliminated from tuned code.<br><br></div><br><br><div class="gmail_quote"><div dir="auto">On December 20, 2023 7:04:20 AM EST, Otto Behrens via Glass <<a href="mailto:glass@lists.gemtalksystems.com" target="_blank">glass@lists.gemtalksystems.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Hi,<div><br></div><div>We are using nginx to load balance in front of GemStone that runs a Seaside application. Some of our requests run too long (we are working hard to cut them down) and in general, the time it takes to service a request in our application varies between 0.1 and about 4 seconds. We are improving and getting more towards the lower end of that. </div><div><br></div><div>Because of this, we use the least_conn directive and we persist session state so that we could use any of our GemStone upstream sessions to service a request. Requests are generally load balanced to idle sessions and there are theoretically no requests that wait for another to get serviced. Perhaps this is not optimal and you have better suggestions. It has worked ok for a long time, but should we consider another approach?</div><div><br></div><div>When our code misbehaves and a request takes let's say 60 seconds to handle, things go pear shaped (yes we want to eliminate them). The user clicks "back" on the browser or closes the browser and nginx picks it up with: </div><div>"epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too while sending request to upstream"<br></div><div><br></div><div>We suspect our problem is: when this happens, it appears as if nginx then routes requests to that same upstream, which is unable to handle it because it is busy handling the previous request (which is taking too long), even with some upstream sessions sitting idle. Some users then end up with no response.</div><div><br></div><div>Ideally, we would like to catch the situation in the GemStone session and stop processing the request (when nginx closes the upstream connection). Alternatively, we could set timeouts long enough so that if the browser prematurely closes the connection, nginx does not close the upstream connection. </div><div><br></div><div>Do you have a suggestion to handle this? Does it make sense to get timeouts (which ones?) to align so that this does not happen?</div><div><br></div><div>Thanks a lot</div><div><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><table width="600" cellpadding="0" cellspacing="0" border="0" style="color:rgb(0,0,0);font-family:Times;font-size:medium"><tbody><tr><td width="400" valign="bottom"><p style="margin:0px;padding:0px"><span style="font-size:18px;color:rgb(146,148,151);font-family:Calibri,sans-serif;font-weight:700">Otto Behrens</span><br></p><p style="font-size:18px;font-weight:700;color:rgb(146,148,151);font-family:Calibri,sans-serif;margin:0px;padding:0px"><span style="font-size:14px;font-weight:300;margin:0px;padding:0px">+27 82 809 2375</span></p></td><td width="200" valign="middle"><img src="https://www.finworks.biz/signature/finworks-signature-logo.png" width="200" height="38" alt="FINWorks" style="display: block; border: 0px; width: 200px; height: 38px; margin: 0px; padding: 0px;"></td></tr></tbody></table><table width="600" cellpadding="0" cellspacing="0" border="0" style="color:rgb(0,0,0);font-family:Times;font-size:medium"><tbody><tr><td height="5"></td></tr></tbody></table><table width="600" cellpadding="0" cellspacing="0" border="0" style="color:rgb(0,0,0);font-family:Times;font-size:medium;border-bottom:1px solid rgb(200,28,36)"><tbody><tr><td height="15"></td></tr></tbody></table><table width="600" cellpadding="0" cellspacing="0" border="0" style="color:rgb(0,0,0);font-family:Times;font-size:medium"><tbody><tr><td height="20"></td></tr></tbody></table><table width="600" cellpadding="0" cellspacing="0" border="0" style="color:rgb(0,0,0);font-family:Times;font-size:medium"><tbody><tr><td width="15" valign="top" style="display:inline-block"><a href="http://za.linkedin.com/in/waltherbehrens" style="color:rgb(17,85,204)" target="_blank"><img src="https://www.finworks.biz/signature/finworks-linkedin-logo.png" width="15" height="15" alt="FINWorks" style="display: inline-block; border: 0px; width: 15px; height: 15px; margin-top: 1.5px; padding: 0px;"></a></td><td width="250" valign="top" style="display:inline-block"><a href="http://www.finworks.biz/" style="color:rgb(200,28,36);font-family:Calibri,sans-serif;margin-left:10px;margin-top:0px;padding-top:0px;font-size:11pt;display:inline-block" target="_blank">www.finworks.biz</a></td></tr></tbody></table><table width="600" cellpadding="0" cellspacing="0" border="0" style="color:rgb(0,0,0);font-family:Times;font-size:medium"><tbody><tr><td height="10"></td></tr></tbody></table><table width="600" cellpadding="0" cellspacing="0" border="0" style="color:rgb(0,0,0);font-family:Times;font-size:medium"><tbody><tr><td><p style="font-size:10px;color:rgb(146,148,151);font-family:Calibri,sans-serif;text-align:justify">Disclaimer & Confidentiality Note: This email is intended solely for the use of the individual or entity named above as it may contain information that is confidential and privileged. If you are not the intended recipient, be advised that any dissemination, distribution or copying of this email is strictly prohibited. FINWorks cannot be held liable by any person other than the addressee in respect of any opinions, conclusions, advice or other information contained in this email.</p></td></tr></tbody></table></div></div></div></div></div></div></div>
</blockquote></div></div></blockquote></div></div>