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

Monday 19 May 2008 5:02:39 am

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.

Paul Bolger

Wednesday 21 May 2008 5:08:30 am

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.

Senior Software Engineer - Vision with Technology

http://www.visionwt.com
http://www.omh.cc
http://www.twitter.com/omh

eZ Certified Developer
http://ez.no/certification/verify/358441
http://ez.no/certification/verify/272578

Wednesday 21 May 2008 5:35:51 am

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

Principal Consultant International Business
Member of the Community Project Board

Wednesday 21 May 2008 7:11:29 am

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...

Baobaz
http://www.baobaz.com

Friday 23 May 2008 5:22:35 pm

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

Sunday 25 May 2008 12: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

Stéphane

Wednesday 30 July 2008 3:27:53 am

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 ;)

Mit freundlichen Grüßen
Best regards

Norman Leutner

____________________________________________________________
eZ Publish Platinum Partner - http://www.all2e.com
http://ez.no/partners/worldwide_partners/all2e_gmbh

Monday 04 August 2008 12: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]

NXC - OPEN RELIABLE

Monday 04 August 2008 2: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/07/traceroute-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>

Tony Wood : twitter.com/tonywood
Vision with Technology
Experts in eZ Publish consulting & development

Power to the Editor!

Free eZ Training : http://www.VisionWT.com/training
eZ Future Podcast : http://www.VisionWT.com/eZ-Future

Monday 04 August 2008 4:33:27 am

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

Tony Wood : twitter.com/tonywood
Vision with Technology
Experts in eZ Publish consulting & development

Power to the Editor!

Free eZ Training : http://www.VisionWT.com/training
eZ Future Podcast : http://www.VisionWT.com/eZ-Future