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.
>>> [hidden email]>> 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
>> 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/Re-Seaside-TTFB-Apache-Seaside- Performance-Problem- tp4928850p4928857.html To start a new topic under Pharo Smalltalk Users, email [hidden email]
To unsubscribe from Pharo Smalltalk Users, click here.
NAML