[Opensim-users] Slow handling of POST -
R.Gunther
rigun at rigutech.nl
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
""This code works well but it has a very serious problem as the
|WebRequest| class function |GetResponse| locks the access to all other
processes, the |WebRequest| tells the retrieved response as closed, as
in the last line in the previous code. So I noticed that always only one
thread is downloading while others are waiting to |GetResponse|. To
solve this serious problem, I implemented my two classes,
*|MyWebRequest|* and *|MyWebResponse|*.""
**********
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>
More information about the Opensim-users
mailing list