@Daddy 如果底部菜单的右下角有个account的按钮，并且不是红色的，表示Editor会参与同步；反之，Editor不参与同步。

FarBox可以从Dropbox处同步数据（如果已经关联）；但不会同步数据回到Dropbox（Web Editor上或者其它调用模板API的put函数等除外）。

这个强制窗口无法关闭的，关闭了就会重新打开。因为无法找到一个站点目录，程序会无法运行。
不知道在这个创建site的窗口之前，程序有没有提醒找到Dropbox的目录呢？如果没有提醒找到Dropbox目录，那么有没有要求设置FarBox的根目录呢？

在你创建了一个site后，进入程序之后，可以在站点列表里找到其它网站吗？

Ctrl+Shift+C，打开配置目录，里面有log.txt文件吗？这个Editor同步的日志。如果有的话，说明Editor从FarBox服务器同步数据回来了。


可能是程序无法识别到你Dropbox内的FarBox目录，然后需要选定一个根目录，然后根目录内没有数据，这种情况不知是否可能？如果是这种情况的是，你选择根目录的时候，指定Dropbox内的FarBox，但是不要再直接关联账户了，否则Editor和Dropbox同时在同步，会有冲突（关于这点，在FarBox.com的官网上，Dropbox接入这个App页面内有说明）。

更多的，不知可否邮件联系我们？ [email protected] 在这里讨论感觉不是太合适。 :(

@kikyous @twor2 非常抱歉，关于图片无法显示的问题已经找到。以前为了修正一个bug造成的bug，会导致没有exif信息的jpeg图片在上传的时候无法正确处理。已经发布更新版，需要重新下载。原来无法显示的图片，需要重新拖入、或者改名。 :(

@linker 我们在下个版本中增加这个排序的设置。 :)

@Daddy 出现新建站点的一个modal窗口，是在刚运行的时候，应该不会是“已登录”。或者建一个不勾选同步的site，然后进去看看。可能FarBox的根目录发生了变化？

@armysheng 好久不见，没有做国内镜像。多数访问多数时候，下载的速度还是可以了，但也有倒霉的…… :(

@twor2 因为不知道具体的网站，所以不好判断。可以在自己的网站域名后加上/service/sync_logs这个路径，就可以访问到自己账户下的同步记录，不能显示的图片的event下如果有`not a image, ignore`则表示服务器端无法识别这个图片（如果是这种情况，可否将原图发一份给我们？ [email protected]）。

@Cater 不是很理解，新开一个桌面是指？

@wklken 谢谢，但应该不会这样做。一边不收费，一边收费，感觉不是太道义。 :)

@kikyous 换一张图片试试？ 如果不行的话，把图片作为附件给hi#farbox.com一份？ 有极少数图片的格式数据不太标准，服务端会无法识别。 :(

@jy02201949 目前仅仅对字体的变动，才会apply到preview窗口里，下次版本可能的话会把字体以及行高也对应过去。 :)


- - - - - - 以下，看到熟悉的ID们很开心呀。- - - - ---

@steveshi LOL, 我们再一起用很多年吧。

@yanwen 哈哈，这个大小已经没有办法了，跨平台以及一些额外package的引入，我们尽力压了……

@caoyue 这个可能就这样了。JS这块，我们可没有信心有做出超越现在一些产品，就不浪费时间了。但是开放了API，允许自己定义自己的WebEditor，貌似现在还没有用户自己做出来，我们下次应该考虑接入几个进来先。 :)

@a591826944 Unibox

@zeroten 可以自己试试Markdown的解析是否都符合了。 :)

@staticor 很抱歉，之前的版本不支持R屏，简直一开就不能忍的状态！ 现在，试试新版？

@taresky 印象中好像回了的，赶紧去邮箱里确认了下，果然…… 这个主要都是模板控制的，里面CSS写个规则，或者JS再控制下，就好了。

虽然未正式发布，但是一、二、三，FarBox Editor应该都基本满足的。

https://www.farbox.com/service/app/new_desktop_editor

@BinbinWang 直接用原来Dropbox对应的邮箱创建密码进行登录就可以了， 参考： help.farbox.com/read/account?lang=zh_cn


@nonozone 好像cloudflare没有生效？ 这倒也是一个办法。
以后我们会考虑增加国内的CDN（呃，国内一般CDN针对国外的upstream的其实不是很友好……），但更可能会在香港增加服务器。 现在，其实在国内多数省市，访问FarBox的速度还是不错的，因为会定时去轮询国内各省市的ISP线路质量，发生请求时，是给出FarBox能给出的最佳线路那台服务器。

要达到链路完美的状态（特别是在中国），这个太难，需要时间，也需要成本。

btw, FarBox不是静态博客，不然，我们早提供整站的备份下载了…… :(

@nonozone 如果VPS不是东亚这边的，速度不大可能会比FarBox快的，我们是有针对中美线路优化过。

Nono可以考虑贴出网址让大家试试速度。另外，如果看到文章中的食物比较可口，LOL，这是我们的图形优化算法在起作用，但是，每图0.5-1Mb的流量，这个万望先考虑到……

鉴于Nono今天刚刚支付了5年30元的基础账户，如果担心FarBox挂了，我们现在可以给你退款。但
，我们这个产品已经持续迭代了两年多，希望不要因为我们是中国人，做了这个产品，内心就先预判了；如果是这样的话，对我们而言，还是有些无奈的。

@hjue

> 只是最近FarBox文章同步太慢(也许是用户量太大了)，并且访问速度也很慢.

不知到hjue在FarBox上使用的域名是什么？绑定的方式是怎么样的，Nameserver/CNAME还是A记录？我们的访问速度（非A记录绑定）还是非常不错的，但国内的线路环境比较复杂，如果hjue遇到访问过慢，可以邮件告诉我们哪个省，什么线路，什么时间；这样对我们优化国内线路时会提供帮助。

"文章同步太慢" -> 这个不应该呀…… 如果hjue在FarBox上自己写过模板，应该会发现我们对更新的识别的反应时间，在有FarBox客户端开着的情况下是1s左右，直接通过Dropbox的，也在3s内一般。不过，上两个礼拜内，Dropbox它们自己的API出过两次事故，FarBox的同步还有个backup机制，即10分钟后，强制同步一次，难道是这个原因？


对了，我们现在用户的用量只是到了目前系统的1%-2%的负载……


我们最近在忙着新系统的设计，刚刚看到这个帖子，感觉还是需要解释一下的。 :)

@ovear `dns协议众多`是不存在的，像EDNS也只是对它的一个补充，并没有被广泛支持；如果要向Google申请，是简单的，114.114.114.114不是很清楚。如果是指dns解析包众多，这倒是。

这也不是为了实现面向clients端的智能DNS，如果需要做，也是可以的。但是，这不会是cpu密集型的，即使没有使用缓存的前提下，超找最近距离的，用类似2D索引的实现就可以解决这个问题了呀；而IP所属地的查询一般都是在结构化的基础上2分法搜索，这个性能还是很高的……

LOL, `几十到几百req`, 不会的了，Gevent的基础上不是这样子的……

EDNS的申请，要到具体的DNS服务商处申请，这很简单的；也因为如此，所以它只是DNS的一个补充协议。一般ISP提供的本地DNS都是接近用户实际地点的。（虽然，关于面向clients端的智能DNS并不是我们的本意）没有所谓的雪崩效应，规则都是自己能控制的，`某一台服务器中的负载会远远大于其他的`出现这种情况，心跳会反应这个status，就不会再跑请求过去了。

DNS的集群跟数据库的集群不一样，并不需要一个master，如果是指SOA的设置，呃，如果认为这是一个master，就自定规则，SOA记录指向其中指定一台DNS Server就可以了。

@yushiro 是的。没有严格的瓶颈，但还是有系统开销在的。这个设计跟普通的DNS轮询最大的差别是在有个动态的调度中心，可以按照自己实际的规则，判断节点上CPU负载、带宽负载、连接数等等，然后在这个规则上进行一次最优的线路选择。

真正容易出现的瓶颈确实在数据库的请求上面，这个就跟具体的项目的业务设计有直接关系了。

如果特指Web，做足缓存的颗粒度，确实可以实现一定时间内`一次生成静态页面， 再也不变化的场景`，以一种静态的方式解决，但是页面又是实时动态的。FarBox内是以浏览器语言+网站内文件的变化时间+URL作为缓存key的判断，但这比较特殊，好像没有什么可以具体分享的，并且，也就是常见的一些做法……

@jerry74 后端的问题在后端考虑，后端不处理好，单机的负载能力就会弱。

也算是DNS的轮询。但几乎所有的LB系统中，都会有个调度中心，只是现在这个结构的调度中心是DNS；调度可以简单一些，也可以复杂一些。比如某台服务器CPU占比比较高，就不请求它了，这就不是以往常见的DNS轮替了。

@HowardMei Thanks，非常认同！我们开始在做这个设计前，对DNS系统的了解并不深，越到后面，越发觉得互联网的这些初期的协议，其实真的意义深远，我们只是沾光了而已。

@rrfeng 是的。基本逻辑是这么简单的，即使不是做后端的Dev，也能解释清楚。

不过，也有另外一方面的考虑，构架足够简单，所以可以将它分离出去而不用去考虑它的存在；复杂的就归于复杂的本身。

其实，如果开发团队的人数和实力是可控的，复杂也是可控的。也不得不承认，现实情况，项目过程中太容易腐败了，可能也是部分这个原因吧，所以我们出来自己做产品。 :)

@qiongqi LOL, 不会， DNS这个基础协议，其实是21世纪非常伟大的一个发明。它本身就是分布式……

我们这样的设计，只是在它的应用层上沾了点光。

@dongbeta 主要是写起来快，代码逻辑比较干净。

其实，最主要的原因还是我们对Python是最熟悉的，FarBox使用了很多第三方库，在Python的前提下，我们对里面存在的问题能直接发现并处理掉；虽然其它比如Node也能上手，但没有这方面的自信。

也题外话一个：其实Python最大的问题就是性能的问题，我们现在一些主要模板基本上都是引入了C包，而且缓存机制以及比较完善了，性能的问题就不大了。比如我们渲染一个页面现在平均能控制在10ms以下了……

@qiongqi PV/IP都可以算…… 去掉集群本身的系统开销，实际上总的容量就是堆机器x每个单机的负载能力。

@tftk @kslr @dongbeta @missdeer

非常不好意思，没有想到会给人这样的观感。这样的结构，确实是亿级别的，很soft，却是底层的。实际的构架中，肯定需要考虑到其它方面的配合，以提高单机的负载能力，进而降低集群的成本。