可以改进XML-RPC性能吗？ [英] Can XML-RPC performance be improved?
问题描述
我在这里有一个已建立的客户端 - 服务器应用程序，其中
现在需要挖掘大量数据（结构为
列表的列表）在两者之间，性能瓶颈已经变成了解析XML所花费的时间（它在一个上花费了100％的CPU，或者在连接的另一端获得了
）并且占据了总计通话时间的50％以上，只要它对用户互动产生的影响比对b / b
的影响更大。这是使用SGMLOP进行
解析 - 我害怕用较慢的
解析器来思考它会是什么样子。任何人（Fredrik？）都有解决这个问题的好主意吗？
-
\S - < a href =mailto：si *** @ chiark.greenend.org.uk> si *** @ chiark.greenend.org.uk - http://www.chaos.org.uk/~sion/
___ | 坦率地说，我对这种或那种企鹅没有任何感情
\ X / | --Arthur C. Clarke
她的努力是什么？ddre heddes b？ce bump bump bump
< blockquote> Sion Arrowsmith写道：
我在这里有一个已建立的客户端 - 服务器应用程序，现在需要挖掘大量数据（结构化为列表）这两者之间的性能瓶颈已经成为解析XML所花费的时间（它在一个或另一端连接上占用100％的CPU）占总呼叫时间的50％以上，在某种程度上它对用户交互的影响比对用户的影响更大。这是使用SGMLOP进行解析 - 我害怕用较慢的解析器来思考它会是什么样子。任何人（Fredrik？）都有解决这个问题的好主意吗？
CORBA。或直接TCP / IP。我知道这不是你正在寻找的答案 - 但是有一个开销解析XML，而且不能消失。
从我在SGMLOP网站上看到的内容，我怀疑你能不能快得多 -
因为速度来自于牺牲标准合规性，它已经好了很多b $ b似乎要做。
问候，
Diez
也许有一个硬件方案？你可以在
并行运行更多服务器吗？或者有一些负载分配系统？
（只是一些通用的服务器技巧，我对XML-RPC了解不多）
-Greg
2006年3月21日，Diez B. Roggisch< de *** @ nospam.web.de>写道：Sion Arrowsmith写道：
我在这里有一个已建立的客户端 - 服务器应用程序，现在需要铲除两者之间存在大量数据（结构为列表列表），并且性能瓶颈已经成为解析XML所花费的时间（它在一个或者上面占用100％的CPU） />连接的另一端，占总呼叫时间的50％以上，以至于它对用户交互的性能影响更大。这是使用SGMLOP进行解析 - 我害怕用较慢的解析器来思考它会是什么样子。任何人（Fredrik？）都有解决这个问题的好主意吗？
CORBA。或直接TCP / IP。我知道这不是你正在寻找的答案 - 但是有一个开销解析XML，而且不能消失。从我读到的内容在SGMLOP的网站上，我怀疑你能不能快得多 -
因为速度会牺牲标准的合规性，而这似乎已经好了。
<问候，
Diez
-
http://mail.python.org/mailman/listinfo/python-list
-
Gregory Pi？ero
首席创新官
混合技术
（ www.blendedtechnologies.com ）
Sion Arrowsmith：我''我们在这里有一个成熟的客户端 - 服务器应用程序，现在需要挖掘巨大的东西两者之间的数据量（以
列表的结构列表），性能瓶颈已经成为解析XML所花费的时间
http://xmlsucks.org/
任何人都有解决这个问题的好主意吗？
cPickle。
http://docs.python.org/lib/module-cPickle.html
-
$ b $bRenéPijlman
Wat wil jij leren？ http://www.leren.nl
I''ve got an established client-server application here where there
is now a need to shovel huge amounts of data (structured as lists of
lists) between the two, and the performance bottleneck has become
the amount of time spent parsing XML (it''s taking 100% CPU on one or
other end of the connection and accounting for well over 50% of the
total call time, to the extent that it''s having a greater impact on
performance than user interaction). And this is using SGMLOP for
parsing -- I dread to think what it would be like with a slower
parser. Anyone (Fredrik?) got any good ideas for tackling this
problem?
--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
___ | "Frankly I have no feelings towards penguins one way or the other"
\X/ | -- Arthur C. Clarke
her nu becomet se bera eadward ofdun hl?ddre heafdes b?ce bump bump bump
Sion Arrowsmith wrote:
I''ve got an established client-server application here where there
is now a need to shovel huge amounts of data (structured as lists of
lists) between the two, and the performance bottleneck has become
the amount of time spent parsing XML (it''s taking 100% CPU on one or
other end of the connection and accounting for well over 50% of the
total call time, to the extent that it''s having a greater impact on
performance than user interaction). And this is using SGMLOP for
parsing -- I dread to think what it would be like with a slower
parser. Anyone (Fredrik?) got any good ideas for tackling this
problem?
CORBA. Or TCP/IP directly. I know that isn''t really the answer you''re
looking for - but there is an overhead parsing XML, and that can''t go away.
From what I read at SGMLOP''s site I doub''t that you can get much faster -
because speed comes with sacrificing standard compliancy, which it already
seems to do.
Regards,
Diez
Perhaps there''s a hardware solution? Could you run more servers in
parallel? Or have some sort of load distribution system?
(Just some generic server tips, I don''t know much about XML-RPC)
-Greg
On 3/21/06, Diez B. Roggisch <de***@nospam.web.de> wrote:Sion Arrowsmith wrote:I''ve got an established client-server application here where there
is now a need to shovel huge amounts of data (structured as lists of
lists) between the two, and the performance bottleneck has become
the amount of time spent parsing XML (it''s taking 100% CPU on one or
other end of the connection and accounting for well over 50% of the
total call time, to the extent that it''s having a greater impact on
performance than user interaction). And this is using SGMLOP for
parsing -- I dread to think what it would be like with a slower
parser. Anyone (Fredrik?) got any good ideas for tackling this
problem?
CORBA. Or TCP/IP directly. I know that isn''t really the answer you''re
looking for - but there is an overhead parsing XML, and that can''t go away.From what I read at SGMLOP''s site I doub''t that you can get much faster -
because speed comes with sacrificing standard compliancy, which it already
seems to do.
Regards,
Diez
--
http://mail.python.org/mailman/listinfo/python-list
--
Gregory Pi?ero
Chief Innovation Officer
Blended Technologies
(www.blendedtechnologies.com)
Sion Arrowsmith:I''ve got an established client-server application here where there
is now a need to shovel huge amounts of data (structured as lists of
lists) between the two, and the performance bottleneck has become
the amount of time spent parsing XML
http://xmlsucks.org/
Anyone got any good ideas for tackling this problem?
cPickle.
http://docs.python.org/lib/module-cPickle.html
--
René Pijlman
Wat wil jij leren? http://www.leren.nl
这篇关于可以改进XML-RPC性能吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
