Smalltalk › Frameworks & Tools › Seaside › Seaside General

Why could a POST take too much?

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Mariano Martinez Peck

Why could a POST take too much?

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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Johan Brichau-2

Re: Why could a POST take too much?

Hi Mariano,

I’m afraid you will need to give a bit more info here…

Is it a GLASS or Pharo-based application? Are you logging the browser response time or is this server-side rendering timing? What is the code, etc… ?

Johan

On 09 May 2014, at 17:42, Mariano Martinez Peck <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Mariano Martinez Peck

Re: Why could a POST take too much?

On Sat, May 10, 2014 at 3:51 AM, Johan Brichau <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Screen Shot 2014-05-12 at 5.10.03 PM.png (18K) Download Attachment

Screen Shot 2014-05-12 at 5.10.16 PM.png (19K) Download Attachment

Philippe Marschall

Re: Why could a POST take too much?

On Mon, May 12, 2014 at 10:17 PM, Mariano Martinez Peck
<[hidden email]> wrote:

>
>
>
> On Sat, May 10, 2014 at 3:51 AM, Johan Brichau <[hidden email]> 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?

The POST is the callback processing, not the rendering. What do you do
in #logAndValue:?

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Mariano Martinez Peck

Re: Why could a POST take too much?

>>
>> 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?

The POST is the callback processing, not the rendering. What do you do
in #logAndValue:?

Hi Philippe,

I am confused by your statement about "the POST is the callback processing". What do you mean?

In my case, I always get 2 request, one is a POST, which always answer 302 as status, and it is always very small.

Then, I have a GET which is the real request and the one that depends on the thing I am executing.

What it is strange is that the first request (the POST that always answer 302) in one case it takes 200ms and in another 1.6 seconds.

the callback time isn't it included in the GET, not in the POST?

Thanks for the clarification.

Cheers
Philippe

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Mariano Martinez Peck

Re: Why could a POST take too much?

On Mon, May 12, 2014 at 5:42 PM, Mariano Martinez Peck <[hidden email]> wrote:

>>
>> 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?

The POST is the callback processing, not the rendering. What do you do
in #logAndValue:?

Hi Philippe,

I am confused by your statement about "the POST is the callback processing". What do you mean?
In my case, I always get 2 request, one is a POST, which always answer 302 as status, and it is always very small.

Then, I have a GET which is the real request and the one that depends on the thing I am executing.
What it is strange is that the first request (the POST that always answer 302) in one case it takes 200ms and in another 1.6 seconds.

the callback time isn't it included in the GET, not in the POST?

what #logAndValue: does is to execute the closure associated to the menu item I want to go. This menu is being built in component X (my main app compoment). The closue will end up setting in X instVar 'subcomponent', the subcomponent to render in it's "main page". So this component X, renderConentOn: will end up doing a "html render: subcomponent' at some point in time.

is it clear?

Thanks for the clarification.

Cheers
Philippe

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

--
Mariano
http://marianopeck.wordpress.com

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Dale Henrichs-3

Re: Why could a POST take too much?

In reply to this post by Mariano Martinez Peck

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 <[hidden email]> wrote:

On Sat, May 10, 2014 at 3:51 AM, Johan Brichau <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Mariano Martinez Peck

Re: Why could a POST take too much?

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 <[hidden email]> 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 <[hidden email]> wrote:

On Sat, May 10, 2014 at 3:51 AM, Johan Brichau <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

--
Mariano
http://marianopeck.wordpress.com

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Sven Van Caekenberghe-2

Re: Why could a POST take too much?

Mariano,

On 12 May 2014, at 23:16, Mariano Martinez Peck <[hidden email]> wrote:

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

This is basic Seaside 101: your navbar's button is inside a form (has to be), hence you submit the form, which is a POST. Seaside always replies with a redirect to a GET to get the _s and _k parameters in the URL. You can think of the first fase as callback processing and the second fase as rendering.

Are you sure that the handling of the button's action (in your own code) does not take a lot of time by itself (apart from what Seaside does) for some application specific reason ?

Sven_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Paul DeBruicker

Re: Why could a POST take too much?

Just for clarity:

<pedant>
It doesn't have to be in a form. You can use jQuery to serialize the form data using an ajax POST e.g.

html jQuery post serializeForm:(html jQuery id: 'myForm')

or with a GET

html jQuery ajax serializeForm:(html jQuery id: 'myForm')

</pedant>

You can also serialize arbitrary divs if you want using jQuery with #serialize: and friends.

But I agree with everything else you've said.

Sven Van Caekenberghe-2 wrote

Mariano,

On 12 May 2014, at 23:16, Mariano Martinez Peck <[hidden email]> wrote:

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

This is basic Seaside 101: your navbar's button is inside a form (has to be), hence you submit the form, which is a POST. Seaside always replies with a redirect to a GET to get the _s and _k parameters in the URL. You can think of the first fase as callback processing and the second fase as rendering.

Are you sure that the handling of the button's action (in your own code) does not take a lot of time by itself (apart from what Seaside does) for some application specific reason ?

Sven_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside