eZ Community » Forums » Suggestions » Improve ez.no site performance for us...
expandshrink

Improve ez.no site performance for us non-Europeans please

Improve ez.no site performance for us non-Europeans please

Monday 19 May 2008 2:02:39 pm - 20 replies

I don't know what ez.no is like in Europe, but at this end of the world it's one of the slowest sites I know. Ping is about 450ms, sometimes stylesheets will time out and not load, and the ezFlow video demo runs in three second chunks with ten second 'buffering' breaks in between.

It's really not great when you are trying to persuade a client that eZ Publish is the way to go.

Tuesday 20 May 2008 11:45:12 pm

I'd like to second that. Developing for ez forces us to be using the documentation constantly, and the website has all the zip and appeal of a striking slug. I'd say it's a server problem and/or ez is not configured correctly.

Wednesday 21 May 2008 2:08:30 pm

Hi,

It would be interesting to see how ez.no is performing in different countries. If people could post their ping time and country that would be great.

Currently ez.no servers are located in Norway, so unfortunately this will mean more sluggish performance for countries far away, like Australia, New Zealand, etc.

Edit: A traceroute is of course even better.

Ole M.

Modified on Wednesday 21 May 2008 4:44:51 pm by Ole Morten Halvorsen

Wednesday 21 May 2008 2:30:24 pm

Oslo (Norway):
min: 8ms, max: 9ms

Maybe check the isp, some isp's here doesn't have a fast connection out of Norway to save cost's ( they are usually only used for normal Internet connection, so normal users won't notice it ).

Modified on Wednesday 21 May 2008 2:33:15 pm by André R

Wednesday 21 May 2008 2:35:51 pm

Paris (free.fr adsl): 85 - 92 ms

Wednesday 21 May 2008 3:52:55 pm

Katowice (Poland): 165ms (adsl, tp.pl)

Wednesday 21 May 2008 4:11:29 pm

I think it's better to make <i>traceroute</i> than <i>ping</i>, so that we can check where exactly problem is. There is also very useful visualroute http://visualroute.visualware.com application that provides a graphical traceroute to any server.

From Poland route is crazy:
- (Gdańsk)
- (Warsaw)
- Germany (Frankfurt)
- USA (Washington )
- Denark
- Norway

The biggest loss is on transatlantic Telia connection...

Friday 23 May 2008 9:14:16 pm

Christchurch (New Zealand) - Cable w/ Telstraclear

--- ez.no ping statistics ---
6 packets transmitted, 6 packets received, 0% packet loss
round-trip min/avg/max/stddev = 344.818/347.976/354.859/3.828 ms

354ms.. oh my.

Saturday 24 May 2008 2:22:35 am

From Las Vegas, NV USA (10mbit up and down)

Tracert
1 1 ms 1 ms <1 ms 192.168.2.1
2 9 ms 22 ms 9 ms ip68-104-4-1.lv.lv.cox.net [68.104.4.1]
3 9 ms 11 ms 8 ms 24-234-1-201.ptp.lvcm.net [24.234.1.201]
4 9 ms 9 ms 22 ms 24-234-6-25.ptp.lvcm.net [24.234.6.25]
5 34 ms 33 ms 34 ms paltbbrj01-ae0.0.r2.pt.cox.net [68.1.0.234]
6 98 ms 97 ms 100 ms ge2-0-0.10G.nyk2nxg2.ip.tele.dk [83.88.23.118]
7 213 ms 213 ms 211 ms pos0-0-1-0.9953M.boanqh1.ip.tele.dk [83.88.26.10
5]
8 210 ms 214 ms 214 ms pos0-0-0-0.9953M.stkm4nqh1.ip.tele.dk [83.88.26.
34]
9 213 ms 213 ms 213 ms pos1-0.2488M.nydnxg1.ip.tele.dk [83.88.13.93]
10 210 ms 214 ms 212 ms pos8-0.2488M.nyd-p1.osl.no.tdcsong.net [83.88.31
.50]
11 214 ms 211 ms 212 ms ge9-2.1000M.nyd-gw1.osl.no.tdcsong.net [80.239.1
04.82]
12 215 ms 236 ms 218 ms 80.239.124.86
13 214 ms 214 ms 213 ms 80.239.124.146
14 216 ms 219 ms 230 ms 85.19.74.108

Ping
Pinging ez.no [85.19.74.108] with 32 bytes of data:

Reply from 85.19.74.108: bytes=32 time=231ms TTL=52
Reply from 85.19.74.108: bytes=32 time=216ms TTL=52
Reply from 85.19.74.108: bytes=32 time=231ms TTL=52
Reply from 85.19.74.108: bytes=32 time=217ms TTL=52

Ping statistics for 85.19.74.108:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 216ms, Maximum = 231ms, Average = 223ms

Saturday 24 May 2008 12:15:00 pm

From Belgium

traceroute to vir.ez.no (85.19.74.108), 64 hops max, 40 byte packets
1 192.168.1.1 (192.168.1.1) 2.970 ms 2.108 ms 1.950 ms
2 ip-62-235-157-1.dsl.scarlet.be (62.235.157.1) 8.808 ms 8.212 ms 8.238 ms
3 194.119.224.177 (194.119.224.177) 8.819 ms 9.074 ms 8.435 ms
4 194.119.226.18 (194.119.226.18) 9.025 ms 8.708 ms 8.408 ms
5 zvtm-s1-rou-1042.be.eurorings.net (134.222.148.132) 9.857 ms 8.380 ms 8.066 ms
6 zvtm-s1-rou-1041.BE.eurorings.net (134.222.231.253) 9.461 ms 8.785 ms 9.470 ms
7 asd2-rou-1021.NL.eurorings.net (134.222.231.185) 12.121 ms 12.061 ms 11.907 ms
8 195.190.227.220 (195.190.227.220) 12.042 ms 13.255 ms 12.004 ms
9 ge1-0-0.10G.asd9nxg1.ip.tele.dk (195.69.144.104) 26.557 ms 26.325 ms 27.193 ms
10 ge0-0-0.10G.asd9nxg2.ip.tele.dk (83.88.15.130) 26.837 ms 27.519 ms 27.176 ms
11 pos0-0-1-0.9953M.boanqh2.ip.tele.dk (83.88.22.221) 48.307 ms 47.535 ms 47.593 ms
12 pos1-0.2488M.oslo1nxg1.ip.tele.dk (83.88.28.194) 47.002 ms 47.004 ms 46.979 ms
13 pos0-0.2488M.nydnxg1.ip.tele.dk (83.88.3.45) 47.890 ms 47.260 ms 47.814 ms
14 pos8-0.2488M.nyd-p1.osl.no.tdcsong.net (83.88.31.50) 47.843 ms 47.502 ms 48.908 ms
15 ge9-12.1000M.nyd-gw1.osl.no.tdcsong.net (80.232.27.178) 47.528 ms 47.866 ms 47.195 ms
16 80.239.124.86 (80.239.124.86) 51.870 ms 52.350 ms 51.250 ms
17 80.239.124.146 (80.239.124.146) 51.733 ms 51.827 ms 52.318 ms
18 85.19.74.108 (85.19.74.108) 51.746 ms 52.587 ms 52.685 ms

ADSL 6Mbit/640kbit down/up

But indeed, ez.no feels a bit slower here too since it was moved from Oslo to the HQ in Skien, albeit no hard data to support this feeling

Paul

Sunday 25 May 2008 9:43:47 pm

Hello,

From Montpellier, France :
PING ez.no (85.19.74.108) 56(84) bytes of data.
64 bytes from 85.19.74.108: icmp_seq=1 ttl=45 time=139 ms
64 bytes from 85.19.74.108: icmp_seq=2 ttl=45 time=161 ms
64 bytes from 85.19.74.108: icmp_seq=3 ttl=45 time=139 ms
64 bytes from 85.19.74.108: icmp_seq=4 ttl=45 time=139 ms

traceroute to ez.no (85.19.74.108), 30 hops max, 40 byte packets
1 192.168.0.1 (192.168.0.1) 10.081 ms 11.266 ms 11.251 ms
2 82.239.138.254 (82.239.138.254) 60.190 ms 61.418 ms *
3 * * *
4 * * *
5 * * *
6 * dijon-6k-1-v800.intf.routers.proxad.net (212.27.50.110) 68.457 ms 70.684 ms
7 * * strasbourg-6k-1-v802.intf.routers.proxad.net (212.27.50.133) 79.125 ms
8 francfort-6k-1-po100.intf.routers.proxad.net (212.27.56.30) 80.082 ms 90.566 ms *
9 amsterdam-6k-1-po100.intf.routers.proxad.net (212.27.56.38) 91.524 ms * *
10 * * *
11 * * *
12 pos0-0-1-0.9953M.boanqh2.ip.tele.dk (83.88.22.221) 137.220 ms * *
13 * * pos1-0.2488M.oslo1nxg1.ip.tele.dk (83.88.28.194) 132.102 ms
14 pos0-0.2488M.nydnxg1.ip.tele.dk (83.88.3.45) 130.363 ms 137.831 ms 130.592 ms
15 pos5-0.2488M.nyd-p2.osl.no.tdcsong.net (83.88.2.190) 130.306 ms 139.586 ms 130.591 ms
16 ge5-2.1000M.nyd-gw1.osl.no.tdcsong.net (80.239.104.86) 131.590 ms 136.589 ms 130.883 ms
17 80.239.124.86 (80.239.124.86) 138.591 ms 141.867 ms 139.076 ms
18 80.239.124.146 (80.239.124.146) 136.579 ms 134.628 ms 141.370 ms
19 85.19.74.108 (85.19.74.108) 137.594 ms 134.839 ms 135.584 ms

Modified on Sunday 25 May 2008 9:47:25 pm by Stéphane Bullier

Friday 30 May 2008 10:28:00 am

Webtraceroute from US server:

http://tools.pingdom.com/ping/?target=ez.no&o=1&save=true

Madrid -Spain

1 1 ms 1 ms 1 ms 172.26.0.1
2 46 ms 47 ms 48 ms 130.Red-213-98-13.staticIP.rima-tde.net [***.***.
***.***]
3 49 ms 52 ms 47 ms 81.Red-81-46-55.staticIP.rima-tde.net [***.***.***.
***]
4 49 ms 50 ms 47 ms So-5-0-0-0-grtmadpe3.red.telefonica-wholesale.ne
t.9.16.84.in-addr.arpa [84.16.9.161]
5 76 ms 98 ms 79 ms So5-2-0-0-grtlontl1.red.telefonica-wholesale.net
[213.140.43.254]
6 82 ms 72 ms 83 ms teledanmark-7-0-7-0-grtlontl1.red.telefonica-who
lesale.net [213.140.52.66]
7 73 ms 76 ms 75 ms ge4-0-0.10G.ldn2nxg2.ip.tele.dk [83.88.29.161]
8 108 ms 102 ms 108 ms ge5-0-0.10G.ldn2nxg1.ip.tele.dk [83.88.24.73]
9 123 ms 128 ms 114 ms pos0-1-4-0.9953M.boanqh1.ip.tele.dk [83.88.12.11
7]
10 115 ms 122 ms 110 ms pos0-0-0-0.9953M.stkm4nqh1.ip.tele.dk [83.88.26.
34]
11 109 ms 112 ms 113 ms pos1-0.2488M.nydnxg1.ip.tele.dk [83.88.13.93]
12 121 ms 119 ms 122 ms pos8-0.2488M.nyd-p1.osl.no.tdcsong.net [83.88.31
.50]
13 107 ms 109 ms 112 ms ge9-12.1000M.nyd-gw1.osl.no.tdcsong.net [80.232.
27.178]
14 123 ms 127 ms 121 ms 80.239.124.86
15 116 ms 121 ms 119 ms 80.239.124.146
16 113 ms 122 ms 113 ms 85.19.74.108

Bayern - Germany

traceroute to ez.no (85.19.74.108), 30 hops max, 52 byte packets
1 static.161.71.46.78.clients.your-server.de (***.***.***.***) 0.294 ms 0.221 m s 0.243 ms
2 hos-tr4.juniper3.rz4.hetzner.de (213.239.244.193) 0.493 ms 0.239 ms 0.243 ms
3 hos-bb1.juniper2.s02.hetzner.de (213.239.240.232) 1.243 ms 0.740 ms 0.867 ms
4 83-141-1-34.static.aixit.com (83.141.1.34) 3.867 ms 3.739 ms 3.743 ms
5 ffm2nxg1.ip.tele.dk (80.81.192.16) 4.491 ms 4.612 ms 5.491 ms
6 pos0-0.2488M.ffm2nxg2.ip.tele.dk (83.88.21.14) 35.351 ms 34.966 ms 34.601 ms
7 pos0-1-0-0.2488M.alb2nqh2.ip.tele.dk (83.88.26.154) 36.475 ms 34.976 ms 3 5.476 ms
8 pos0-2-0-0.9953M.boanqh2.ip.tele.dk (83.88.25.154) 34.975 ms 34.847 ms 34 .227 ms
9 pos0-0.2488M.oslo1nxg1.ip.tele.dk (83.88.13.90) 34.352 ms 34.476 ms 34.10 3 ms
10 pos0-0.2488M.nydnxg1.ip.tele.dk (83.88.3.45) 144.050 ms 168.662 ms 200.52 4 ms
11 pos5-0.2488M.nyd-p2.osl.no.tdcsong.net (83.88.2.190) 34.976 ms 34.973 ms 34.478 ms
12 ge5-2.1000M.nyd-gw1.osl.no.tdcsong.net (80.239.104.86) 34.851 ms 34.348 ms 34.978 ms
13 80.239.124.86 (80.239.124.86) 39.224 ms 38.970 ms 38.850 ms
14 80.239.124.146 (80.239.124.146) 39.848 ms 39.971 ms 39.976 ms
15 85.19.74.108 (85.19.74.108) 40.349 ms 40.722 ms 40.348 ms

Wednesday 30 July 2008 12:27:53 pm

Hi guys,

this will always be a problem due to the the long distance to some locations over the world.

An example:
The client is located in LA (US), the server in Europe
The ping time from LA to the European sever is 180ms average
A page makes 25 request (4 .js files within the head)
The page generation on the server takes 0.5 sec

Result:
Each request has at least 180ms overhead = 4.5 sec lost
+ page generation on the server 0.5 sec
+ .js files within head ~0.5 sec (within the head js files are loaded one after another)

loss:
This means a loss of at least 5.5 sec and doesn't include any transfer !

This can be solved if eZ joins a content delivery network to deliver the static items like js,css, and images or if eZ sets up their own small delivery network with some different servers in different continents.

We also made an implementation of an output filter which enables you to rewite the urls for static content which is delivered from the extensions (Simply by using RegEx).

This enables you to use different servers for different types of content.

For example you can deliver javascript files from http://js.example-cms.com,
static images (layout mainly) from http://static.example-cms.com
and css files from http://css.example-cms.com
and the dynamic content from your normal url http://www.business2web.com

To sync the static content we use a simple rsync cronjob-script which is very fast.

This also improves the normal loading time, because the client makes more request to different servers. (-> Golden performance rules)

In addition this may also be used to deliver content from a location that depends on the client.

We also submitted the filter to the kernel so this will hopefully be available by standard in eZ 4.1

Cheers blunk.gif Emoticon

Modified on Wednesday 30 July 2008 12:33:17 pm by Norman Leutner

Wednesday 30 July 2008 12:35:13 pm

In addition you can use Varnish on the servers for the static content.

Monday 04 August 2008 9:41:33 am

66-82 ms from Kyiv, Ukraine (volia.com)

tracert is 18 hops long:

 1    <1 мс    <1 мс    <1 мс  my.router [192.168.1.1]
 2    11 ms    13 ms    14 ms  ip.82.144.213.1.stat.volia.net [82.144.213.1]
 3     9 ms     7 ms     7 ms  v74.TenGig3-2.diamond.volia.net [82.144.194.66]
 4     9 ms    10 ms    10 ms  kiev-b1-link.telia.net [213.248.98.249]
 5    27 ms    34 ms    28 ms  win-b2-link.telia.net [80.91.249.91]
 6    40 ms    47 ms    41 ms  ffm-bb1-link.telia.net [80.91.252.78]
 7    42 ms    42 ms    39 ms  ffm-b1-link.telia.net [80.91.254.97]
 8    41 ms    43 ms    43 ms  tdc-114354-ffm-b1.telia.net [213.248.77.54]
 9    68 ms    65 ms    65 ms  pos0-0-2488M.ffm2nxg2.ip.tele.dk [83.88.21.14]
10    71 ms    86 ms    83 ms  pos0-1-0-0-2488M.alb2nqh2.ip.tele.dk [83.88.26.154]
11    94 ms    73 ms    62 ms  pos0-2-0-0-10G.boanqh2.ip.tele.dk [83.88.25.154]
12     *        *        *     Превышен интервал ожидания для запроса.
13    64 ms    64 ms    62 ms  pos0-0-2488M.nydnxg1.ip.tele.dk [83.88.3.45]
14    67 ms    69 ms    65 ms  pos5-0.2488M.nyd-p2.osl.no.tdcsong.net [83.88.2.190]
15    65 ms    63 ms    64 ms  ge9-14.1000M.nyd-gw1.osl.no.tdcsong.net [80.232.27.154]
16    76 ms    70 ms    73 ms  80.239.124.86
17    69 ms    70 ms    74 ms  80.239.124.146
18    76 ms    75 ms    74 ms  ez.no [85.19.74.108]

Monday 04 August 2008 10:13:37 am

 traceroute ez.no
traceroute to ez.no (85.19.74.108), 30 hops max, 40 byte packets
 1  192.168.2.1 (192.168.2.1)  2.176 ms  0.809 ms  0.753 ms
 2  192.168.0.1 (192.168.0.1)  1.049 ms  1.113 ms  0.925 ms
 3  bras11-l0.rcsntx.sbcglobal.net (151.164.182.26)  11.280 ms  13.309 ms  10.356 ms
 4  dist2-vlan120.rcsntx.sbcglobal.net (151.164.162.67)  9.642 ms  9.487 ms  10.752 ms
 5  bb2.10g3-0.rcsntx.sbcglobal.net (151.164.243.97)  9.433 ms  9.183 ms  9.027 ms
 6  151.164.243.128 (151.164.243.128)  49.145 ms  49.010 ms  49.044 ms
 7  ge0-0-0.10G.nyk2nxg1.ip.tele.dk (206.223.131.3)  50.280 ms  50.065 ms  50.437 ms
 8  ge2-0-0-10G.nyk2nxg2.ip.tele.dk (83.88.23.118)  50.394 ms  51.680 ms  50.814 ms
 9  pos0-0-1-0-10G.boanqh1.ip.tele.dk (83.88.26.105)  155.724 ms  157.555 ms  165.526 ms
10  pos0-0-0-0-10G.stkm4nqh1.ip.tele.dk (83.88.26.34)  163.163 ms  163.588 ms  163.029 ms
11  pos1-0-2488M.nydnxg1.ip.tele.dk (83.88.13.93)  164.086 ms  164.203 ms  163.599 ms
12  pos5-0.2488M.nyd-p2.osl.no.tdcsong.net (83.88.2.190)  164.801 ms  169.973 ms  165.002 ms
13  ge9-14.1000M.nyd-gw1.osl.no.tdcsong.net (80.232.27.154)  159.077 ms  158.872 ms  158.837 ms
14  80.239.124.86 (80.239.124.86)  167.758 ms  167.614 ms  167.755 ms
15  80.239.124.146 (80.239.124.146)  166.304 ms  164.505 ms  164.355 ms
16  85.19.74.108 (85.19.74.108)  166.690 ms  165.107 ms  164.870 ms

<i>//kracker

Korn - Sing Sorrow</i>

Monday 04 August 2008 11:12:07 am

I think a fast distributed environment is a must, after all this is the direct target market for eZ Publish. So a US and Asian environment would make complete sense. Not a cache server a full synced environment.
It will make a good case study for ez.no

For the Traceroute, please bear the following in mind

http://blog.theplanet.com/2007/06...aceroute-our-misunderstood-friend-2/

<i>A question that I often face - what IS a traceroute? Most individuals know that it represents the “hops” or routers along the path from a system’s IP to the destination IP entered. What’s most often misunderstood is the response time numbers printed for each hop. Some assume that it is the time any packet takes to make that leg of the journey. But, that just isn’t the case.</i>

Monday 04 August 2008 1:15:16 pm

Tony your idea doesn`t make sense when Normans idea delivers 95% of what is needed with only 5% of the costs compared to your solution.

Monday 04 August 2008 1:33:27 pm

Hi Bjorn,

Thank you for the directness of your reply.

Let me explain my thinking.

This is as much an opportunity for marketing as it is an opportunity to solve a technical problem.

>>Global
By showing eZ Publish can work in a Global capacity (not just a single server location) you can show corporates that eZ Publish can help them with the global needs. This means it can help with local editing speeds as well as global load balancing. This is a big issue with a platform that contains both editing and publishing platforms.

>>Cache
Of course adding a cache, locally and in each region will improve performance but there is no reason why you cannot do both. Remember ez.no is not just a site, it is an eZ Publish showcase.

Tony

Monday 04 August 2008 1:50:04 pm

Hi Tony,

I definitly like to see such a case that you have shown to us. So far I havn`t come across a client that needs this.

Also when you start thinking about it, I would think that the database software supplier plays a big role in realizing this case/solution.

Monday 04 August 2008 2:06:27 pm

>>Edit and Publish in the same platform.
We see it when we have high traffic sites with large editorial teams. The problem is that when the site is busy the speed of editing slows down for the editor. This means you end up paying more per page edit.
In the ideal situation this is not a problem, but when you deal with countries with slow internet connections it becomes a show stopper.

>>database
I do not understand what you mean by the database supplier can you explain.

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from