[Opensim-users] Slow handling of POST -

Sat Sep 29 23:36:57 UTC 2012

=====================================
I switched back to linux with my osgrid region.
I have some strange sideeffect on my train megasim, as soo the train is 
rideing and am on the sim it seems to crash pretty fast
with a nice stacktrace and above that some slow requests on serveral parts.

22:16:02 - [BASE HTTP SERVER]: Slow handling of 498 POST /CAPS/ ......  
took 5708ms
22:16:05 - [BASE HTTP SERVER]: Slow handling of 505 POST /CAPS/ ...... 
took 4644ms
22:17:35 - [FORMS]: Slow request 45 POST ........ took 100125ms,
23:19:17 - [FORMS]: Slow request 138 POST.......  took 100024ms,
23:19:58 - [USER AGENT CONNECTOR]: Unable to contact remote server 
...... for GetServerURLs
Region (root) # Stacktrace:

Native stacktrace:

         mono() [0x498a19]
         mono() [0x4e999f]
         mono() [0x41f617]
         /lib64/libpthread.so.0(+0xf140) [0x7effa5a6c140]
         mono() [0x5e04d9]
         mono() [0x5dd4a0]
         mono() [0x5e0cfc]
         mono() [0x5e15d2]
         mono() [0x5e1c07]
         mono() [0x5e263d]
         mono() [0x5dc292]
         mono() [0x5dc575]
         mono() [0x5dc7ee]
         mono(mono_array_new_specific+0xe2) [0x590602]
         [0x4186fd7d]

Debug info from gdb:

So have done a bit searching, thereare  maby a few hints.
I try to explain it best i can, hope 1 of them is direction to the solution.
Its maby more a collection of ideas , more the needle in the hay.
Not C# expert, but what i see the request code is pretty basic.
The one opensim uses looks a bit like whats used on
**********

http://www.codeproject.com/Articles/13486/A-Simple-Crawler-Using-C-Sockets#WebRequest
and look at the section, "2. *WebRequest and WebResponse problems:" *am 
quoting a piece of text from that website

**********
HttpWebRequest.GetResponse Method seems to block.

the Microsoft page say the following: 
http://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.getresponse%28v=vs.71%29.aspx
""This method blocks waiting for content to post; if there is no 
time-out set and you do not provide content, your application will block 
indefinitely.""

**********

Maby the ServicePointManager.Expect100Continue Property is intressting 
to use ? 
http://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.expect100continue%28v=vs.71%29.aspx

**********
last thing that i want to point to is this site 
http://stackoverflow.com/questions/2519655/httpwebrequest-is-extremely-slow
The talk about that the http proxy is enabled default, and that disable 
it can speed up the process.
Most of the above things come from this page.

=====================================

On 2012-09-22 02:22, Justin Clark-Casey wrote:
> There are no timeouts on these particular requests, which probably 
> isn't a good thing - OpenSimulator is inconsistent when it comes to 
> timeouts.  However, I suspect that's oging to be peripheral to the 
> issue here.
>
> On 20/09/12 11:44, M.E. Verhagen wrote:
>> I wonder if there is a timeout on the fetch request ?
>> Or are they stacking up and just waiting till they are in the front 
>> of the line to be processed ?
>>
>> 2012/9/20 Justin Clark-Casey <jjustincc at googlemail.com 
>> <mailto:jjustincc at googlemail.com>>
>>
>>     Fetch times of 1068560ms (which is more than 15 minutes!) are 
>> pathological - something is wrong.
>>
>>     In the first case I would suspect an issue with the connection to 
>> the OSGrid inventory service.  Either it is being
>>     overloaded (OSGrid actually runs multiple copies of the ROBUST 
>> inventory service and load-balances between them
>>     using Nginx, but perhaps the limits are being hit), things are 
>> being massive lagged because of lots of requests
>>     hitting the .net default connection limit, as Melanie discussed, 
>> or you have a network issue.
>>
>>     However, I'm a little surprised that the OSGrid Inventory Service 
>> request within FetchInventoryDescendents2 isn't
>>     making it's own complaint about a long request.  The log message 
>> you're seeing does cover the whole of the CAPs call
>>     so I suppose there is some chance there's some other cause, 
>> though it is a pretty simple capability.
>>
>>     If you want to see if viewers are doing a lot of inventory 
>> fetches, then you can try the command "debug http 3" on
>>     the simulator console.  This will show every incoming http 
>> request from viewers (and other simulators) and the HTTP
>>     URI they are hitting.  Very recent code also has levels 4 and 5 
>> which will log a snippet of the incoming request and
>>     the entire request, though you probably don't want to use them 
>> for any length of time.
>>
>>
>>     On 14/09/12 11:33, Ai Austin wrote:
>>
>>
>>             From: Melanie <melanie at t-data.com 
>> <mailto:melanie at t-data.com>>
>>
>>             You're using a viewer that fetches the user inventory in the
>>             background on login. ...
>>             You will need to disable inventory fetch on startup and/or
>>             viewerside AO.
>>
>>
>>         Thanks for the explanation Melanie... that sounds like it is 
>> the type of problem I am seeing on our add on OSGrid
>>         regions... but not on our own Openvue grid whcih essentially 
>> runs on identical hardware and with identical
>>         network setups.
>>
>>         I am observing the problem with both LL 3.3.4 and 
>> Firestorm/Pheonix 4.2.2...
>>
>>         I don't have the viewer provided sAO turned on in Firestorm,  
>> but I just looked at all the settings I can find in LL
>>         3.3.4 and Firestorm 4.2.2 and cannot see one that refers to 
>> http fetching via http.  Although I am sure I have
>>         seen this
>>         in the past on earlier viewers.  Which Preferences tab is it on?
>>
>>             From: James Stallings II <james.stallings at gmail.com 
>> <mailto:james.stallings at gmail.com>>
>>
>>             I would recommend (assuming firestorm here) setting both 
>> inventory fetch
>>             and texture fetch to http in the settings, and making the 
>> following changes
>>             to opensim.ini:
>>             [ClientStack.LindenCaps]
>>                  ...
>>                  Cap_GetTexture = "localhost"
>>                  Cap_GetMesh = "localhost"
>>                  ; This is disabled by default. Change if you see 
>> fit. Note that
>>                  ; serving this cap from the simulators may lead to 
>> poor performace.
>>                   Cap_FetchInventoryDescendents2 = "localhost"
>>                   Cap_FetchInventory2 = "localhost"
>>
>>
>>         Yep, that what I am set to already James.. I just checked. 
>> Thanks.
>>         _________________________________________________
>>         Opensim-users mailing list
>>         Opensim-users at lists.berlios.de 
>> <mailto:Opensim-users at lists.berlios.de>
>> https://lists.berlios.de/__mailman/listinfo/opensim-users 
>> <https://lists.berlios.de/mailman/listinfo/opensim-users>
>>
>>
>>
>>     --
>>     Justin Clark-Casey (justincc)
>>     OSVW Consulting
>>     http://justincc.org
>>     http://twitter.com/justincc
>>
>>     _________________________________________________
>>     Opensim-users mailing list
>>     Opensim-users at lists.berlios.de 
>> <mailto:Opensim-users at lists.berlios.de>
>>     https://lists.berlios.de/__mailman/listinfo/opensim-users 
>> <https://lists.berlios.de/mailman/listinfo/opensim-users>
>>
>>
>>
>>
>> -- 
>> Groningen en Hannover Opensims: 
>> secondlife://meverhagen.nl:8002:Hannover ZW/
>>
>>
>> _______________________________________________
>> Opensim-users mailing list
>> Opensim-users at lists.berlios.de
>> https://lists.berlios.de/mailman/listinfo/opensim-users
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-users/attachments/20120930/679b629c/attachment.html>