> On June 17, 2012, 1:37 p.m., Michael MacFadden wrote: > > This looks ok to me, but i do have some questions. Assuming the CND > > example, how would this work. It seems like the web socket address is > > inserted into the GXP context dynamically. Would the output of the GXPs be > > cached at the CND? Also, if using a CND would the client browser actually > > hit the front end address or would they be pointed to the CND? > > > > Can you describe what files and resources would be at the CDN node and how > > the client browser would interact with the CND and the live server? > > Especially regarding loading of the javascript and figuring out where to > > connect back to?
All the normal traffic of the client (except websocket traffic) comes from the CDN but depending on how aggressive is the CDN caching configured. The websocket traffic connects directly to other port/domain bypassing the CDN. In our case, kune.cc points to our CDN (currently cloudflare), and www.kune.cc points to our server and is used for the websocket traffic. You can see with firebug which traffic comes directly from the CDN opening https://kune.cc. If you configure SSL the certificate should include both domains. Looking the yesterday stats, half of the traffic is saved by the CDN. Maybe someone knows other techniques to make services like Wave more scalable. - Vicente J. ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/5375/#review8315 ----------------------------------------------------------- On June 17, 2012, 12:45 p.m., Vicente J. Ruiz Jurado wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/5375/ > ----------------------------------------------------------- > > (Updated June 17, 2012, 12:45 p.m.) > > > Review request for wave, Michael MacFadden, Yuri Zelikov, and Ali Lown. > > > Description > ------- > > The idea is that the client uses two configurable listening addresses: > - one for the normal traffic (all the common server petitions), the current > http_frontend_public_address > - and a new one for the websocket traffic (that can be configured to a > different subdomain or port if it's necessary). > > That is, we would be able to split these two different traffics. This would > allow the use of proxies, caches or CDNs for the "normal traffic". > > Issue: > https://issues.apache.org/jira/browse/WAVE-357 > > > Diffs > ----- > > server-config.xml 5f39312 > server.config.example 0d3da67 > src/org/waveprotocol/box/server/CoreSettings.java d9b95ec > src/org/waveprotocol/box/server/gxp/WaveClientPage.gxp cea296a > src/org/waveprotocol/box/server/rpc/ServerRpcProvider.java 82c3c8d > src/org/waveprotocol/box/server/rpc/WaveClientServlet.java f8a95f2 > src/org/waveprotocol/box/webclient/client/WebClient.java b16df98 > > Diff: https://reviews.apache.org/r/5375/diff/ > > > Testing > ------- > > Tested with different ports/subdomains, for example with this in /etc/hosts > as websocket domain > 127.0.0.1 ws.localhost > but also tested in a production server. > > > Thanks, > > Vicente J. Ruiz Jurado > >
