侃一下关于程序的“柔性”

yulihua49 · 发表于 2011-9-9 17:43

原帖由〇〇于 2011-9-9 17:41 发表
只有输出结果，没有时间对比。。。

在P13，127楼。

服务端程序在128楼，看看是否有对你不公平的做法。

[ 本帖最后由 yulihua49 于 2011-9-9 17:57 编辑 ]

yulihua49 · 发表于 2011-9-9 17:46

这是客户端程序

#include <unistd.h>
#include <sccli.h>
#include <pack.h>
#include <json_pack.h>
int test_page(T_Connect *conn,T_NetHead *head)
{
int ret;
JSON_OBJECT json,cmd;
char *p;
T_CLI_Var *clip=(T_CLI_Var *)conn->Var;
INT64 now;
cmd=json_object_new_object();
add_string_to_json(cmd,"tablename","TI_CITY");
add_string_to_json(cmd,"where","WHERE DAIL_AREA_CODE=:DAIL_AREA_CODE AND CITY_STOP_DATE >= :CITY_STOP_DATE");
add_string_to_json(cmd,"page_size","10");
add_string_to_json(cmd,"page_idx","1");
json=json_object_new_object();
add_string_to_json(json,"DAIL_AREA_CODE","0350");
add_string_to_json(json,"CITY_STOP_DATE","20110909");
json_object_object_add(cmd,"values",json);
p=(char *)json_object_to_json_string(cmd);
if(isatty(0)) printf("cmd=%s\n",p);
head->PROTO_NUM=get_srv_no(clip,"page_proc");//如果是我的程序，就"page_select"
if(head->PROTO_NUM==1) {
json_object_put(cmd);
ShowLog(1,"%s:no such svc 'page_select'",__FUNCTION__);
return -1;
}
head->data=p;
head->PKG_LEN=strlen(head->data);
head->ERRNO1=head->ERRNO2=head->PKG_REC_NUM=head->D_NODE=0;
head->O_NODE=LocalAddr(conn->Socket,NULL);
now=now_usec();
ret=SendPack(conn,head);
json_object_put(cmd);
ret=RecvPack(conn,head);
if(ret) {
ShowLog(1,"%s:net err=%d,%s",__FUNCTION__,errno,strerror(errno));
return -1;
}
if(head->ERRNO1 || head->ERRNO2) {
ShowLog(1,"%s:recv ERRNO=%d,%d",__FUNCTION__,head->ERRNO1,head->ERRNO2);
return -1;
}
ShowLog(2,"%s:svc succeed TIMEVAL=%d",__FUNCTION__,(int)(now_usec() - now));
if(isatty(0)) printf("data=%s\n",head->data);
return 0;
}

复制代码

[ 本帖最后由 yulihua49 于 2011-9-9 17:48 编辑 ]

newkid · 发表于 2011-9-9 21:15

原帖由 yulihua49 于 2011-9-9 17:16 发表

这个功能根本用不着PL/SQL。自己解决了。
你的那个程序，我已经测试了。单例的。没做压力。节后再说。
跟我的程序比了一下。在客户端，从发送命令到接收结果的时间。单位是微秒。

你的存储过程的执行时间：
TIMEVAL=58606
TIMEVAL=23585
TIMEVAL=20988
TIMEVAL=11657
TIMEVAL=24134
TIMEVAL=10919

我的：
TIMEVAL=30372
TIMEVAL=16913
TIMEVAL=9121
TIMEVAL=9655
TIMEVAL=8766
TIMEVAL=16947

多大数据量要传58秒？
我那种做法网络流量比你大，因为加上了那些包装的列名，引号等等。这就是我前面说的为什么PLSQL要处理“裸”数据，至于格式化的包装我完全同意交给接收端去做（然后再按需要转发），因为这部分完全不含业务逻辑且工作量不大，适合在数据库之外完成。你津津乐道的“柔性”正是我尽力要避免的，PLSQL是“有所为，有所不为”。
另外你比较性能的时候应该排除硬解析、物理读的干扰，不要出现程序A完成了物理读而程序B只需逻辑读的情况，同样的程序运行两遍然后各取第二遍来比较。

〇〇 · 发表于 2011-9-9 21:41

别在客户端，在服务器端测试一下

yulihua49 · 发表于 2011-9-10 10:07

原帖由 newkid 于 2011-9-9 21:15 发表

多大数据量要传58秒？
我那种做法网络流量比你大，因为加上了那些包装的列名，引号等等。这就是我前面说的为什么PLSQL要处理“裸”数据，至于格式化的包装我完全同意交给接收端去做（然后再按需要转发），因为这部分完全不含业务逻辑且工作量不大，适合在数据库之外完成。你津津乐道的“柔性”正是我尽力要避免的，PLSQL是“有所为，有所不为”。
另外你比较性能的时候应该排除硬解析、物理读的干扰，不要出现程序A完成了物理读而程序B只需逻辑读的情况，同样的程序运行两遍然后各取第二遍来比较。

58毫秒，告诉你了，单位是微秒。
“你津津乐道的“柔性”正是我尽力要避免的”，不是我津津乐道，这是客户需求，干了几十年IT了，太多的项目绝大多数精力用于“柔来柔去”，用户不断的变更需求，而且限期完成。所以柔性编程是客户需要而不是我。如果你说需要极力避免，那就是满足不了用户需求，我们的辩论就结束了。我认为这个帖子不是讨论是否需要柔性，而是采用什么手段，比较方便，比较高效的实现较高的柔度。柔性编程，绝对不是我的发明，几十年来无数软件人员在为之努力。要达到“软件更软”的目标。各种实用的应用都具有一定的柔性。但是是否方便是否高效是否够柔，是否能够传承。这些是需要研究提高的。
我抛出的虽然是个砖，也是数十年经历的总结，与感兴趣的人交流一下。

传输时间占的比重不大，应该在1ms以下。主要是处理时间。
二者都是第一次时间比较长，那应该是硬解析的时间。机器都是比较空闲的。

服务器时间可以测一下。
单例的时间不重要，主要看压力测试，大量用户并发的平均响应时间和交易吞吐量。单就这个例子的应用来说，都不重要，节后可以测一下做个技术上的探讨。
在压力测试中，网络传输时间会被并行掉（只要流量不过载）。
单例的环境：
客户端－交易服务器------数据库服务器

压力测试将在如下环境进行：
客户端-----交易管理器------交易服务器------数据库服务器，各自是独立节点，这接近实际使用情况。
这样响应时间会增加（毕竟要通过那么多次网络），但交易吞吐量会增加，任务各自分担了。
成千上万的客户同时，不能直接连交易服务器，必须通过交易管理器做一个连接池和排队处理。

[ 本帖最后由 yulihua49 于 2011-9-10 11:12 编辑 ]

newkid · 发表于 2011-9-10 11:10

你的题目是“侃一下关于程序的“柔性””，应用程序什么时候应该柔，是不是越柔越好，都未定论，凭什么你一句话就得胜回朝了？
你的客户到底是什么身份，难道他们是程序员？只要你设计的应用系统能满足需求，能及时体现需求变更，他们还管你怎么写程序？
知道为什么“太多的项目绝大多数精力用于“柔来柔去””？因为你没有用合适的工具做合适的事情。C语言写SQL很麻烦，因此你发明了包装器，在这层面是“柔性”的，但你的业务程序还是柔不得，它还是老老实实用列名（结构成员名）访问数据，写业务逻辑。PLSQL抛弃了中间的访问层，它和SQL已经完美结合，把你原来写在客户的业务程序在数据库就实现了，这是更好的方法。

yulihua49 · 发表于 2011-9-10 14:01

原帖由 newkid 于 2011-9-10 11:10 发表
你的客户到底是什么身份，难道他们是程序员？只要你设计的应用系统能满足需求，能及时体现需求变更，他们还管你怎么写程序？
知道为什么“太多的项目绝大多数精力用于“柔来柔去””？因为你没有用合适的工具做合适的事情。C语言写SQL很麻烦，因此你发明了包装器，在这层面是“柔性”的，但你的业务程序还是柔不得，它还是老老实实用列名（结构成员名）访问数据，写业务逻辑。PLSQL抛弃了中间的访问层，它和SQL已经完美结合，把你原来写在客户的业务程序在数据库就实现了，这是更好的方法。

这是一个漫长的过程。当时的确是没有什么好办法。数据表里往往预留各种类型的列若干。C语言写SQL很麻烦，但有时必须用C。JAVA也是有了各种框架才简单起来的。不管什么语言，框架都会带来方便，也会带来一定的柔性。JAVA的框架，,net的框架。。。。估计你反对也反不过来。在有了框架后，SQL简单起来，甚至有了noSQL的趋势。人们不写语句也可以方便的使用SQL了，如果效率不低，为什么还要用PL/SQL呢？我们这个PK，我也不说我的效率如何，至少不必PL/SQL低。就代码量而言，后边的接口代码加上PL/SQL的代码，量不低，含金量还很高，功能还有欠缺，何必要用PL/SQL呢？
在DAU里，可以不点列名，也可以点。业务处理逻辑，在结构成员这个层次上使用列名，但在存取数据时，就可以少写或不写列名。涉及列名越少，程序的柔性就越高。减少列名的使用是提高程序柔性的重要途径。（不是全部）

应用程序没有绝对的柔性，也没有绝对的不柔性。一切依据需要。
程序达到何种应变能力，可以研究探讨，我试图拿出一个解决方案。好不好可以讨论，我欢迎有人能指出，哪些方面柔性不足，有何改进办法。

目前能达到最高的应变，需要人工智能，这不是单纯的PL/SQL能解决的。某种程序语言可能更合适。语言和数据库、知识库的联系，还有很长的路要走。方便的接口方法需要不断研究。

[ 本帖最后由 yulihua49 于 2011-9-10 15:01 编辑 ]

sohay · 发表于 2011-9-10 14:05

我很赞同newkid的观点，用合适的工具做合适的事情。最简单就是最好的，能用pl/sql实现的就不要搞什么包装器。

yulihua49 · 发表于 2011-9-10 14:08

原帖由 sohay 于 2011-9-10 14:05 发表
我很赞同newkid的观点，用合适的工具做合适的事情。最简单就是最好的，能用pl/sql实现的就不要搞什么包装器。

、
现在问题是，DAU比PL/SQL简单得多。

一批学生，半小时培训，就能写出不错的程序。
如果培训PL/SQL到一定水平需要多少时间？
包装器也好，框架也好，不就是为了简单吗？用合适的工具做合适的事情。最简单就是最好的，这就是框架的宗旨。
JAVA的hibernate，无数初入门者从这里开始了他们的SQL之旅。
DAU步hibernate的后尘，为C程序员带来方便。
用合适的工具做合适的事情，做柔性的程序，DAU无疑是更好的。

[ 本帖最后由 yulihua49 于 2011-9-10 14:45 编辑 ]

newkid · 发表于 2011-9-11 03:29

“不管什么语言，框架都会带来方便，也会带来一定的柔性。JAVA的框架，,net的框架。。。。估计你反对也反不过来。"
数据库和非数据库两个阵营之争由来已久，有人把它比喻成宗教战争，确实是很难有结果的。
不过我怀疑那些框架的生命周期，因为不久之后就有更花哨的版本出现，你又得去跟风。

“人们不写语句也可以方便的使用SQL了，如果效率不低，为什么还要用PL/SQL呢？"
我还想反过来问你呢，PLSQL能做到的事情，如果效率不低，为什么要把程序写到数据库外？

“就代码量而言，后边的接口代码加上PL/SQL的代码，量不低，含金量还很高，功能还有欠缺，何必要用PL/SQL呢？”
代码量没有多少，你忘了DAU那层全省掉了？我其实不喜欢这么做，我建议用PLSQL返回结果集，由你的C程序去包装成JSON. 你用C写个通用的读游标程序也不难。

“业务处理逻辑，在结构成员这个层次上使用列名，但在存取数据时，就可以少写或不写列名。”
你不是不写或少写，你是把这部分工作量转移到模版去了。如果自动模版，相当于SELECT *, 或SELECT *-X (这个-X表示去除某些列，是我杜撰的)；如果手动模版，则工作量比SQL还大，而且代码还不好读，你得很小心才知道怎么在模版外面加上WHERE。我敢打赌你的程序员大部分都用自动模版。这就引出一个问题，没有人用JOIN, 都是自己嵌套循环实现的。

“一批学生，半小时培训，就能写出不错的程序。
如果培训PL/SQL到一定水平需要多少时间？”
如果没学过任何编程的人呢？学习C和学习PLSQL哪个更快？

[讨论] 侃一下关于程序的“柔性”

回复 #131 yulihua49 的帖子

浏览过的版块