Menu
Woocommerce Menu

固定在浏览器底部,WSGI协议以及对服务器的影响

0 Comment

将 footer 固定在浏览器底部,footer浏览器

在内容超出屏幕时,footer只有在滚动条拉直底部时才出现。当撑不满屏幕时,footer直接固定在底部。

主体区域 min-height:100%, 恰好把 footer 挤出一屏外,footer 本身使用负的
margin-top 往上提与 height 相同的距离,这时只需在主体区内部元素上添加
padding-bottom 把 footer 盖住的区域排开即可。

html:

图片 1

<!DOCTYPE HTML>
<html lang="en">
    <head>
    <script id="jquery_182" type="text/javascript" class="library" src="/js/sandbox/jquery/jquery-1.8.2.min.js"></script>
    </head>
    <body>
        <div class="wrapper">
            <div class="header">header</div>
            <div class="main">
                  <button id="add">add</button>
                    <p>test test test</p>
            </div>
        </div>
      <div class="footer">footer</div>
    </body>
</html>

View Code

 

css:

图片 2

html{
    height:100%;
}
body{
    height: 100%;
    margin: 0;
    background: white;
}
.wrapper{
    min-height:100%;
    height:auto;
}
.main{
    padding-bottom: 60px;
}
.footer,.header{
    color: white;
    text-align:center;
    height: 60px;
    line-height:60px;
    background:#376AAE;
}
.footer{
    margin-top:-60px;
}

p{
    margin:0;
    padding:10px;
    background:white;
}

View Code

 

js:

图片 3

$(function(){
    $("#add").click(function(){
      $(".main").append('<p>test test test</p>');
    });
})

View Code

 

其实使用 css3 calc
的话,可以很简单地将vh和绝对单位混算,DOM结构就无需如此别扭了,直接
min-height: calc(100vh – 60px); 就好了

图片 4

body{
    margin: 0;
    background: white;
}
.main{
    min-height:calc(100vh - 120px);
}
.footer,.header{
    color: white;
    text-align:center;
    height: 60px;
    line-height:60px;
    background:#376AAE;
}

p{
    margin:0;
    padding:10px;
    background:white;
}

View Code

 

footer 固定在浏览器底部,footer浏览器
在内容超出屏幕时,footer只有在滚动条拉直底部时才出现。当撑不满屏幕时,footer直接固定在底部…

WSGI协议以及对服务器的影响,wsgi协议服务器

             
 下面的内容纯属个人学习心得,如果对于我的观点有疑问,敬请留言,我将虚心向大牛学习。

 

               WSGI的全称是WEB SERVICE GATEWAY INTERFACE.WSGI
不是服务器,不是API,也不是模块,而是一种协议规范,是描述web service
和web application通信的协议规范。

       要实现WSGI协议,必须实现web service 和 web application
,当前运行在WSGI上的协议框架有FLASK,DJANGO,TORANDO.

                WSGI协议必须包含两部分,分别为web service 和web
application这两部分,客户端与服务器的实现原理图如下所示:

        图片 5

                 WSGI
application接收由server转发的request,处理请求,并将处理结果返回给server。application中可以包括多个栈式的中间件(middlewares),这些中间件需要同时实现server与application,

         
因此可以在WSGI服务器与WSGI应用之间起调节作用:对服务器来说,中间件扮演应用程序,对应用程序来说,中间件扮演服务器。

                  只要web service 和web application
同时实现了WSGI的协议,那么不同的web service 就可以和同一个web
application 组合成为一个服务器,同样的不同的web application
可以和同一个web

          service组合成为一个服务器。

 

          

下面的内容纯属个人学习心得,如果对于我的观点有疑问,敬请留言,我将虚心向大牛学习。…

改善OpenStack上DHCP的性能

你有没有碰到过OpenStack中,VM失去IP地址的问题?如果有的话,你知道那可能是什么问题
——特别是如果你拥有大量的节点和VM。你的客户会因为没有明显原因却断了与VM的连接而感到
挫败。甚至云的支持团队会为log文件里没有提示却出现问题感到挫败。

听起来很熟悉?

在这篇blog里,我将会分享我的一些关于Openstack网络的经验,特别是承担为VM分配IP地址的责任的DHCP子组件。

为什么我们会把问题归咎于DHCP组件?因为这些特定的问通常都是由这个小但明显微不足道的OpenStack组件导致的。

在Ubuntu 12.10 上安装部署Openstack

Ubuntu 12.04 OpenStack Swift单节点部署手册

OpenStack云计算快速入门教程

企业部署OpenStack:该做与不该做的事

CentOS 6.5 x64bit 快速安装OpenStack

DHCP agent和DNSmasq

在OpenStack中,neutron-dhcp-agent为实例提供ip地址。理论上,neutron-dhcp-agent可以支持多种

后端,但现在它只支持dnsmasq。当启动一个实例时,分配和配置(ip)的程序包含一个在dnsmasq
config中储存ip地址的进程,接着启动或重载dnsmasq。通常,OpenStack在每个网络中只有一个neutron-dhcp-agent负责spawn一个dnsmasq,所以一个庞大的网络(包含所有子网)中只会有一个dnsmasq提供服务。理论上,并且根据实用的实验室测试,dnsmasq应该能每秒处理1000个DHCP请求,但这里有些事实要说明下:

1.租赁时间。默认情况下是120s,你大概会知道,在租赁时间内,dhcp客户端会尝试中途延长租赁时间。这意味着每个VM会一分钟更新一次他们的ip地址。

2.去启动一个包含65535个静态租赁的DNSmasq实例几乎需要4分钟(3分43秒)。一般这会发生在neutron为新的VM分配新的ip地址,接着强行reload
DNSmasq时。在此时,将没有DHCP服务会为相应的私有Neutron网络提供服务。

3.如果你没有在dnsmasq的配置中使用no-ping选项——这是应归于对安全担忧的OpenStack的默认设置——你会因非常慢的服务速度感到痛苦,因为在dnsmasq中,一个分开的pinger进程会被用于检查所提供的ip地址是否已经在使用中。包含no-ping选项,dnsmasq将能在10分钟内为160个请求提供服务并且不会失去它们,尽管这依赖于核心(core)速度和CPU速度。

4.Ubuntu和CentOS有mac地址表(neighbour
table)被限制到/128/512/1024(net.ipv4.neigh.default.gc_thresh1/2/3)个记录。因为如此,不经常使用的
IP 记录将会异常快速老化(IP records that are not frequently used will
age abnormally fast)这会影响网络性能并拖慢系统把流量发送至dhcp
agent所在节点上的正确的mac地址的能力。

5.企图通过显著的增加ip的租赁时间去解决这些性能问题,这会导致neutron释放ip地址这方面的大问题(如果你的云负载均衡地改变)。默认情况下,neutron会为一个VM分配一个ip地址达24小时(neutron
will allocate an IP address to a VM for 24
hours),独立于实际的租赁时间。当然,默认情况下,neutron不会为已经终止了的实例提供ip地址直至24小时。

你可以采取的措施
幸运的是,你可以做点事解决问题,如果你使用openstack并拥有一个地址空间大于255个地址(/24)的私有网络,

接着你应该考虑调整dnsmasq和network节点自身的默认参数。

1.增加ip的租赁时间以减少每秒来自VM的尝试更新ip地址的请求数量。根据一般的场景计算新的租赁时间,
记住虚拟机生命周期的平均时间。由于一个Bug,设置太大的租赁时间值会强迫OpenStack在数据库中保留这个ip地址为“used”的状态。即使VM已经被删除,因为neutron的租赁时间在数据库中,neutron将不会释放这个ip地址。

2.增加MAC地址表的尺寸使其能服务至少一千个主机。要做到这样,典型地,你可以设置dhcp-agent所在主机
的sysctl变量(通常在/etc/sysctl.conf)。视情况,你可以在所有与网络有关的节点执行以下操作,这些变量

如此设置:

net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 4096
net.ipv4.neigh.default.gc_thresh3 = 8192

3.为DNSmasq的默认参数加上no-ping选项。这个改变能够使其每秒处理多10-20个请求,因为在被实际分配之前,dnsmasq无需再尝试ping那些ip。如果你使用OpenStack作为你的基础设施的一部分,记住,你必须谨慎地考虑这个选项。比如,如果你正使用提供者网络(provider
networks)并且你的VM与其他物理服务器、设备、等等是单一L2域的组成部分,IP冲突是可能发生的的,可以造成严重破坏。

Neutron社区必须思考的改变

不幸地,在neutron中没有任何办法能为用户解决24小时ip分配的问题(the
problem of 24 hour IP
allocation),这个问题应该从neutron自身的改变去解决。一个简单的解决方法是在neutron或dhcp-agent中增加一个可配置的参数以修改租赁时间,并把它用作neutron数据库中的分配周期。这个方法表面看上去很完美但是仔细检查一下,你会意识到这会大大增加neutron-api/neutron-db的负载。所以这不是一个正确或不正确的方法去解决问题。

取而代之的是,neutron应该在实例被终止时简单地从数据库中移除ip地址。这会解决所有问题并在云上实现

动态负载和ip地址的完美重用。【实际上,这恰好是Icehouse版本的情况,尽管目前问题有所减轻】

结论

正如我说的,我的所述只是覆盖了一个很小的OpenStack网络的子组件——DHCP服务。正如你所看到的,
如果配置不正确,特别是当你使用了DNSmasq的默认选项将会导致许多痛苦。上面我所推荐的希望能帮助你
了解如何选择具体的DNSmasq选项和如何根据情况调整他们。

Linux系统下构建DHCP服务器

CentOS下配置主从DNS服务器以及DHCP下的DDNS

SUSE Linux 11 pxe+DHCP+tftp+ftp 无人值守安装

Linux下架设DHCP服务器过程及3种测试

Linux上一步一步实现DHCP服务器

本文永久更新链接地址:

你有没有碰到过OpenStack中,VM失去IP地址的问题?如果有的话,你知道那可能是什么问题
特别是如果你拥有大量的节…

标签:,

发表评论

电子邮件地址不会被公开。 必填项已用*标注

相关文章

网站地图xml地图