[Seaside] Why could a POST take too much?

[Dale Henrichs]

Mariano,

How heavily loaded is the system while you are doing this test?

If the system is doing a lot of disk i/o (readn and write) and you have not
put your tranlogs on a separate spindle (LUN) and you are running on Lunix,
there is a possibility that the delay is caused by the end of request
commit ...

On Linux, the default setting for the system is to favor reads over writes,
the commit will not complete until the tranlog records have been flushed to
disk and on a system that is doing a lot of reading, the flush can be
deferred for "unreasonably long periods" (yes seconds). On SS3 I was seeing
significant delays until I move the tranlogs to a separate LUN....

You can tell if this is a possibility by looking at statmon results ... you
are looking for lots of disk i/o (PageReads on your Gems) ...

If you suspect that this might be the case (i.e., an MFC running when you
are seeing the slow responses), then I can look at a statmon file to help
determine if this is indeed the case.

Dale


On Mon, May 12, 2014 at 1:17 PM, Mariano Martinez Peck <
marianopeck at gmail.com> wrote:

>
>
>
> On Sat, May 10, 2014 at 3:51 AM, Johan Brichau <johan at inceptive.be> wrote:
>
>> Hi Mariano,
>>
>> I’m afraid you will need to give a bit more info here…
>> Is it a GLASS or Pharo-based application?
>>
>
> Sorry, I didn't give too much info. It is GLASS.
>
>
>> Are you logging the browser response time or is this server-side
>> rendering timing? What is the code, etc… ?
>>
>>
> I am using the developer tools. I attach 2 screenshots, one POST (normal
> one) takes 246ms and the slow one that takes 1.66 seconds in this example.
> Both "submits" were just a click in a menu button.
>
> The menu is renderrd like this:
>
> renderActivityMenuOn: html id: anId
> (self showActivityMenu and: [self activityMenu isEmpty not]) ifTrue: [
>  html div id:'activityMenuDiv'; with: [
> html form: [
> html
>  tbsNavbar
> id: anId;
> beDefault;
>  with: [
> self activityMenu
> do: [ :menuAction |
>  html space.
> html
> tbsNavbarButton
>  beSmall;
> beActiveIf: ((menuAction = selectedActivityMenuAction)  or:
> [selectedActivityMenuAction isNil and: [self activityMenu first =
> menuAction]]) ;
>  callback: [menuAction logAndValue: self.
> selectedActivityMenuAction := menuAction];
>  with: [ html text: menuAction label ] ] ] ]]]
>
> So basically it is a form and each menu item is a button.
>
> I don't understand why a POST could take 200ms for one menu item and 1.6
> second for another one.
>
> Any idea? how can I debug it?
>
> Thanks in advance,
>
>
>
>
>> Johan
>>
>> On 09 May 2014, at 17:42, Mariano Martinez Peck <marianopeck at gmail.com>
>> wrote:
>>
>> Hi guys,
>>
>> I have a strange situation. I have the main menu of my app built with
>> Bootstrap NavBar. It is a form, and a button per "menu item". Buttons are
>> NavbarButton. Now what is strange is that it takes quite some time to
>> render some of the menu items. Using internet browser dev tools I can see
>> that requests are usually fast, however, for certain specific menu items,
>> the POST takes quite some time. For example, there are 2 or 3 menu items
>> where the post takes 3 seconds!!!!    Normally, I know how to profile/debug
>> slow requests (I can profile #handleRequest: etc) but I am clueless how to
>> profile this problem.
>>
>> Any help is appreciated.
>>
>> Best,
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>  _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>>
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>
>
> --
> Mariano
> http://marianopeck.wordpress.com
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20140512/e61aa469/attachment-0001.htm