[Seaside] Why could a POST take too much?

[Mariano Martinez Peck]

OK....this is what I found strange. I profiled both request, the POST and
the GET. Indeed, the POST was slow because of the processing I did in the
callback. Normally, 99% of my use cases, the POST is quite fast and the
slow part I get it in the GET. In this case, the slow part is in the post
and the fast in the get.

Could you explain what is the first POST and which is the second GET?

Thanks in advance,



On Mon, May 12, 2014 at 5:53 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> 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
>>
>>
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>


-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20140512/325aae28/attachment.htm