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

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

by 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). 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] TTFB, Apache, Seaside Performance Problem

by Sabine Manaa

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! 2017-01-05 12:25 GMT+01:00 NorbertHartl [via Smalltalk] < ml-node+s1294792n4928840h35(a)n4.nabble.com>: > It is hard to guess. Can you try changing the rewrite rules to > > RewriteRule ^/rka(.*)$ http://127.0.0.1:8085/RKA/$1 [proxy,last] > RewriteRule ^/hello(.*)$ http://127.0.0.1:8085/HelloWorld/$1 [proxy,last] > > It is "127.0.0.1" instead of "localhost" > > It is trial and error anyway ;) > > Norbert > > > Am 05.01.2017 um 12:10 schrieb Sabine Manaa <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=4928840&i=0>>: > > > > 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> > > > > > > > > -- > > View this message in context: http://forum.world.st/TTFB- > Apache-Seaside-Performance-Problem-tp4928839.html > > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > http://forum.world.st/TTFB-Apache-Seaside-Performance- > Problem-tp4928839p4928840.html > To start a new topic under Pharo Smalltalk Users, email > ml-node+s1294792n1310670h65(a)n4.nabble.com > To unsubscribe from TTFB, Apache, Seaside Performance Problem, 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/TTFB-Apache-Seaside-Performance-Problem-tp4928839p492… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Jan. 5, 2017

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

by Norbert Hartl

It is hard to guess. Can you try changing the rewrite rules to RewriteRule ^/rka(.*)$ http://127.0.0.1:8085/RKA/$1 [proxy,last] RewriteRule ^/hello(.*)$ http://127.0.0.1:8085/HelloWorld/$1 [proxy,last] It is "127.0.0.1" instead of "localhost" It is trial and error anyway ;) Norbert > Am 05.01.2017 um 12:10 schrieb Sabine Manaa <manaa.sabine(a)gmail.com>: > > 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> > > > > -- > View this message in context: http://forum.world.st/TTFB-Apache-Seaside-Performance-Problem-tp4928839.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

Jan. 5, 2017

Re: [Pharo-users] How to view hierarchy of multiple classes in a package?

by Tim Mackinnon

I finally got a chance to try this change out - and this a super helpful change - thanks so much. (It also taught me where some of the things live in Pharo). Why wouldnât this change be made permanent in the live Pharo? I canât see any downside and it really helps understand new code. Tim > On 30 Dec 2016, at 10:49, Henrik Nergaard <draagren(a)outlook.com> wrote: > > Changing ClassWidget>>#showHierarchy to: > showHierarchy: aBoolean > > | all | > > (showHierarchy := aBoolean) ifFalse: [ ^ self ]. > > all := IdentitySet new. > model selectedPackageGroup asNautilusSelection classes do: [ :cls | > all > addAll: cls allSuperclasses; > addAll: cls withAllSubclasses > ]. > > self cachedHierarchy: (SortHierarchically buildHierarchyForClasses: all) > > Will make the hierarchy button show the tree for all classes in that package/tag. > <image001.png> > > Best regards, > Henrik > > From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org>] On Behalf Of Tim Mackinnon > Sent: Wednesday, December 28, 2016 5:24 PM > To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> > Subject: Re: [Pharo-users] How to view hierarchy of multiple classes in a package? > > This seems to have generated a bit of conversation which has helped me quite a bit. > > Denis, your picture has made me realise that the System browser is a bit better than I realised. > > However the example I was looking at was a package that had a series of Announcement subclasses, AND what wasn't obvious was that they were all subclasses of the same parent "Announcement", as that isn't shown - you just get a series of classes not rooted under some parent (even if it was object). I'm guessing that just things that are subclasses of each other in the same package are shown? > > I was hoping that pane might show - > > Announcement > + A > + B > + C > > I'm now wondering what it will show if you had a few different subclasses of the different collection classes (ok it's a bad idea to subclass them, but my point is if you had a few models at different points in a hierarchy)? > > I'm guessing you would see the same flat list - but I will go and try that to help me learn a bit more. > > Tim

Jan. 5, 2017

TTFB, Apache, Seaside Performance Problem

by Sabine Manaa

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> -- View this message in context: http://forum.world.st/TTFB-Apache-Seaside-Performance-Problem-tp4928839.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Jan. 5, 2017

Re: [Pharo-users] Reverse interval

by Nicolai Hess

It is just something I often saw, I don't even know if this is by-design. I think there are good arguments for both interpretations 2017-01-05 10:33 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > ok fair enough, I am not saying I am right and you are wrong, just wanted > to understand the reasoning > > Would it not "Interval empty" made more sense ? or is (1 to: 0) > convenient in some way in your scenario ? > > On Thu, Jan 5, 2017 at 10:59 AM Nicolai Hess <nicolaihess(a)gmail.com> > wrote: > >> 2017-01-05 9:46 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >> >> mainly because in my 30 years of coding for fun I never gave a damn what >> C or other languages try to convince us what expected behaviour is , its >> one of the big reason why I code in Smalltalk ;) >> >> plus I hate C/C++ with a vengeance , so :D >> >> On Thu, Jan 5, 2017 at 10:38 AM Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >> On 5 Jan 2017, at 09:29, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >> >> cant say it makes sense for me , why it assumes I want to +0.01 when I >> give 0.5 to 0.01 when it should assume I want to -0.01 ? is there a >> scenario that would not be true ? >> >> >> We often use (1 to: 0) for an "empty" interval. All this code wouldn't >> work if we would take this as a reversed (0 to: 1) interval. >> >> >> >> take it this way: in C youâll need to write: >> >> for (int i = 0.50; i >= 0.1; i-=0.01) â¦ >> >> which is also explicit about the decreasing âiââ¦ so I donât understand >> why it does not makes sense for you :) >> >> Esteban >> >> >> in any case its better than reversedo , thank you >> >> On Thu, Jan 5, 2017 at 10:20 AM Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >> this is correct behaviour (since 0.50 + 0.01 will be bigger than 0.01), >> correct way to define this step is: >> >> (0.50 to: 0.01 by: -0.01) do:[ :each| tp := tp + each ]. >> >> (by: *-*0.01), negative >> >> Esteban >> >> >> On 5 Jan 2017, at 09:15, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >> >> hey guys I try to do a reverse interval like this >> >> tp := 0.0. >> (0.50 to: 0.01 by: 0.01) do:[ :each| tp := tp + each ]. >> tp inspect. >> >> and I get nothing , is this a bug or a feature ? >> >> i see a reverse method but looks weird to go that way and not very >> smalltalky / pharoic >> >> >>

Jan. 5, 2017

Re: [Pharo-users] Reverse interval

by Nicolas Passerini

2017-01-05 10:33 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > Would it not "Interval empty" made more sense ? or is (1 to: 0) > convenient in some way in your scenario ? > +1

Jan. 5, 2017

Re: [Pharo-users] Reverse interval

by Dimitris Chloupis

ok fair enough, I am not saying I am right and you are wrong, just wanted to understand the reasoning Would it not "Interval empty" made more sense ? or is (1 to: 0) convenient in some way in your scenario ? On Thu, Jan 5, 2017 at 10:59 AM Nicolai Hess <nicolaihess(a)gmail.com> wrote: > 2017-01-05 9:46 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > > mainly because in my 30 years of coding for fun I never gave a damn what C > or other languages try to convince us what expected behaviour is , its one > of the big reason why I code in Smalltalk ;) > > plus I hate C/C++ with a vengeance , so :D > > On Thu, Jan 5, 2017 at 10:38 AM Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > On 5 Jan 2017, at 09:29, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > cant say it makes sense for me , why it assumes I want to +0.01 when I > give 0.5 to 0.01 when it should assume I want to -0.01 ? is there a > scenario that would not be true ? > > > We often use (1 to: 0) for an "empty" interval. All this code wouldn't > work if we would take this as a reversed (0 to: 1) interval. > > > > take it this way: in C youâll need to write: > > for (int i = 0.50; i >= 0.1; i-=0.01) â¦ > > which is also explicit about the decreasing âiââ¦ so I donât understand why > it does not makes sense for you :) > > Esteban > > > in any case its better than reversedo , thank you > > On Thu, Jan 5, 2017 at 10:20 AM Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > this is correct behaviour (since 0.50 + 0.01 will be bigger than 0.01), > correct way to define this step is: > > (0.50 to: 0.01 by: -0.01) do:[ :each| tp := tp + each ]. > > (by: *-*0.01), negative > > Esteban > > > On 5 Jan 2017, at 09:15, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > hey guys I try to do a reverse interval like this > > tp := 0.0. > (0.50 to: 0.01 by: 0.01) do:[ :each| tp := tp + each ]. > tp inspect. > > and I get nothing , is this a bug or a feature ? > > i see a reverse method but looks weird to go that way and not very > smalltalky / pharoic > > >

Jan. 5, 2017

Re: [Pharo-users] improving add parameter refactoring

by Denis Kudriashov

Hi. Just to know, Eclipse does it right for recursions in java. It puts new argument in recursive call 2017-01-05 9:15 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > Hi john > > I'm facing the following situation and I was wondering if a simple > heuristic could not improve the situation (where edge cases will always be > a problem). > > I got a hierarchy of expressions implementing evaluate and I wanted to add > a parameter (the binding). So Add Parameter worked but broke evaluate > recursive methods. > Here is a part of the book I'm writing > > > [[[ > EConstant >> testEvaluate > self assert:(EConstant new value: 5) evaluate equals: 5 > ]]] > > is transformed as follows: > [[[ > EConstant >> testEvaluate > self assert: ((EConstant new value: 5) evaluateWith: Dictionary new) > equals: 5 > ]]] > > Your tests should nearly all pass except the ones on variables. Why do > they fail? > Because the refactoring transformed message sends ==evaluate== but > ==evaluateWith: Dictionary new== and this even in methods ==evaluate==. > > [[[ > EAddition >> evaluateWith: anObject > ^ (right evaluateWith: Dictionary new) + (left evaluateWith: Dictionary > new) > ]]] > > [[[ > EAddition >> evaluateWith: anObject > ^ (right evaluateWith: anObject) + (left evaluateWith: anObject) > ]]] > > > And I was wondering if a good heuristic would be to change the parameter. > Now I have the impression that the refactoring is done it two passes. > So this is more tricky than it looks. > > Stef >

Jan. 5, 2017

Re: [Pharo-users] Reverse interval

by Nicolai Hess

2017-01-05 9:46 GMT+01:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: > mainly because in my 30 years of coding for fun I never gave a damn what C > or other languages try to convince us what expected behaviour is , its one > of the big reason why I code in Smalltalk ;) > > plus I hate C/C++ with a vengeance , so :D > > On Thu, Jan 5, 2017 at 10:38 AM Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> On 5 Jan 2017, at 09:29, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >> >> cant say it makes sense for me , why it assumes I want to +0.01 when I >> give 0.5 to 0.01 when it should assume I want to -0.01 ? is there a >> scenario that would not be true ? >> >> We often use (1 to: 0) for an "empty" interval. All this code wouldn't work if we would take this as a reversed (0 to: 1) interval. > >> take it this way: in C youâll need to write: >> >> for (int i = 0.50; i >= 0.1; i-=0.01) â¦ >> >> which is also explicit about the decreasing âiââ¦ so I donât understand >> why it does not makes sense for you :) >> >> Esteban >> >> >> in any case its better than reversedo , thank you >> >> On Thu, Jan 5, 2017 at 10:20 AM Esteban Lorenzano <estebanlm(a)gmail.com> >> wrote: >> >> this is correct behaviour (since 0.50 + 0.01 will be bigger than 0.01), >> correct way to define this step is: >> >> (0.50 to: 0.01 by: -0.01) do:[ :each| tp := tp + each ]. >> >> (by: *-*0.01), negative >> >> Esteban >> >> >> On 5 Jan 2017, at 09:15, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: >> >> hey guys I try to do a reverse interval like this >> >> tp := 0.0. >> (0.50 to: 0.01 by: 0.01) do:[ :each| tp := tp + each ]. >> tp inspect. >> >> and I get nothing , is this a bug or a feature ? >> >> i see a reverse method but looks weird to go that way and not very >> smalltalky / pharoic >> >> >>

Jan. 5, 2017