Warning: curl_exec() has been disabled for security reasons in /pub/host/sunboyu/sunboyu/www/wp-includes/http.php on line 1022
原创技术 一个程序猿 孙小一,孙小二,PHP,MYSQL,LINUX,APACHE,原创技术,扯淡

django进程管理器

作者 : admin 于 2009年12月16日, 16:42:49
2009
12-16

nginx+php，php有个进程管理器，为php-fpm，Django没有，网上大概看了看，找出了几段，小改一下，能用了。

  1. #!/bin/bash
  2. siteroot="/home/project/sun"
  3. sitename="http://python.sunboyu.cn"
  4. cd $siteroot
  5. if [ $# -lt 1 ];then
  6.     echo "Usages: server.sh [start|stop|restart]"
  7.     exit 0
  8. fi
  9.  
  10. if [ $1 = start ];then
  11.     isrun=`ps aux|grep "manage.py runfcgi"|grep -v "grep"|wc -l`
  12.     if [ $isrun -eq 1 ];then
  13.         echo $sitename" has running!"
  14.         exit 0
  15.     else
  16.         python manage.py runfcgi method=threaded host=127.0.0.1 port=8000 --settings=settings
  17.         echo $sitename"is running!!"
  18.     fi
  19. elif [ $1 = stop ];then
  20.     djid=`ps aux|grep "manage.py runfcgi"|grep -v "grep"|awk '{print $2}'`
  21.     kill -9 $djid
  22.     echo $sitename" is stop!"
  23. elif [ $1 = restart ];then
  24.     djid=`ps aux|grep "manage.py runfcgi"|grep -v "grep"|awk '{print $2}'`
  25.     kill -9 $djid
  26.     echo $sitename" is stop!!"
  27.     python manage.py runfcgi method=threaded host=127.0.0.1 port=8000 --settings=settings
  28.     echo $sitename" is start!!"
  29. else
  30.     echo "Usages: server.sh [start|stop|restart]"
  31. fi

django+nginx的部分配置

作者 : admin 于 2009年12月16日, 11:26:55
2009
12-16

nginx的配置，特别感谢爱词霸的吕同学，发扬了开源共享的精神，大大缩短了我的调试成本。

  1. server {
  2.     listen 80;
  3.     server_name python.sunboyu.cn;
  4.     location / {
  5.           fastcgi_pass 127.0.0.1:8000;
  6.           fastcgi_buffers      16  128k;
  7.           fastcgi_ignore_client_abort  on;
  8.           fastcgi_read_timeout 60;
  9.  
  10.           fastcgi_param PATH_INFO $fastcgi_script_name;
  11.           fastcgi_param REQUEST_METHOD $request_method;
  12.           fastcgi_param QUERY_STRING $query_string;
  13.           fastcgi_param CONTENT_TYPE $content_type;
  14.           fastcgi_param CONTENT_LENGTH $content_length;
  15.           fastcgi_param SERVER_PROTOCOL  $server_protocol;
  16.           fastcgi_param SERVER_PORT      $server_port;
  17.           fastcgi_param SERVER_NAME  $server_name;
  18.  
  19.           fastcgi_pass_header Authorization;
  20.           fastcgi_intercept_errors off;
  21.  
  22.     }
  23. }

同时附上一个额外的文档，nginx变量跟cgi协议的对应关系。
注：在配置中，并不是所有的变量必须加上，而是根据环境选择其中应该有的变量，至于具体加哪些变量，得求助高人了。

  1. #    Fast CGI param reference
  2. #    fastcgi_param    SCRIPT_FILENAME  $document_root$fastcgi_script_name;
  3. #    fastcgi_param    QUERY_STRING  $query_string;
  4. #    fastcgi_param    REQUEST_METHOD  $request_method;
  5. #    fastcgi_param    CONTENT_TYPE  $content_type;
  6. #    fastcgi_param    CONTENT_LENGTH  $content_length;
  7. #    fastcgi_param    GATEWAY_INTERFACE  CGI/1.1;
  8. #    fastcgi_param    SERVER_SOFTWARE  nginx;
  9. #    fastcgi_param    SCRIPT_NAME  $fastcgi_script_name;
  10. #    fastcgi_param    REQUEST_URI  $request_uri;
  11. #    fastcgi_param    DOCUMENT_URI  $document_uri;
  12. #    fastcgi_param    DOCUMENT_ROOT  $document_root;
  13. #    fastcgi_param    SERVER_PROTOCOL  $server_protocol;
  14. #    fastcgi_param    REMOTE_ADDR  $remote_addr;
  15. #    fastcgi_param    REMOTE_PORT  $remote_port;
  16. #    fastcgi_param    SERVER_ADDR  $server_addr;
  17. #    fastcgi_param    SERVER_PORT  $server_port;
  18. #    fastcgi_param    SERVER_NAME  $server_name;

django笔记3-DEMO篇

作者 : admin 于 2009年12月15日, 21:06:11
2009
12-15

1、创建一个project（可理解为站点）

django-admin.py startproject project1

发现新建了一个文件夹 project1

2、创建一个app（可理解为一个……）

python manage.py app1

发现多了一个文件夹 app1

3 、vi ./app1/views.py 增加代码

  1. from django.http import HttpResponse
  2. def index(self,request):
  3.     return HttpResponse('hello test')

4、vi ./urls.py 增加代码
( r’^tests/’ , ‘project1.app1.views.index’ ),

5、启动服务

python manage.py runserver domain.com:8000

然后在浏览器打 domain.com:8000/tests

如果能看到 hello test则证明配置成功。

如果不成功，看debug信息吧，debug默认是开启的。

另外我自己配置使用fastcgi方式运行python，python manage.py runfcgi host=127.0.0.1 port=8000,然后用nginx代理访问。两种方式还有所不同，具体的不同点暂时还不知道，希望知道这些差别的大大们多加提示，继续研究中。

django笔记2-配置篇

作者 : admin 于 2009年12月15日, 20:37:59
2009
12-15

1、升级linux的python为最新版本

ln -s /usr/bin/python /opt/python**{your install path}**/bin/python

2、设置django-admin.py至系统命令

ln -s /opt/python**{your install path}**/lib/python2.5/site-packages/django/bin/django-admin.py /usr/bin/django-admin.py

然后查看 django-admin.py –version

回显版本正确，则证明系统配置成功。

django笔记1-安装篇

作者 : admin 于 2009年12月14日, 19:02:47
2009
12-14

1、安装django，当然要安装python，我安装的python2.5

./configure –prefix=你的路径

2、安装mysqldb

这个可以看这篇文章 http://www.sunboyu.cn/2009/04/22/python25mysqldb122%E5%AE%89%E8%A3%85.shtml

3、安装easl_install

http://pypi.python.org/pypi/setuptools 我下的源码，按照提示安装就行

4、使用easl_install安装flup

地址 http://www.saddi.com/software/flup/dist/flup-1.0.2-py2.5.egg

5、安装django1.1

python setup install

到这里大体就算安装完了，底下配置。

完全缓存discuz论坛数据

作者 : admin 于 2009年12月06日, 22:15:07
2009
12-6

最近一直在琢磨discuz的优化，想出一些数据缓存的策略：

index.php 部分数据已经进行了缓存，但需要全部缓存，只有当 页面刷新数/更新时间 >>>> 发帖数/更新时间 ，则有必要做此缓存，此处缓存更新最为频繁，适合做内存缓存，但 更新时间不宜太久，此时间根据首页更新频度确定。

forumdisplay.php 更新频繁，优化策略同上，只是更新频度略低于首页。

viewthread.php 回复更新频繁，内容更新频度低，适合做硬盘缓存。但分页部分不可做缓存，否则……

space.php 更新不频繁，适合做硬盘缓存。

faq.php 做个静态即可。

以上分析只是根据平时维护总结，临时脑子一蹦，未作具体分析，欢迎广大站长讨论试用。版权所有，欢迎盗版。

大话discuz性能优化

作者 : admin 于 2009年11月27日, 23:46:31
2009
11-27

接此篇 http://www.sunboyu.cn/2009/11/05/discuz%E8%AE%BA%E5%9D%9B%E4%BC%98%E5%8C%96.shtml

最近一直在修改discuz，看到了很多问题，在跟系统工程部门合作的时候，也看到了很多比较优秀的解决方案，可以引入到系统中。

底下粗略讲述下已经做过的优化和可以着手进行的优化。

对于一个数据量比较大的论坛，首先是分表。posts表，threads表是必须要分的。可以按照forum表的fid进行分，也可以使用tid进行hash散列分布。分表带来的问题，显然是分页。我们进行排序的时候不可能去进行union查询，否则就失去了分表的意义。在这里，我们使用了一个支持排序的key-value型存储的小型数据库-Tokyo Tyrant（http://1978th.net/tokyotyrant/），用此数据库去同步threads表和posts表的数据，达到高速分页。（附：典型应用可以参见此文章 http://blog.s135.com/tcsql/ ）

随着数据表的膨胀，很多join联查必须进行拆分。分表可能强制我们去拆分联查，另外一些很变动不大的表，比如用户信息表的数据，使用率明显很高，变动不会太大，而使用key-value存储再合适不过。这时候，bdb和memcached是首选，我推荐使用bdb，可以持久存储于硬盘上，由用户更新资料触发更新，不必考虑过期和服务器重启的问题。这样可以减少太多的join联查，而节约数据库服务器的缓存。

随着静态文件的增长和访问量的增长，带宽浪费是一个值得考虑的问题。我们打开discuz的首页，静态文件要比php文件多好几倍，而每个文件都夹带了长长的cookie信息，因此，把这些cookie去掉显然会节约大量的带宽。discuz的文件结构还是很不错的，通常通过一个参数的配置或者全文替换就能完成这项工作。此应用，可以在新浪所有的图片上有所体现。

全文检索是mysql所不擅长的，因此附加一个好的全文检索方案很必须，我熟悉的方案：Lucene，sphinx，whoosh是我喜欢的几个全文检索的工具，对于discuz的负载，我感觉任何一个都能满足应用。在此方案上，设计一个完美的同步触发机制很重要。

还有很多问题，都在待发现中，部分问题已经解决，部分问题可以优化。discuz优化好，其实是个不错的产品。

给WordPress加了个每日谚语插件

作者 : admin 于 2009年11月23日, 23:04:53
2009
11-23

很久没写点自己的小代码了，感觉手生。

  1. < ?=$voice[rand(0,count($voice)-1)]?>  #加在title的地方，$voice这个数组随便找个地方塞一下就行

流程的改进和代码控制

作者 : admin 于 2009年11月21日, 09:37:52
2009
11-21

最近一直在修改系统，并无太多原创的代码。其中修改了ucenterhome和discuz两套代码。

ucenterhome原来的队伍进行优化后，我又改进了分享功能。此功能虽然上线，功能也无大碍，但UE方面差强人意，主要是因为年前项目紧张，此项目投入人力并不多的原因。此功能修改，无详细的需求文档，也未进行详细的需求分析和业务逻辑设计，就匆匆开始了编码过程，结果就是：代码比较混乱，结构性比较差，升级和改进的潜力小。如果要改进，面临的结果就是重写。又因为uchome本身的设计结构，无论改写和重写成本都比较高。

因此，前期的规划是比较重要的，前期多想一点，后期就能节约更多的时间和精力。

这种做法马上应用到下一个项目中：discuz论坛的优化和功能改造。

前期对需求做了详细的分析，在中间不断的需求细化和明确，因此，功能和业务逻辑清晰，代码在修改的时候，保留了原来功能，只做了功能的分支。虽然前期的需求交流花费了较多的时间，但编码过程所花费的时间就很小了。

后者的流程才是以后要继续发扬的流程。

一段清理系统垃圾的代码（只用于windows）

作者 : admin 于 2009年11月17日, 14:28:47
2009
11-17

clean

 Page 6 of 30  « First  ... « 4  5  6  7  8 » ...  Last » 



    • 有事说事

      加入LAMP技术交流群
      点击添加好友
      点击和我聊天

      给我发信

      我也有UC的