Hi Omer and thanks for the useful info.

We are currently in contact with several Swiss hosting companies, but so far we have not managed to find one offering dedicated php hosting, with 24/7 tech support in English, at a price we can afford.

If we manage to find an affordable hosting solution in Switzerland, we will definitely test it, and if we find that it improves the speed, we will use it.

Thanks again

Oded

SiteAdmin Oded, Sep 2, 2009 @ 13:15

 i compared the traceroute results on glocals.com and infomaniak.ch. check it out oded.
the access is 1000 times faster on infomaniak in geneva.
cheers


epicure, Sep 2, 2009 @ 15:18

No offense , but some people obviously dont have something better to do in their life.
Who gives a shit... it takes a few msec more ?

Coopy, Sep 2, 2009 @ 16:24

This user is certainly ignorant about technical details about how enterprise systems works, and the comments made are certainly unintelligent given the fact glocals admins have put such an enormous effort (I am sure many sleepless nights) to optimize the site in the past few weeks.

Fernay Voltaire once famously said "Common sense is not so common after all".




hyeomer, Sep 2, 2009 @ 17:02

 Thanks Oded for the reply and updating us.

"epicture" also ran some tests on infomaniak and saw the lowest possible delay.

Since you mentioned about the finding an affordable solution, perhaps it would be a good idea to evaluate some possible "paid membership" models...I am just throwing an idea in the hat. After all, so many people use and benefit from glocals, so I assume some combination of free/paid membership could be fair deal.

Given the number of users on glocals right now, if 10% of them takes up the paid model, I guess this could be enough.

Cheers
Omer

hyeomer, Sep 2, 2009 @ 17:14

 Thanks for your tests epicture :-)

Cheers

hyeomer, Sep 2, 2009 @ 17:18

 yes, i DO have better things to do in my life than "watch paint dry" on slow response times. and, "i do give a shit" maybe you don't mind......i guess it's what you are used to and expectations.

epicure, Sep 2, 2009 @ 18:26

 plus some of using mobile broadband appreciate fast connections (or low and behold .. still using telephone dial-up internet connections) ! milliseconds are a measure of one packet .. but as traffic increases .. these milliseconds become seconds .. and in some cases minutes ! Good job to the computer techies .. both admin and hyeomer/epicure for at least caring about these little unforgotten things ...

Sporty, Sep 2, 2009 @ 18:39

 I ran the test for English Forum (hosted out of Germany).

TraceRoute to 87.106.55.131 [www.englishforum.ch]

I can't really read/interpret the results, but it seems that it takes more time to access that site than Glocals (if I read the output correctly).

HOWEVER, the response time of EF is still smokingly fast compared to the latest improvements on the new Glocals site. And yes, there have been improvements.

I would still suggest that you go back to the comments on the other feedback thread that talks about the "heaviness of the Glocasl pages". I am sure that there is still lots of clean up that can be done there.

Good luck.

P.S. I am running on a 10mb connection so I expect the pages to load quickly.












Verbier, Sep 2, 2009 @ 18:35

 yeah, as if you don't have enough on your plate....you need to have a site which scales
nicely for things like the iPhone. Facebook has a great app for iPhone which lets you stay on
FB with a very slick interface......


Zonker, Sep 2, 2009 @ 18:57

 Hey Verbier,

I ran the traceroute test for EnglishForum.ch. This site is located in Germany. Here are details:
traceroute to www.englishforum.ch (87.106.55.131), 64 hops max, 40 byte packets
 1  r864-1-rhpzm-1-ip11 (137.138.193.193)  13.756 ms  4.424 ms  0.600 ms
 2  r874-b-rhpzl-2-sb70 (194.12.142.45)  0.550 ms  1.164 ms  0.311 ms
 3  b513-b-rfte6-1-ab55 (194.12.140.9)  0.517 ms  0.339 ms  3.385 ms
 4  g513-e-rci76-1-pg1 (194.12.144.9)  0.586 ms  3.211 ms  0.455 ms
 5  g513-e-rci76-1-fe1 (192.65.184.165)  1.715 ms  1.349 ms  1.518 ms
 6  e513-e-rci76-1-pe1 (192.65.184.161)  3.167 ms  1.380 ms  1.200 ms
 7  195.141.236.205 (195.141.236.205)  1.121 ms  1.114 ms  1.137 ms
 8  linx.bb-c.the.lon.gb.oneandone.net (195.66.224.98)  20.115 ms  20.378 ms  20.069 ms
 9  te-1-3.bb-c.bap.rhr.de.oneandone.net (212.227.120.49)  36.031 ms  34.457 ms  34.515 ms
10  ae-11.gw-distp-a.bad.oneandone.net (212.227.122.5)  97.188 ms  171.762 ms  210.657 ms
11  ae-1.gw-prtr-r231-a.bad.oneandone.net (195.20.247.50)  27.310 ms  26.917 ms  45.122 ms
12  s15311167.onlinehome-server.info (87.106.55.131)  24.441 ms  26.124 ms  24.481 ms

After 7th hop, the response time jumps to the scale of 10's ms as compared to 1's ms prior to that. This is where internet connectivity between Switzerland/Germany taking place and after that we start seeing longer delays. But since it's still very near to Geneva, that's why you get a faster response from the site..
 
You can see the server details that its located near Frankfurt region which hosting EF:
http://www.ip-adress.com/ip_tracer/87.106.55.131

Cheerio
Omer

hyeomer, Sep 2, 2009 @ 19:24

 Thanks for your positive feedback Sporty :-)

You have hit the right point that msec adds up to seconds and for 10k simultaneous users pinging the same server is a quite a hard job for that server to respond...

Since the server is far away in Mediterranean network, my analysis is that lots of responses from the server time's out since TCP/IP protocol works with acknowledgment hand-shake mechanisms. Thus all the timed out packets have to be resent by the server which also wastes addtional network bandwidth.

hyeomer, Sep 2, 2009 @ 19:29

 Yeah Facebook is a nice example actually..

The other day, the former chief scientist gave us an interesting talk@CERN about how FB manages data synchronization, scalability, collecting user feeds and then updating on the profiles...

It's pretty amazing...its the same with YouTube or Google. They have data centers on each continent to cater the needs of their local-regional users to avoid "long distance" network requests :-)

FB app or iPhone app for GLocals would be cool to have :-)

hyeomer, Sep 2, 2009 @ 19:32

Guys - thanks alot for the advice, but I'd like to understand one thing:

Is the site still slow?

Thanks

Oded

SiteAdmin Oded, Sep 2, 2009 @ 19:45

 Hi Oded,

It's hard to quantify.

Under off-peak loads, its  faster.

Under peak loads, its slows down considerably. This is the improvement zone for optimization.

Cheers
Omer

hyeomer, Sep 2, 2009 @ 19:57

No complaint about the speed from my end of the Internet, seems pretty quick to me. One minor niggle is Opera compatibility: if I 'Reply with Quote' the post button doesn't work. But that's probably for a different thread. 
rich_t, Sep 2, 2009 @ 20:16

 It is still taking 3-5 seconds to change/load pages. Yes, this is considered slow.

Verbier, Sep 2, 2009 @ 21:19

On my machine a facebook profile page takes on average 1.2-2.7s to be
completely loaded including images, here on glocals, a profile page
takes 15s on average and often up to 25s ..according to Firebug statistics.
Vitaly, Sep 2, 2009 @ 22:43

Later measurement gave about 6s to glocals profile page which is not bad.

Vitaly, Sep 2, 2009 @ 23:02

Guys - there seems to be a nice concentration of professionals on this thread, so maybe you can help me understand whether or not there is a speed issue.

Epicure says that waiting for pages to load is like watching paint dry, Rich says he does not see a speed issue, and Vitaly says it takes between 6 -25 seconds for a page to load.

So which is it?  No speed issue, or 25 seconds per page?

Thanks alot for your help

Oded

SiteAdmin Oded, Sep 3, 2009 @ 09:06

Bugs and a missing functionality is the priority one to me as for a site user. Personally I would like a chat back better... Regarding the speed issue I wouldn't worry that much. You can easily overcome it just by building a cluster on top of a number of powerful servers (not sure about PHP scalability) located here in Switzerland but if you cannot afford it right now - just drop it ;) Anyway "Early optimization is the root of much evil" everybody knows..

Vitaly, Sep 3, 2009 @ 09:09

Thanks Vitaly.

Barring any unforseen circumstances, the chat, and the photos from the old site, will be back next week.

Oded

SiteAdmin Oded, Sep 3, 2009 @ 09:52

Different pages have different response time e.g. home page response is different from email_inbox/email_sent. Similar differences are visible for "things to do" and "forums" and once the photos section get added, then additional image payload will further hog the bandwidth.

This will certainly not fly well with the chat since it requires the response time to be much faster; imagine sending a chat message and then waiting for some where between 5 -25sec to get to them, and more or less same amount for the response. This will be a major turnoff for the chat functionality.





hyeomer, Sep 3, 2009 @ 10:12

 Guys,

The best approach would be to test and validate methodologically.

I started a response time monitoring process for the site and following are test configurations:

1) home page
2) things to do
3) members
4) forums

The site was monitored from different network locations, and we can safely assume that values for US would be the same for EU since Mediterranean is separate across Atlantic and Europe.
 
The results showed that home page on avg. took 989 ms while it was largest for the forums where it took around 1418ms. Members and things to do fell some where in between.

You can view the results here:
http://okhalid.web.cern.ch/okhalid/glocals.png

NOTE: these tests have been running since mid-night yesterday and doesn't include peek usage which I guess hits around between 9am-11am and 7pm - 10pm (rough guessing).

I will post the updated results in the evening to have the clearer picture of site response time under peak and off peak loads. It was earlier mentioned that some how missing functionality is more important then then optimization, I don't think so. Missing functionality is only going to add more load on the system as more people will use it so "early but selective optimization is definitely not evil" in this case ;-)

Omer

hyeomer, Sep 3, 2009 @ 10:27

The chat cannot become worse then it was being attached to the old site but it was usable enough so take it as a prove of concept ;)

Vitaly, Sep 3, 2009 @ 10:33

 Some how results link didn't work last time around, here we go again!

http://www.cern.ch/okhalid/glocals.png

hyeomer, Sep 3, 2009 @ 10:42

Can you suggest something certain to do about the speed "issue" or maybe you have a spare cluster in Switzerland that you can lend them for free? ) As it was already said the hosting prices were not affordable so far..

Vitaly, Sep 3, 2009 @ 10:46

 Read the whole thread first! 
Few suggestion have been already made, in case you have missed:
1) site migration to Switzerland2) paid membership models to fund the affordabillity issue3) If Swiss is too expensive, migrating the site to continental europe would still be better, and I am sure there are cheap/affordable options in France/Germany or atleast at par with hosting option in far away country in middle east.
Lack of access to source code of the application prevent the users (like me and otthers ) to make any further concrete optimization suggestion. Users can only do black box testing and that what we have been doing. Since you are from IT, you should know that!
hyeomer, Sep 3, 2009 @ 11:17

Hi again Omer

Any chance you could add the Classifieds > Housing page to your test?

Thanks

Oded

SiteAdmin Oded, Sep 3, 2009 @ 11:34

 www.pilotsystems.net will host a PHP site with all-round engish support.

Servers are in Paris, a 3 hour train ride from Geneva, and a .025 second journey for a 16kb packet of data.

facemelter, Sep 3, 2009 @ 11:33

 Hi Oded,

I actually did that already last night :-)

But I didn't display the classified results in the results page (the link I sent in the morning). I will display classified results in the next result refresh.

Cheers
Omer

hyeomer, Sep 3, 2009 @ 11:56

 Hi Omer



1)
site migration to Switzerland



already said, not affordable yet



2) paid membership models to fund the
affordabillity issue



Oh, come on.. even facebook is free, in this case I will adapt one of my unfinished projects just to fill this gap ;))



3) If Swiss is too expensive, migrating the site to
continental europe would still be better, and I am sure there are
cheap/affordable options in France/Germany or atleast at par with
hosting option in far away country in middle east.



you are more then welcome to provide some considerable options ;)



Vitaly


Vitaly, Sep 3, 2009 @ 11:59

Come on guys - there's no need to argue.

Everyone is doing their best to help, and we appreciate it alot.

Thanks

Oded

SiteAdmin Oded, Sep 3, 2009 @ 12:02

 Hi Oded,

 It's not an dispute, it's a technical discussion )
 Regarding the topic I am quite sure that changing a hosting location you can address this issue to a certain extent. Omer is pointing in the right direction.

 Vitaly

Vitaly, Sep 3, 2009 @ 12:04

 Nice one :-)

hyeomer, Sep 3, 2009 @ 12:24

Guys,

Thanks again for the feedback.

To add to Oded's point:

If we were sure that moving the servers to CH would make a real noticeable impact on the site's speed, we'd do it quickly. Hosting it out of CH has benefits on lower costs and on better service, but all that is secondary to speed.

However, we're still trying to asses if moving to CH would get a noticeable impact, mainly as the site now loads (from CH) quickly. We run speed tests daily, and for the past week the homepage loads up in less than 1 sec. So cutting another 50% off this time still seems small...

What think?

Nir




Nir Ofek, Sep 3, 2009 @ 13:24

Hi Nir,

How many machines are you testing from? I work in Lausanne for a financial software company so we have a pretty good line. According to http://www.speedtest.net/summary.php I have an 8 meg download speed during peak hours at work, which is above average for general internet connectivity and the glocals site is now only slightly below average in terms of speed. The site is a lot faster since last week.

"Things to do" takes 4 seconds to load.
"Members" takes 6 seconds.
"Classifieds" takes 4/5 seconds.
Etc.

Which is sub-optimal for an application but fine for browsing I guess!!

facemelter, Sep 3, 2009 @ 13:29

 Hi Nir,

 I wouldn't bother much about a speed right now. It's fast enough in comparison to the old one. It is already a big step while an optimization is an endless story ) Several functions you have introduced recently and a number of old ones just don't work at all or misbehaving. Fix it and reach a milestone first. Optimization is just like an attractive candy. It often gives a filling that with a minimal effort you cat get a big improvement in speed so that everyone will say "wow" ;)

 Cheers,
 Vitaly

Vitaly, Sep 3, 2009 @ 13:47

 Guys,

So far so good...I think we had quite an active discussion so far and thanks to every body for their contribution.

Summary
========
Just to summarize the points raised so far so that we go step further in this "endeavor" :

* there is a broad agreement (among the technical minded users) so far that site have certainly improved its performance since its launch but it's sub-optimal for application performance as mentioned by "facemelter", "epicture", "verbier", "sporty"and by others.

* "vitaly" point is some-what credible about fixing the existing bugs, and defining a clear milestone and achieving it and then coming to the speed-optimization issue.

This is one approach but it doesn't exclude the site migration except it only suggest to do it after bug-fixing but its contradictory to say to add new features (more system load in simple terms) with our improving the previous system.

The second approach would be the following:

* since bug fixing is OK but bringing up new features will certainly improve part of user experience ( "wow effect" ) while adding more system load. If "site response" is considered (as in the case of most website) a critical litmus test to measure how happy are the users, then it definitely provides a strong basis for consideration. Since adding of new features will be continuous process and there will always be some thing new to add every few months, new-features is a never ending process and this will be putting more load on the server and network latency will have an aggregated compound effect. Thus it's valid to say that migrating the site to Switzerland or continental Europe holds priority over "overhead generating" new features.

But all of this could be subjective opinion, relative one's position and perspective. Right!

Results
======

That's why its very important to empirically prove the point with concrete performance data to separate "fact" from "opinion".

The tests I have been running on the site now have the results for peak usage. Have a look here: www.cern.ch/omer.khalid/glocals.png

Every test have to be measure against some bench mark (reference criteria), so I added the response time to Google (top right) which avg. 66ms where as now you will see not only large response times for peak usage-patterns for different sub-sites (homepage, forum, classified etc) but also there are the red-dots on the curves. These red-dots points to time-outs when site failed to send the response to the user at all.

Peak usage is the only time when one can measure site performance since all systems perform well, theoretically speaking, under 0ff-peak usage scenarios, and thus can never be considered a valid measurement criteria (in this case response time).

All these tests were conducted with out logging in to the site so that none of the application overhead was kicked in. This is to separate network-overhead from application-overhead. Once a user logs in and the application goes through all of its programmatic logic + SQL queries to build return pages, then the response times will be even longer. Imagine that with already timing-out pages.

Conclusion
==========

* yes, it would be good to define a concrete milestone for existing bug fixes while preparing some sort of feasibility is prepared for site migration.
* new features could be put on hold if tests show that they will only further slow down the system (glocals competitors performance have to be kept in mind here)
* after bug-fixes milestone, migration should be done.
* then next phase of newer features, further improvements could be conducted

* If affordability is an issue for migration, i certainly raise my hands to pool in some financial help for hosting-migration since i use glocals very often and it have been a very nice portal for social networking in geneva. Any one else? Vitaly?
hyeomer, Sep 3, 2009 @ 23:29

 Hi Omer,

I have nothing to say in addition actually.. It's fairly enough said.. I just feel a bit restrained since you know the glocals is a private project and I wouldn't go beyond some constructive (I hope) suggestions I could give so far..

Cheers,
 Vitaly

Vitaly, Sep 3, 2009 @ 23:33

Thanks again for the great advice / data guys.

We're looking into the things you mentioned.

Anyone else?

Oded

SiteAdmin Oded, Sep 4, 2009 @ 10:23

Have you tried using NGINX for the static files and/or varnish for caching all the static stuff?
I tried setting up varnish on my server, but it seems to be broken on the release of the OS I run currently.
You should move all static files to a different subdomain (static.glocals.com) and remove all cookies from them (varnish can only cache stuff without cookies).


rainer_d, Sep 4, 2009 @ 14:42

Have you tried turning it off and on again?

hayes, Sep 4, 2009 @ 23:59

 There are other ways to improve performance:sure, setting servers closer to target
destination (CH) would help, but any effort on reducing web pages weight could have a
significant impact, wherever the servers are. I'm pretty sure that some easy gains could be
reached, for instance a version with less or lighter pictures. But the developer team probably
has already thought about it, right?Another advantage would be the possibility to
show the site on iphones, which have a smaller screen...
GuillaumeTel, Sep 5, 2009 @ 08:40

 Are you really sure that the problem comes from the network site?

As the site  was completely changed, maybe is the new
method/technology slower than the previous one. Eg if you moved from PHP to jsp, I may
understand that page generation be different...Moreover, with the new system, I do
not see popup. They may save some network load if they are lighter than a real
page.
I don't say that the solution/issue is here, but it should be
investigated as well. If response time from the same country are similar to
those of Switzerland, then certainly the problems does not come from the network/server
location!
CheersGuillaume
GuillaumeTel, Sep 5, 2009 @ 20:16

 Well, I am still puzzled what causes the site to be very slow sometimes, in some configurations.
I mean slow compared to other websites, for example www.tsr.ch, bbc.uk.
From the work place - glocals.com is loading fast, that is all changes take place in a matter of seconds. What does this prove ?
But from my home computer all changes on the glocals.com pages are significantly slower than on the tsr.ch website.

jasper, Sep 5, 2009 @ 21:36

 Jasper,

The site loads faster at your workplace probably there you have a LAN connection while your connection bandwidth is lower.

Your observation is correct regarding the fast changes in site's response. This is probably due to "load" or number of simultaneous users.

Cheers

hyeomer, Sep 5, 2009 @ 22:12

 Guilaume,

Page generation time and technology related delay is called "application" delay to provide the service what it provides. In this case, glocals app is provide number of services like forums, classified, members, activities etc etc.

Network delay is independent of Application delay but it can cause the application not to function properly if it's too large, since the way internet works is that all the network packets are acknowledged by the recipient computers to the source in a frame-by-frame manner, and then source sends more and wait for acknowledgment before sending next packets. If network delay is large enough that some of these packets starts timing out on the way, then the source will keep on resending the same packets until the actual request times out (which will happen after few failures) or the application will become very slow.

This sort of problems are called "Emerging properties" of a system which will only appear when the system runs at peak but not otherwise. That's why they are always very difficult to pre-test or simulate.

Conclusion: Network delay's can have a significant effect on the application under peak load.

hyeomer, Sep 5, 2009 @ 22:14

Only the programmers can definitely answer the question why the site is slow sometimes.My guess would be that the DB is overloaded with "useless" queries, at times.Until the Admins give out some information, we can only make educated guess (which may or may be not of of limited usefulness)...
Where I work, we have a 100 MBit line to the internet and glocals still is not "fast".At home, I currently have 15 hops to the site. After the 11th hop, the latency goes into the triple-digit range - this is certainly not helping, but nothing I'd worry about until the latency of the site itself is improved. Though maybe you glocals guys can persuade your ISP to setup a peering at the Swiss Internet Exchange (TIX)? Compare the traceroute of glocals to that of google.com, who do have a peering setup at TIX.
Other websites have been dealing with larger audiences for a longer time and have had to put more resources into developing their apps and had to come up with clever solution (that don't involve adding more hardware) earlier.Just to put things into perspective, this link (for the interested student) provides an insight into how a site like facebook actually manages to survive the day-to-day operations:http://www.facebook.com/note.php?note_id=39391378919


rainer_d, Sep 5, 2009 @ 21:53

what causes slowing down ?

I have an info textline at the bottom of my windows screen monitoring data transfer.
When data transfer takes place it reads something like :
waiting for reply from www.gloclas.com
but then it also reads something like
waiting for reply from www.google-analytics.com

Does anyone know what this means ?
Is every move on glocals logged by google - contributing to the slowing down ?

jasper, Sep 6, 2009 @ 11:09

 Jasper,
No every move on glocals is not monitored by google analytics; it would just not be possible for google to do that.
Web admins always need to monitor and gather some statistics on their websites about where they are visited from, which pages are popular etc etc so that they plan, develop and organize things related to web development/management accordingly and possibly ad-targetting.
Traditionally, web hosting companies provided tools for doing this or web admins developed their own.
Google stepped into this arena ( for their own reasons) to provide online (free) tools for web admins to monitor their websites. Google Analytics is such one tool and glocals admins are using it, that's why you see this link appearing in your progress window. But it's not a cause of slowdown because your browser directly accesses google's website rather than going through glocals for statistical gathering otherwise such systems will not scale.
I hope that answers your question.
Omer
hyeomer, Sep 6, 2009 @ 17:23

I see the comments in this thread are well over a week old, but I'll bite.

I think that moving the site from Israel to Switzerland would certainly improve latency, but I don't think it would greatly benefit the overall performance. If you download this Firefox plugin and try saving the front page, you'll know why. The point is this: the front page is 1.7 megabytes big, and to load it completely, you'll have to download over 300 different files. No matter where you put your server, this is going to take some time!

So moving the server is a non-option, if you ask me. It will not structurally fix the problem, it will only alleviate the problem.

The only viable, structural solution to the slowness of the site is this:
1. reduce the number of files it has to download
2. reduce the total size that needs to be downloaded

Point 1 will accomplish three things:
a. it will reduce the stress on the server, as it will no longer need to spawn 300 process for each new (non-cached) request
b. it will reduce the time needed to download the site, since a browser will typically download something like 10 files at a time, max
c. it will reduce the time needed to download the site, since the waiting time (latency) is reduced from 300x(some time) to 20x(some time)

Point 2 will also accomplish more than one thing:
a. it will reduce the stress on the server, as the total amount of data that needs to be sent will be lower
b. since the amount of data that is transferred is lower, the user will finish the download quicker, and this will result in a faster site

As you can see, both of these points are a double edged sword: they reduce stress on the server, *and* they improve client-side performance. A webserver that is under heavy load serves pages slower than a regular webserver. Same goes for your computer: if it is doing 20.000 things at a time, everything will come to a crawl and it will barely respond to anything you click.

So that's it, basically. Reduce the total size of the page and reduce the number of HTTP requests and the site will be much faster. And be sure to check out this web page.

Best,
Edward

PS: contact me at [email protected] if you have issues like this at work or if you need any type of internet related consulting services

thedutchguy, Sep 15, 2009 @ 12:54

 He's right. About everything...

facemelter, Sep 15, 2009 @ 14:55

 TheDutchGuy:

Thanks. Makes good sense.

We plan to get back to speed optimising in the next few weeks. We gave the speed issue some first aid in the first 3 weeks after launch, and once it got an acceptable level we moved off to deal with some of the other urgent bugs.

When we get back to speed, your suggestions seem indeed the way to go. Our page is just ultra heavy.

Also, without a connection to the speed issue, our current homepage (after login) now shows some stuff that I think is useless for most members, and will be an easy candidate for removals:

- pictures of those who posted last on the forums
- pictures of members who recently joing glocals.com

Thanks again,

Nir

Nir Ofek, Sep 15, 2009 @ 15:29

Thanks. I know I probably got this point across in another post, but given the length of the thread I just had to respond :-)

Anyway, I wouldn't sweat it. The site doesn't seem too slow to me. But if you still want to optimize, this is the way to go. Some things I would do first:

1. use CSS sprites for the corners and the buttons
2. automatically scale the pictures, and serve the thumbnails instead of the full pictures
3. gzip the javascript, but don't do it as a server-setting. If you do that, it will probably zip each file time and time again, which will increase the load of your server instead of decreasing it. Instead, write a script that gzip's it once, and then serve that file instead of the original javascript. Saves you 400kb on ext-all.js alone.

Good luck with it! And, I must say, I think you've done a wonderful job on this site. I really like it. Keep up the good work!

Best,
Edward

thedutchguy, Sep 15, 2009 @ 15:33

 Server location matters little to the speed of the site, this is the same before the site move and after. 98% of the site speed issues before, and now are with the code. Before it was a mix of multiple generations of code that was the culprit, and now it is just a bit of a young codebase that is being improved, but at least not from multiple generations of web technology.

Let me put it in perspective. You are talking about a 0.2 second difference in time if the site is outside of Switzerland, ZERO point TWO seconds, it is hardly noticeable at all. Optimizing the code however makes multiple seconds of difference, as has already been shown.

these trace routes prove nothing at all, your computer and human eye can hardly process the difference in 38milliseconds and 100 milliseconds. there is one type of platform such matters at all and that is major FPS online gaming, where 'lag kills' but even though 100ms is not major lag that will cause problems. HTTP page loads make no discernible difference in speed for this.

moving a server to swtizerland, putting it direct to fiber, all these expensive things, would do little to nothing to help at all right now, or in the past. They would just be expensive folly to help someone get their jollies.
now there are some things that can be done to improve the speeds, and several of them are being done, and it is a slower process than some want, but it is maturing the codebase and bringing it along to make the glocals site a better place.

StephenSQL, Sep 15, 2009 @ 17:48

 these are all much more useful suggestions than moving the server :)

StephenSQL, Sep 15, 2009 @ 17:58

 I agree with Edward's suggestions (very concrete and
nice). 
These are standard approaches which should always be
implmented in large-user serving sites to reduce per request payload and resource
requirements on the server.
style="font-size: 11px; color: rgb(149, 117, 106); line-height: 22px; ">1. use CSS sprites for
the corners and the buttons
2. automatically scale the pictures, and serve the
thumbnails instead of the full pictures
3. gzip the javascript, but don't do it as a server-
setting. If you do that, it will probably zip each file time and time again, which will increase
the load of your server instead of decreasing it. Instead, write a script that gzip's it once, and
then serve that file instead of the original javascript. Saves you 400kb on ext-all.js
alone.
size="3">
This solves one aspect of the problem; payload size.
This will involve changes effort across the application (depending how it's designed and
implemented) == if good design, then lower development cost else higher development
cost.
Nevertheless, locatity issue of the payload will remain part
of the deployment any large enterprise application. It's impact could be reduced for the time
being but it will start biting back once again a certain threshold of usage/load/users is
crossed. Moving servers will cost less (in terms of development efforts) as long as a
hosting solution is available costing the same amount as of
now.
It's up to the admins to decide that which end of the problem
they want to work on first ;-)
Omer
hyeomer, Sep 15, 2009 @ 18:03

 The last part is where you are way off, glocals is in no way a large enterprise application.
nor is facebook, or myspace. They are cloud based sites on the internet, they are not LAN/WAN enterprise apps AT ALL.
You are all also not considering the fact of growth in the design, where you setup a server network in the US and in Europe, and Asia for future growth and redundancy. Cloud based apps are a totally different ballgame and 'enterprise applications' they work differently, they don't even work on the same network principles. These geocentric measures help some with speed, but many times are used only for redundancy and routing around network problems that may crop up and impact internet routing for short periods of time.

an enterprise application would design from the start with security, then look at interface, speeds, etc. Glocals has to implement security of course, but you are not talking about each visitors coming into a VPN to access it or anything like this, you have an open and public design that is accessed by all.




StephenSQL, Sep 15, 2009 @ 18:14

 "Enterprise" only represents the scale of the applications and quality of service
delivery where as "Cloud" represents how compute/storage resources are organized and
presented to its users. An enterprise application can be both deployed on a cluster of
computers (using any mode of connectivity: Lan - Wan - Infiniband etc etc) or on a
cloud.
Cloud but its just abstraction through which compute resources
are exposed to users in a unified model CPU/Storage/Network as compared to individual
services end points in "Grid" computing. A cloud at the back end are clusters inter-
connected and managed through a middle ware. 
I have
attended talks of Facebook developers and I can assure you that it's not only an enterprise
application but also not a cloud application ;-). The core app runs on its clusters (ofcourse
cache management done for geographical regions) accept the photo storage is manged
through "cloud" that's where you will often encounter "still downloading"
delays...
To explain further, enterprise applications can be both
deployed on the same servers and distributed servers. It depends on the needs. e.g. Wall
Street banks have extreme needs for High Frequency Trading systems where they sell-buy
shares are very narrow margins to generate small but volumouns profits. This all depends
on speed, and all the trade feeds are handled on single-cpu to reduce inter application
latencies. One such company, Solace, is news because they broke the microsecond
latency barrier for handling one-million msg per
second. 
All interested, can enlighten themselves further
over here:http://www.hpcwire.com/home/specialfeaturetopitem/Solace-Systems-
Sets-the-Pace-in-the-Race-to-Zero-Latency-
59263197.html


hyeomer, Sep 15, 2009 @ 18:51

 Even in that definition, glocals is in no way enterprise.

StephenSQL, Sep 15, 2009 @ 19:12

I have said earlier in the thread, and to repeat again this is matter of personal opinions about
how to classify. Intersting to discuss but it digresses from the issue at hand ;-
)
I think so far this thread have produced not only interesting discussions
but also many concrete suggests including hosting options available in CH/EU for the admins
to consider.
They it's a matter of decision, on part of sys admins, to
tackle which end first!



hyeomer, Sep 15, 2009 @ 19:14

 no it is not a matter of opinion, it is fact.

By no definition is glocals enterprise app, NONE.

In addition to this you could move the server to your local network right now and it would be no more than 0.3 seconds faster. It isn't the network, period.

StephenSQL, Sep 15, 2009 @ 19:20

 Hi Oded,
 By observing this thread, this discussion
have produced not only some very concrete suggestions from various members but also
generated lots of "emotions"! (I guess both goes hand in hand). This is a healthy sign
that there are people on the forum  who are motivated, interested and willing to
contribute in terms of thoughts and time. 
Edward's
suggestion of using CSS sprites is certainly a very good proposal worth
evaluating.
I think this thread should stay active as it have been
attracting technical minded glocals == free consultancy :-
)
CheersOmer
hyeomer, Sep 15, 2009 @ 19:28

 With all due respect, this is not consultancy at all, there have been a few helpful tips regarding the code output to the client from the server coded backend.

Few people here know the backend of the glocals site, prior to the move or after, but those that do are well advised. if moving a server would help here, I promise you it would have already been done by now.

consultancy requires knowing what you are consulting upon, and it can't just be done all on hypothetical when you are running a new code base, new location, new developers, and new admin team, as it is a real here and now problem and ongoing resolution.


StephenSQL, Sep 15, 2009 @ 20:25

 > consultancy requires knowing what you are consulting upon color="#585755" size="4">
color="#585755" size="4">In
theory;-)SCNR
rainer_d, Sep 15, 2009 @ 20:40

 Oh, seems I just found a  new bug.Please, try to filter out all the special
chars.I see XSS-attacks coming along.
Hm. Does it
work?><script
type="text/javascript">alert("XSS");</script>
rainer_d, Sep 15, 2009 @ 20:42

 Thankfully, it doesn't work!

StephenSQL, Sep 15, 2009 @ 20:46