Re: [Seaside] TTFB, Apache, Seaside Performance Problem
Locked
Re: [Seaside] TTFB, Apache, Seaside Performance Problem
 
|
I think this has to do with your particular server setup (Windows, Apache on Windows ?), there normally should not be any real difference (caching of DNS results). I am using localhost as upstream server reference everywhere (Linux mostly Nginx).
Anyway, it does again show that general system admin and networking knowledge is always crucial and independent of specific application technologies used. BTW, thanks for this conversation, this way we can all learn some more. > On 5 Jan 2017, at 13:10, Sabine Manaa <[hidden email]> wrote: > > http://stackoverflow.com/questions/25199405/localhost-vs-127-0-0-1-performance > > 2017-01-05 13:24 GMT+01:00 Sabine Manaa <[hidden email]>: > Mariano, no, there is no difference in the response time between localhost and 127.0.0.1 > I entered now the ip of the server there. > > Don't you think that this should be written in the book? > http://book.seaside.st/book/advanced/deployment/deployment-apache/configure-apache > > > > 2017-01-05 12:58 GMT+01:00 Mariano Martinez Peck [via Smalltalk] <[hidden email]>: > Wow, that's what I call to nail it! hahahaha. > > Norbert, do you have some explanation we could all learn from it? It's something concrete about Apache or is it something as general as resolving localhost could take longer than 127.0.0.1? > > Sabine, do you see a difference in the response time when ping to localhost and 127.0.0.1 ? > > Thanks in advance, > > On Thu, Jan 5, 2017 at 8:47 AM, Sabine Manaa <[hidden email]> wrote: > The problem is solved: I had to replace localhost by 127.0.0.1 > Thanks a lot Norbert Hartl for your advice! > > 2017-01-05 12:25 GMT+01:00 Sabine Manaa [via Smalltalk] <[hidden email]>: > Hi, > > I need the help of the community. > > I am not succeding in making our app faster. > The problem is the Time to first Byte (TTFB). It is always more than one second which is much to much. > We reduced the problem to a problem between apache and pharo/seaside. > > For this, I have a test application which only renders "hello World". So I am sure it is not my code, my database, my css, my js, my ssl.... :-) > > I optimized and learned a lot for my app, but it did not solve the TTFB problem, which costs 1 additional sec for each click of the user which is inaceptable. > > Please follow this tests to see the problem: > > ===>>> Test 1: test.html without Pharo/seaside > https://tools.keycdn.com/performance?url=http://app.spesenfuchs.de/test.html > TTFB in Frankfurt below 10 ms -> this proves that the server and configuration is fast. > > ===>>> Test 2: hello world, simple seaside page > https://tools.keycdn.com/performance?url=app.spesenfuchs.de/hello > TTFB in Frankfurt more than 1 second! -> this proves that it is not my application :-) it is only a hello world seaside page... > > ===>>> Test 3: my login page > https://tools.keycdn.com/performance?url=app.spesenfuchs.de/rka > TTFB in Frankfurt more than 1 second! > > (alternative: enter the urls into https://gtmetrix.com/) > > In Apache, we enabled tracing of the rewrite and this tells me (i assume), that apache makes the rewrite very fast, within the same millisecond :-) > [Thu Jan 05 12:14:35.243400 2017] [rewrite:trace2] [pid 1288:tid 1692] mod_rewrite.c(477): [client 91.89.219.232:52272] 91.89.219.232 - - [app.spesenfuchs.de/sid#66c848][rid#20bc4c8/initial] init rewrite engine with requested uri /hello > [Thu Jan 05 12:14:35.243400 2017] [rewrite:trace3] [pid 1288:tid 1692] mod_rewrite.c(477): [client 91.89.219.232:52272] 91.89.219.232 - - [app.spesenfuchs.de/sid#66c848][rid#20bc4c8/initial] applying pattern '^/rka(.*)$' to uri '/hello' > [Thu Jan 05 12:14:35.243400 2017] [rewrite:trace3] [pid 1288:tid 1692] mod_rewrite.c(477): [client 91.89.219.232:52272] 91.89.219.232 - - [app.spesenfuchs.de/sid#66c848][rid#20bc4c8/initial] applying pattern '^/hello(.*)$' to uri '/hello' > [Thu Jan 05 12:14:35.243400 2017] [rewrite:trace2] [pid 1288:tid 1692] mod_rewrite.c(477): [client 91.89.219.232:52272] 91.89.219.232 - - [app.spesenfuchs.de/sid#66c848][rid#20bc4c8/initial] rewrite '/hello' -> 'http://localhost:8085/HelloWorld/' > [Thu Jan 05 12:14:35.243400 2017] [rewrite:trace2] [pid 1288:tid 1692] mod_rewrite.c(477): [client 91.89.219.232:52272] 91.89.219.232 - - [app.spesenfuchs.de/sid#66c848][rid#20bc4c8/initial] forcing proxy-throughput with http://localhost:8085/HelloWorld/ > [Thu Jan 05 12:14:35.243400 2017] [rewrite:trace1] [pid 1288:tid 1692] mod_rewrite.c(477): [client 91.89.219.232:52272] 91.89.219.232 - - [app.spesenfuchs.de/sid#66c848][rid#20bc4c8/initial] go-ahead with proxy request proxy:http://localhost:8085/HelloWorld/ [OK] > > So, I assume that there is problem between Apache and Seaside.... > > My questiond are: > what can I do to find the bottleneck? > what is the reason that is so slow? > your help is very appreciated because I have run out of ideas what it could be and I was investigating it several days now. > > Concerning the system: > The server is at Amazon ec2 windows Server 2009 R2 SP1 > The Apache version is 2.4.23 > The configuration of the apache is like this (as described in the seaside book http://book.seaside.st/book/advanced/deployment/deployment-apache/configure-apache) > > <VirtualHost *:80> > ProxyPreserveHost On > ServerName app.spesenfuchs.de > RewriteEngine On > <Directory "C:\xampp\htdocs"> > Require all granted > </Directory> > DocumentRoot "C:\xampp\htdocs" > RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f > > RewriteRule ^/rka(.*)$ http://localhost:8085/RKA/$1 [proxy,last] > RewriteRule ^/hello(.*)$ http://localhost:8085/HelloWorld/$1 [proxy,last] > </VirtualHost> > > If you reply to this email, your message will be added to the discussion below: > http://forum.world.st/TTFB-Apache-Seaside-Performance-Problem-tp4928842.html > To start a new topic under Seaside General, email [hidden email] > To unsubscribe from Seaside, click here. > NAML > > > View this message in context: Re: TTFB, Apache, Seaside Performance Problem > Sent from the Seaside General mailing list archive at Nabble.com. > > _______________________________________________ > 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 > > > If you reply to this email, your message will be added to the discussion below: > http://forum.world.st/TTFB-Apache-Seaside-Performance-Problem-tp4928842p4928845.html > To start a new topic under Seaside General, email [hidden email] > To unsubscribe from TTFB, Apache, Seaside Performance Problem, click here. > NAML > > > > View this message in context: Re: TTFB, Apache, Seaside Performance Problem > Sent from the Seaside General mailing list archive at Nabble.com. > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Am 05.01.17 um 13:34 schrieb Sven Van Caekenberghe:
> I think this has to do with your particular server setup (Windows, Apache on Windows ?), there normally should not be any real difference (caching of DNS results). I am using localhost as upstream server reference everywhere (Linux mostly Nginx). > I guess youe are right: I just tried in our environment and the result is not distinguishable from the initial response times. We never had these problems, however. Joachim -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:[hidden email] Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1 |
Re: [Seaside] TTFB, Apache, Seaside Performance Problem
|
|
> Am 05.01.2017 um 13:41 schrieb [hidden email]: > > Am 05.01.17 um 13:34 schrieb Sven Van Caekenberghe: >> I think this has to do with your particular server setup (Windows, Apache on Windows ?), there normally should not be any real difference (caching of DNS results). I am using localhost as upstream server reference everywhere (Linux mostly Nginx). >> > I guess youe are right: I just tried in our environment and the result is not distinguishable from the initial response times. We never had these problems, however. > And I'm glad that after 23 years of doing networking stuff I developed a gut feeling what might be wrong :) The problem here (I think) is precedence of ipv6 over ipv4. Modern systems are configured in a way to prefer ipv6 over v4. So while resolving the name localhost the loopback address ::1 is resolved making the apache proxy connecting to ::1. While pharo does not have ipv6 support the connection fails. In case of that in a ipv6 scenario the ipv4 alternative is tried making the call to 127.0.0.1 instead. Shouldn't be a reason taking so long so it might have to do with the apache proxy module code. There are multiple options to prevent that: 1. you make the use of localhost explicit by using 127.0.0.1 which here means localhost(ipv4) 2. You do echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf to switch your system to ipv4 precedence 3. You remove ::1 localhost from the file /etc/hosts 4. You rename ::1 localhost to ::1 ip6-localhost In an ip dual-stack scenario there are these kind of problems. Hope that clarifies it! Norbert |
Re: [Seaside] TTFB, Apache, Seaside Performance Problem
|
|
In reply to this post by Sven Van Caekenberghe-2
Your discussion was going on the seaside list? I just wonder I haven't seen any of the responses from Mariano et al.
Norbert > Am 05.01.2017 um 13:34 schrieb Sven Van Caekenberghe <[hidden email]>: > > I think this has to do with your particular server setup (Windows, Apache on Windows ?), there normally should not be any real difference (caching of DNS results). I am using localhost as upstream server reference everywhere (Linux mostly Nginx). > > Anyway, it does again show that general system admin and networking knowledge is always crucial and independent of specific application technologies used. > > BTW, thanks for this conversation, this way we can all learn some more. > >> On 5 Jan 2017, at 13:10, Sabine Manaa <[hidden email]> wrote: >> >> http://stackoverflow.com/questions/25199405/localhost-vs-127-0-0-1-performance >> >> 2017-01-05 13:24 GMT+01:00 Sabine Manaa <[hidden email]>: >> Mariano, no, there is no difference in the response time between localhost and 127.0.0.1 >> I entered now the ip of the server there. >> >> Don't you think that this should be written in the book? >> http://book.seaside.st/book/advanced/deployment/deployment-apache/configure-apache >> >> >> >> 2017-01-05 12:58 GMT+01:00 Mariano Martinez Peck [via Smalltalk] <[hidden email]>: >> Wow, that's what I call to nail it! hahahaha. >> >> Norbert, do you have some explanation we could all learn from it? It's something concrete about Apache or is it something as general as resolving localhost could take longer than 127.0.0.1? >> >> Sabine, do you see a difference in the response time when ping to localhost and 127.0.0.1 ? >> >> Thanks in advance, >> >> On Thu, Jan 5, 2017 at 8:47 AM, Sabine Manaa <[hidden email]> wrote: >> The problem is solved: I had to replace localhost by 127.0.0.1 >> Thanks a lot Norbert Hartl for your advice! >> >> 2017-01-05 12:25 GMT+01:00 Sabine Manaa [via Smalltalk] <[hidden email]>: >> Hi, >> >> I need the help of the community. >> >> I am not succeding in making our app faster. >> The problem is the Time to first Byte (TTFB). It is always more than one second which is much to much. >> We reduced the problem to a problem between apache and pharo/seaside. >> >> For this, I have a test application which only renders "hello World". So I am sure it is not my code, my database, my css, my js, my ssl.... :-) >> >> I optimized and learned a lot for my app, but it did not solve the TTFB problem, which costs 1 additional sec for each click of the user which is inaceptable. >> >> Please follow this tests to see the problem: >> >> ===>>> Test 1: test.html without Pharo/seaside >> https://tools.keycdn.com/performance?url=http://app.spesenfuchs.de/test.html >> TTFB in Frankfurt below 10 ms -> this proves that the server and configuration is fast. >> >> ===>>> Test 2: hello world, simple seaside page >> https://tools.keycdn.com/performance?url=app.spesenfuchs.de/hello >> TTFB in Frankfurt more than 1 second! -> this proves that it is not my application :-) it is only a hello world seaside page... >> >> ===>>> Test 3: my login page >> https://tools.keycdn.com/performance?url=app.spesenfuchs.de/rka >> TTFB in Frankfurt more than 1 second! >> >> (alternative: enter the urls into https://gtmetrix.com/) >> >> In Apache, we enabled tracing of the rewrite and this tells me (i assume), that apache makes the rewrite very fast, within the same millisecond :-) >> [Thu Jan 05 12:14:35.243400 2017] [rewrite:trace2] [pid 1288:tid 1692] mod_rewrite.c(477): [client 91.89.219.232:52272] 91.89.219.232 - - [app.spesenfuchs.de/sid#66c848][rid#20bc4c8/initial] init rewrite engine with requested uri /hello >> [Thu Jan 05 12:14:35.243400 2017] [rewrite:trace3] [pid 1288:tid 1692] mod_rewrite.c(477): [client 91.89.219.232:52272] 91.89.219.232 - - [app.spesenfuchs.de/sid#66c848][rid#20bc4c8/initial] applying pattern '^/rka(.*)$' to uri '/hello' >> [Thu Jan 05 12:14:35.243400 2017] [rewrite:trace3] [pid 1288:tid 1692] mod_rewrite.c(477): [client 91.89.219.232:52272] 91.89.219.232 - - [app.spesenfuchs.de/sid#66c848][rid#20bc4c8/initial] applying pattern '^/hello(.*)$' to uri '/hello' >> [Thu Jan 05 12:14:35.243400 2017] [rewrite:trace2] [pid 1288:tid 1692] mod_rewrite.c(477): [client 91.89.219.232:52272] 91.89.219.232 - - [app.spesenfuchs.de/sid#66c848][rid#20bc4c8/initial] rewrite '/hello' -> 'http://localhost:8085/HelloWorld/' >> [Thu Jan 05 12:14:35.243400 2017] [rewrite:trace2] [pid 1288:tid 1692] mod_rewrite.c(477): [client 91.89.219.232:52272] 91.89.219.232 - - [app.spesenfuchs.de/sid#66c848][rid#20bc4c8/initial] forcing proxy-throughput with http://localhost:8085/HelloWorld/ >> [Thu Jan 05 12:14:35.243400 2017] [rewrite:trace1] [pid 1288:tid 1692] mod_rewrite.c(477): [client 91.89.219.232:52272] 91.89.219.232 - - [app.spesenfuchs.de/sid#66c848][rid#20bc4c8/initial] go-ahead with proxy request proxy:http://localhost:8085/HelloWorld/ [OK] >> >> So, I assume that there is problem between Apache and Seaside.... >> >> My questiond are: >> what can I do to find the bottleneck? >> what is the reason that is so slow? >> your help is very appreciated because I have run out of ideas what it could be and I was investigating it several days now. >> >> Concerning the system: >> The server is at Amazon ec2 windows Server 2009 R2 SP1 >> The Apache version is 2.4.23 >> The configuration of the apache is like this (as described in the seaside book http://book.seaside.st/book/advanced/deployment/deployment-apache/configure-apache) >> >> <VirtualHost *:80> >> ProxyPreserveHost On >> ServerName app.spesenfuchs.de >> RewriteEngine On >> <Directory "C:\xampp\htdocs"> >> Require all granted >> </Directory> >> DocumentRoot "C:\xampp\htdocs" >> RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f >> >> RewriteRule ^/rka(.*)$ http://localhost:8085/RKA/$1 [proxy,last] >> RewriteRule ^/hello(.*)$ http://localhost:8085/HelloWorld/$1 [proxy,last] >> </VirtualHost> >> >> If you reply to this email, your message will be added to the discussion below: >> http://forum.world.st/TTFB-Apache-Seaside-Performance-Problem-tp4928842.html >> To start a new topic under Seaside General, email [hidden email] >> To unsubscribe from Seaside, click here. >> NAML >> >> >> View this message in context: Re: TTFB, Apache, Seaside Performance Problem >> Sent from the Seaside General mailing list archive at Nabble.com. >> >> _______________________________________________ >> 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 >> >> >> If you reply to this email, your message will be added to the discussion below: >> http://forum.world.st/TTFB-Apache-Seaside-Performance-Problem-tp4928842p4928845.html >> To start a new topic under Seaside General, email [hidden email] >> To unsubscribe from TTFB, Apache, Seaside Performance Problem, click here. >> NAML >> >> >> >> View this message in context: Re: TTFB, Apache, Seaside Performance Problem >> Sent from the Seaside General mailing list archive at Nabble.com. >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > |
Re: [Seaside] TTFB, Apache, Seaside Performance Problem
|
Thank you all for your comments and help. The mailing list mostly is my last option (I don't want make to much noise) and if anyone can help me here, I am always very happy. @Norbert, concerning your last post, ip4/ip6: is there any disadvantage when choosing your option1 (using 127.0.0.1 instead of localhost) instead of the others? @Norbert, I have Problems with the seaside mailing list. My posts reach the list online but don't go out by mail. When I used it in the past, I did not get response (because people read the mailing list by mail and not by going to http://forum.world.st), so I used the Pharo Mailinglist by intent, sorry: -) @Sven, yes apache on windows: http://lists.squeakfoundation.org/pipermail/seaside/2012-August/029062.html We would prefer using IIS but there seems to be no detailed description for it. @Joachim, yes indeed more than one second! So, I had response times from 3-4 seconds. Now, after reading and optimizing a lot and also without the TTFB problem, it is 1-2 sec, great! BTW: vary has very good advices, e.g: https://varvy.com/pagespeed 2017-01-05 14:32 GMT+01:00 NorbertHartl [via Smalltalk] <[hidden email]>: Your discussion was going on the seaside list? I just wonder I haven't seen any of the responses from Mariano et al. |
Re: [Seaside] TTFB, Apache, Seaside Performance Problem
|
|
In reply to this post by NorbertHartl
Seems to be some trouble with the Seaside list as I replied at 12:44 but it is like it wasn't shown or something. "Did you try with 127.0.0.1 instead of localhost? I see you are on Windows and I got some issues like that. Phil" On Thu, Jan 5, 2017 at 2:48 PM, Norbert Hartl <[hidden email]> wrote: Your discussion was going on the seaside list? I just wonder I haven't seen any of the responses from Mariano et al. |
Re: [Seaside] TTFB, Apache, Seaside Performance Problem
|
|
In reply to this post by Sabine Manaa
No, even if you would make spesenfuchs.de reachable via ipv6 it would be just a purely internal configuration. Pharo opens only a ipv4 socket so there is no disadvantage in specifying so
I couldn't read the seaside list because I'm not subscribed. Well, now I am. Good luck, Norbert |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |