January 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [Pharo-dev] Call of projects of open-dev lectures

by stepharong

On Thu, 05 Jan 2017 10:50:58 +0100, Hilaire <hilaire(a)drgeo.eu> wrote: > Hi, > > You desscribed a bit the students, I have few more questions : > > What is the background of the students regarding computer science? L3 student (third year) > > How many hours are they supposed to dedicate to the project? 12 * 4 hours. > > Phratch will be a nice project to get student interested by. Thanks I will add it to the list. > > > Hilaire -- Using Opera's mail client: http://www.opera.com/mail/

Jan. 5, 2017

Re: [Pharo-users] [Seaside] TTFB, Apache, Seaside Performance Problem

by Norbert Hartl

> Am 05.01.2017 um 16:04 schrieb Sabine Manaa <manaa.sabine(a)gmail.com>: > > @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? > No, even if you would make spesenfuchs.de <http://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 > @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 <http://forum.world.st/>), so I used the Pharo Mailinglist by intent, sorry: -) I couldn't read the seaside list because I'm not subscribed. Well, now I am. Good luck, Norbert

Jan. 5, 2017

Re: [Pharo-users] [Seaside] TTFB, Apache, Seaside Performance Problem

by Sabine Manaa

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] < ml-node+s1294792n4928857h62(a)n4.nabble.com>: > 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] > <http:///user/SendEmail.jtp?type=node&node=4928857&i=0>>: > > > > 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] > <http:///user/SendEmail.jtp?type=node&node=4928857&i=1>> 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 > <http://app.spesenfuchs.de/sid#66c848][rid%2320bc4c8/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 > <http://app.spesenfuchs.de/sid#66c848][rid%2320bc4c8/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 > <http://app.spesenfuchs.de/sid#66c848][rid%2320bc4c8/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 > <http://app.spesenfuchs.de/sid#66c848][rid%2320bc4c8/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 > <http://app.spesenfuchs.de/sid#66c848][rid%2320bc4c8/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 > <http://app.spesenfuchs.de/sid#66c848][rid%2320bc4c8/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:///user/SendEmail.jtp?type=node&node=4928857&i=2> > >> 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 > ml-node+s1294792n1310670h65(a)n4.nabble.com > To unsubscribe from Pharo Smalltalk Users, click here > <http://forum.world.st/template/NamlServlet.jtp?macro=unsubscribe_by_code&no…> > . > NAML > <http://forum.world.st/template/NamlServlet.jtp?macro=macro_viewer&id=instan…> > -- View this message in context: http://forum.world.st/Re-Seaside-TTFB-Apache-Seaside-Performance-Problem-tp… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Jan. 5, 2017

Re: [Pharo-users] [Seaside] TTFB, Apache, Seaside Performance Problem

by phil＠highoctane.be

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 <norbert(a)hartl.name> wrote: > 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 <sven(a)stfx.eu>: > > > > 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 <manaa.sabine(a)gmail.com> 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 > >> seaside(a)lists.squeakfoundation.org > >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > > > > >

Jan. 5, 2017

Mouse events in FastTableModel subclass [Spec]

by Matteo

Hi, I've created a PictureListModel class to manage a list of pictures. It's a subclass FastTableModel and its adapter (MorphicPictureListAdapter) is a subclass of MorphicFastTableAdapter. The widget works correctly: it shows a scrollable list of pictures. The problem is that it cannot handle âclickâ and âdouble clicksâ events, i.e. double clicking on a list item does nothing, even setting "handlesDoubleClick:" to true. I've tried to figure out the mechanism, looking into the FastTableModel, its Morphic adapter and reading the "BuildingUIWithSpec" doc, but I didn't get it. Where could I find some hint to manage "click" and "double click" events in FastTableModel? Thanks, Matteo

Jan. 5, 2017

Re: [Pharo-users] [Seaside] TTFB, Apache, Seaside Performance Problem

by Norbert Hartl

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 <sven(a)stfx.eu>: > > 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 <manaa.sabine(a)gmail.com> wrote: >> >> http://stackoverflow.com/questions/25199405/localhost-vs-127-0-0-1-performa… >> >> 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… >> >> >> >> 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…) >> >> <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-tp4928842p492… >> 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 >> seaside(a)lists.squeakfoundation.org >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > >

Jan. 5, 2017

Re: [Pharo-users] [Seaside] TTFB, Apache, Seaside Performance Problem

by Norbert Hartl

> Am 05.01.2017 um 13:41 schrieb jtuchel(a)objektfabrik.de: > > 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

Jan. 5, 2017

DWARF parser?

by Luke Gorrie

Hoi, Just a quick question to avoid duplicated effort: Has anybody written a DWARF [1] parser for Pharo? [1] https://en.wikipedia.org/wiki/DWARF

Jan. 5, 2017

Re: [Pharo-users] [Seaside] TTFB, Apache, Seaside Performance Problem

by jtuchel＠objektfabrik.de

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:jtuchel@objektfabrik.de 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

Jan. 5, 2017

Re: [Pharo-users] TTFB, Apache, Seaside Performance Problem

by Hilaire

Hello, I am all listening, learning and happy Norbert helps to fix this issue. Best wishes of success. Hilaire Le 05/01/2017 Ã 12:43, Sabine Manaa a Ã©crit : > Norbert, its crazy - THAT WAS IT > Thank you very much! > > I can't wait with the beer till esug, send me your address and I send > you a bottle of wine :-)) very happy! > -- Dr. Geo http://drgeo.eu

Jan. 5, 2017