取决于规模，当你的规模上去之后，分开是必然的，为了保证不受网络请求延时的影响，消息通信的时候可能还要上请求队列。
规模不大，请求不高的时候，怎么方便怎么来。只要模块接口条理清晰python重构还挺快的。

@shinebay
克扣点击量是指按合同结算应该以点击数或展示量计费的时候，克扣掉统计的点击量。
超量展示是指按合同应该以间隔半小时弹窗一次或点击一次弹窗一个的时候，广告商间隔时间更短就弹窗，甚至一次点击弹三四个窗口

1. 广告主和站长之间的差价
2. 克扣点击量和展示量
3. 超量展示

大广告联盟和广告主拿到的单价够高，赚差价足够了。
中小广告联盟就奇葩多了，扣量和超量展示都会玩，日常就是扣量，合同要结束的时候超量展示就很疯狂了尤其是弹窗与点击类的广告。

有很多，以小区为主，其实活得挺艰难，利润不高，人力成本挺高，因为人在小区的时间基本是非工作时间，夜间和周末为主。

正好我踩过这个坑了，我分享一下我的感受吧。
第一个版本的时候图开发速度懒得拆分模块，页面我全都是在服务端生成的，所有的请求都是用form提交到服务器。
这是第一个坑，提示不够人性化，用户提交的数据出错的时候，要在返回页面重新渲染不同的错误提示很繁琐。为了跳过这个坑，引入了javascript模板去渲染页面。显示给用户的页面拆分成了模板和数据渲染两块，开发速度提升了很多。这个时候就已经需要用到ajax去向接口请求数据了。不过这样的数据渲染对seo不是很有利，搜索引擎对javascript渲染出来的页面基本抓取不到。
但是上线之后，不够用啊，用户请求太多，单机不好抗，又要做负载均衡把请求带宽也分摊出去，为了易于扩展，需要填充数据的地方全部改成ajax异步请求。同时后端做读写分离，敏感操作都要加锁，开多台从机。
目前正在趟第三个坑，备案，因为网站最开始图省事，用的快速备案，每三个月备案就会被注销一次，为了能在备案注销期间用户正常访问，利用大部分cdn服务商备案查询不是很严格的时间差，主服务器迁移到国外用另外的域名，为了用cdn服务，网站的页面彻底做成静态化的，拿数据的ajax请求全部都改成跨域的。这个时候接口的设计优势就凸显出来了，早期设计得好的接口，分离的时候就很方便，打包一下就可以了，倒是最开始第一版为了省事全在model层打包的操作拆分的时候费了点时间。

restful 配合 ajax 请求开发的时候易于复用，同时易于扩展，放单机上面优势不明显，扩展到多机了优势就暴涨了。

做一下缓存，长按f5就是不断的请求页面，wordpress没开缓存的时候请求会一直去到数据库里面，很耗性能。不需要实时更新内容的页面，做伪静态化减少请求穿透webserver到数据库的请求数。

@likuku
memcached 有个日本人作的版本，支持两台memcached双向自动同步，假若一台坏掉，之后恢复运作会自动从活着的那台抓回数据复活。

这个插件有个坑都在网络连接上面:
一个是网络连接传输过程如果阻塞了,会一直挂起.

局域网可能不容易被坑到,但是如果服务器负载太高,可能会踩到第一个坑.
远程的话,要评估一下数据一致性的要求有多高了.

图片还是放国内比较好，国际带宽延迟太大，可以考虑挂到有备案的域名下面的机器，图片使用非80端口，可以绕过审查，不影响使用。如果图片实时响应要求不是非常苛刻，小IDC的机房可以便宜很多。

@gouera http权威指南可以帮助你了解浏览器和webserver都会做什么事情，但是涉及到性能的问题，你还需要看看操作系统原理 计算机组成原理一类的书才能了解更多相关的概念，比如cpu负载，内存占用，磁盘读写一类的事情对程序性能会有什么影响。

楼主肯定是基础知识积累的还不够，浏览器的通信机制，渲染流程;程序运行的处理流程;webserver的通信机制,处理请求的流程;数据库查询的处理流程这些基本的概念都没有理解.要做性能测试分析系统瓶颈不现实，如果确实看不懂，还是退一步，先回去看看更基础的概念吧，磨刀不误砍柴功的。

小应用其实做好这几个已经可以解决大部分的瓶颈问题了：
提高web server 接受并发请求的能力，用有epoll机制的web server。
增加处理的进程，在web server配置开多个进程同时处理请求。
降低数据库查询请求，用redis mongodb之类的内存数据库做缓存，保存查询结果到内存中。

如果做了这两个还存在瓶颈，考虑一下做负载均衡吧。不过那是架构师要考虑的问题。

请求是每秒执行完的总数，并发是发起请求的用户数。
性能测试中每秒执行的总数不能完全体现系统的负载能力，所以根据实际场景还需要模拟并发量，就是多个用户同时请求同一个资源，系统是否能抗住负载。
web的瓶颈一般都在程序和数据库：
多用户同时发起请求时 web server是否能在限定的延时内接住所有请求
为保存这些用户会话所占用的网络联接数有多少，web server 是否都能保持住，检索会话的时间是多少
为响应请求的数据，程序需要开辟多少内存来保存数据
为处理请求，需要向数据库请求多少次数据
ORM模块支持多少并发向数据库提交请求
数据库在并发请求下的处理延时有多少
同时向数据库请求数据会占用多少内存
程序处理请求占用多少cpu资源
程序处理请求的延时有多少

这些数据颗粒度可能太细，没有定制好工具要拿颗粒度那么细的数据估计不容易。
那就监控进程的内存占用，进程的cpu占用率，webserver 响应时间。
进程的内存占用可以大致了解数据库占用多少内存，程序占用多少内存，webserver占用多少内存
进程的cpu占用率同样
webserver的响应时间大致可以了解请求处理的总时长。

工具分两种，压力源和监控
压力源要么自己写，业务不复杂的话用apache的ab去做也不错。企业级的loadrunner之类的很专业。
监控那就看实际场景了。简单的直接用系统内置的应用来看看，需要出报告的，就找几个监控软件配置上去做图表。

早安

我是在cc图库看的，其实这几个站都没有封海贼火影这些热漫，只是定时开放而已，你等周四晚上在看。

话说这里也有腾讯的同学，不会告诉运营部的人吧。
漫画走正版的路线是最好的发展方式，u17就是注重版权走国漫原创，成功圈下不少国内的漫画作者，前段时间好象还被大价钱收购了。

oracle的服务器配置的时候会装Xwindows 但是上线之后也会关掉只使用命令行 远程vnc其实很慢而且根本没有命令行好用
到机房里面用gui界面的人不嫌吵吗 机房的空气感觉呼吸了会减寿的
使用linux的目的就是要把硬件资源压榨到极致 线上的服务器内存cpu硬盘那都是百分之百提供给外部服务用的 运维还用gui操作去管理服务器 除非有不用gui不能操作的应用系统 不然肯定是太懒或者太笨

一般机房不是封掉vpn的请求的么，在天朝境内翻墙，机房被拔线都不用通知的。

要跑超长时间的任务，又需要保留运行日志的时候，会用 nohub 和 & 配合将任务挂到后台去。然后就可以关掉终端去干别的事情了。
如果只是用&挂起，关掉终端了，命令也会被中断。
我实际用到的场景就是跑某些费时的安装脚本，或者暂时运行某些python的轻量web应用。

就是靠地推去扫大街，积累了原始数据之后开始配合UGC和店家主动上传。
这也是这些网站的门槛所在。