zope performance issues
Morning Guys/Gals, I write in regards some wierd performance issues that we have been facing at work. I will illustrate the same in brief. We are a large consultancy based out of India evaluating App Servers for deployment by customers world wide. I am neither a code guru nor a zope admin guru but am getting along well with the same and work for the Performance Engineering Group here. Towards benchmarking any app server we port our "TPC-W" certified web application to the enviornment. TPC-W is based in many flavours jsp/asp and now zope_dtml. Some very simple basic transactions short-circuited(Without Sql queries) on Weblogic/Websphere give me 5-10 times the throughput that i got with simple zope pages. To illustrate the figures...i got a 30TPS(Transactions per sec) compared to a 150+TPS with weblogic/websphere. All zope code i have writte via the ZMI is very simple DTML code. Nothing fancy. Lemme tell you all that i have 5+ years on gnu/linux and worked with Red Hat. Just to let you know i am serious about the figured above and just dont want to show something in poor light. Do help me push zope to the limits and i will share the results of the benchmarks as obtained. Somethings i need to start with.....
Caching of Objects in Zope Dynamic Thread Management Features in Zope Shared pool connection management for SQL queries Tuning Documents Monitoring of current instance Capability to pump test load across numerous Zope Servers(If none of the above work)
Appreciate any feedback on the same fellas. Trevor ===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/
Do help me push zope to the limits and i will share the results of the benchmarks as obtained. Something i need to start with.....
Caching of Objects in Zope Check out RAMCacheManager. It is a basic cache Product that comes with Zope. You can also use a seperate caching proxy like squid.
Dynamic Thread Management Features in Zope ??
Shared pool connection management for SQL queries This will be handled by the particular database adapter that you are using, so you will have to evaluate them ...
Tuning Documents No ideas here.
Monitoring of current instance /Control_Panel/Database/Activity will have information on the current activity. If you use RAMCacheManager, it will also have information about cache hits on cached objects.
Capability to pump test load across numerous Zope Multiple ZEO clients connecting to a single backend storage server. Use LVS (http://www.linuxvirtualserver.org/) to balance requests between them if you are on Linux.
HTH, John Ziniti
Hello John, --- John Ziniti <jziniti@speakeasy.net> wrote:
Caching of Objects in Zope Check out RAMCacheManager. It is a basic cache Product that comes with Zope. You can also use a seperate caching proxy like squid. [snip]
At this point of time i am not allowed to perform any tests using tools/plugins other than those that fit into the application server under test. I need to check out RAMCacheManager. Any idea on how effective the same is. As in approx what will be the percentage increase in Transactions Per Second with RAMCacheManager on???.
Dynamic Thread Management Features in Zope
[snip] I meant the capability to manage the pool of threads with visual representation of the thread usage in real time. Weblogic/Websphere provide for the same. Some very arcane thread pool management is available through the zope.cong file but i am very sure a lot more fine tuning is possible. Any comments on this one john???.
Shared pool connection management for SQL queries This will be handled by the particular database adapter that you are using, so you will have to evaluate them ... [snip]
Thanks.
Monitoring of current instance /Control_Panel/Database/Activity will have information on the current activity. If you use RAMCacheManager, it will also have information about cache hits on cached objects. [snip]
Fantastics. Lemme configure RAMCacheManager and revert back with increase/decrease in performance.
Capability to pump test load across numerous Zope Multiple ZEO clients connecting to a single backend storage server. Use LVS
[snip] ZEO yes...but i want the push the vanilla setup to the max before i get onto ZEO. Infact i am yet to educate myself on that front. am just reading up.
(http://www.linuxvirtualserver.org/) to balance requests between them if you are on Linux. [snip]
My whole test env is Gnu/Linux. But again no other plugins other than those that fit directly into Zope. Thanks John. You were really helpful. I will revert back with the results. Trevor
HTH, John Ziniti
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/
On Wed, 2004-05-19 at 00:08, Trevor Warren wrote:
At this point of time i am not allowed to perform any tests using tools/plugins other than those that fit into the application server under test.
That's what makes corporate <insert country here> great! <wink>
Dynamic Thread Management Features in Zope [snip]
I meant the capability to manage the pool of threads with visual representation of the thread usage in real time. Weblogic/Websphere provide for the same.
On UNIX, we just typically use "top".
Some very arcane thread pool management is available through the zope.cong file but i am very sure a lot more fine tuning is possible.
I think you might be best off if you didn't think too hard about thread pool management. Fine-grained thread management is apparently critical to Java app servers (at least from discussions I've overheard from Java people), but Zope just takes care of it for you and you don't need to think all that much about it. The presentation link I sent over has some tips for "tuning" which involves some thread-related settings... http://www.plope.com/misc/szweb/img19.html through http://www.plope.com/misc/szweb/img23.html are probably most relevant. - C
Hey Chris, Thanks for writing in. --- Chris McDonough <chrism@plope.com> wrote:
On UNIX, we just typically use "top". [snip]
ho..ho..ho...Very funy..:D. `top -d 5` is less intensive that a top that refreshes every sec.
http://www.plope.com/misc/szweb/img19.html through http://www.plope.com/misc/szweb/img23.html are probably most relevant. [snip]
Thanks captain, am just going through the same right now along with the RamCacheManager as suggested. Trevor
- C
===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/
Trevor Warren wrote at 2004-5-18 21:08 -0700:
... Any idea on how effective the same is. As in approx what will be the percentage increase in Transactions Per Second with RAMCacheManager on???.
Of course, this depends on how costly your rendering is... -- Dieter
--- Dieter Maurer <dieter@handshake.de> wrote:
Per Second with RAMCacheManager on???.
Of course, this depends on how costly your rendering is... [snip]
The content is just 3 DTML pages with static html embedded in it. Nothing to fancy and no eye candy at all. RamCacheManager objects i used to cache all images/dtml scripts. The statistics show that ONLY DTML scripts got cached and no images...why????. Ofcourse i would use a rever proxy/apache to do that caching but would appreciate some clarity on the same. There was abso no increase in performance with RamCacheManager enabled for dtml scripts. I am leaving for office in sometime and will re-setup the zope config towards running last nite's test for 50 users again with the following settings. Lemme know if you desire some changes???.
Users on the system : 50 Iterations per user at any given time(Defines the no of times the site) is looped thro) : 1 10 Threade in Zope Main DB Cache as 20000 No temp DB Cache Pool connections 15
Any comments????. Trevor
-- Dieter
===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer
Trevor Warren wrote:
The content is just 3 DTML pages with static html
embedded in it. Nothing to fancy and no eye candy at all.
Uhhh... please tell me this isn't your benchmark :) -Matt -- Matt Hamilton matth@netsight.co.uk Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Design | Zope/Plone Development & Consulting | Co-location | Hosting
--- Matt Hamilton <matth@netsight.co.uk> wrote:
Trevor Warren wrote: Uhhh... please tell me this isn't your benchmark :) [snip]
The whole set of 4 iterations is 12 pages and with tons of sql's. But towards getting to that....i wanna get the first iteration short circuited done first. Makes sense???. Trevor
-Matt
===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer
Trevor Warren wrote at 2004-5-19 19:49 -0700:
... RamCacheManager objects i used to cache all images/dtml scripts. The statistics show that ONLY DTML scripts got cached and no images...why????.
You should not cache static objects (such as images) via a RAMCacheManager -- the only effect: you consume more memory (provided that the ZODB cache has adequate size). Use the RAMCacheManager only for dynamic content. In a real production situation, you would use an HTML cache (e.g. Squid, Apacher + mod_cache) to cache static objects. The "HTMLCacheManager" may help you to set the correct cache headers.
Ofcourse i would use a rever proxy/apache to do that caching but would appreciate some clarity on the same.
Indeed...
There was abso no increase in performance with RamCacheManager enabled for dtml scripts.
Maybe, because your DTML objects have not been dynamic... In this case, the HTML cache approach would be better...
... I am leaving for office in sometime and will re-setup the zope config towards running last nite's test for 50 users again with the following settings. Lemme know if you desire some changes???.
Users on the system : 50 Iterations per user at any given time(Defines the no of times the site) is looped thro) : 1 10 Threade in Zope Main DB Cache as 20000 No temp DB Cache Pool connections 15
Your application is CPU bound (at least, I expect this). This means that a higher number of threads can only induce higher overhead (due to more thread switches). On the other hand this should not lead to a dramatic slow down... You may increase the number of instructions before Python is ready to switch threads (again to reduce the number of thread switches). This, too, will not drastically improve throughput, though. Two more notes: * You should have a feeling what you may get: On my machine (Athon 1.4 GHZ, 600 MB RAM), I get about 85 req/sec for a simple DTML page and about 160 req/sec for an Image. I think that's almost as good as you can come with Zope. * The speed highly depends on how well Python was generated. I once observed that the Python generated by myself was about 50 % faster than that distributed with my OS installation (SuSE 7.3). How well your Python runs can be checked with the PyStone benchmark. As a comparison: my Python has 26.187 pystones/second (on the machine mentioned above). -- Dieter
Hello Dieter, --- Dieter Maurer <dieter@handshake.de> wrote:
You may increase the number of instructions before Python is ready to switch threads (again to reduce the number of thread switches). This, too, will not drastically improve throughput, though. [snip]
Where is this setting???. Is this the one in zope.conf mentioned as python_check_interval as "1000".
How well your Python runs can be checked with the PyStone benchmark.
As a comparison: my Python has 26.187 pystones/second (on the machine mentioned above).
[snip] this is mine...:D [zope@blade1 test]$ ./pystone.py Pystone(1.1) time for 50000 passes = 2.22 This machine benchmarks at 22522.5 pystones/second [zope@blade1 test]$ ./pystone.py Pystone(1.1) time for 50000 passes = 2.23 This machine benchmarks at 22421.5 pystones/second [zope@blade1 test]$ ./pystone.py Pystone(1.1) time for 50000 passes = 2.25 BTW Dieter, the number of hits/s are on the lines of yours. Out here we are taught to not look at them but total transactional throughput as defined by some very simple e-business tests. Trevor
-- Dieter
===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer
Trevor Warren wrote at 2004-5-21 03:39 -0700:
--- Dieter Maurer <dieter@handshake.de> wrote:
You may increase the number of instructions before Python is ready to switch threads (again to reduce the number of thread switches). This, too, will not drastically improve throughput, though. [snip]
Where is this setting???. Is this the one in zope.conf mentioned as python_check_interval as "1000".
Yes.
... BTW Dieter, the number of hits/s are on the lines of yours. Out here we are taught to not look at them but total transactional throughput as defined by some very simple e-business tests.
Sure, as service times vary highly... My numbers should just give you a feeling, how fast you can get. It is highly unlikely that you can achieve more than 80 to 160 requests per second given your machine. Adding the service times for the individual requests together will give you an upper bound on the number of transactions. You will only get more, when you do either: * serve static content either from (external) caches or directly from Apache * increase CPU speed * increase number of CPU's and (accordingly) Zope processes Of course, you can combine these various approaches. -- Dieter
--- Dieter Maurer <dieter@handshake.de> wrote:
Of course, you can combine these various approaches.
[snip] Thanks Dieter, You have been very helpful in this whole excercise. Trevor
-- Dieter
===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer
On Wed, May 19, 2004 at 07:49:43PM -0700, Trevor Warren wrote:
--- Dieter Maurer <dieter@handshake.de> wrote:
Per Second with RAMCacheManager on???.
Of course, this depends on how costly your rendering is... [snip]
The content is just 3 DTML pages with static html embedded in it. Nothing to fancy and no eye candy at all.
RamCacheManager objects i used to cache all images/dtml scripts. The statistics show that ONLY DTML scripts got cached and no images...why????.
Read the Help text for RAMCacheManager. This is expected behavior. See lib/python/Products/StandardCacheManagers/help/RAM.stx or just click teh "Help" button in the ZMI.
Ofcourse i would use a rever proxy/apache to do that caching but would appreciate some clarity on the same.
There was abso no increase in performance with RamCacheManager enabled for dtml scripts.
Not especially surprising since they weren't doing much work in the first place. At most you saved a little parsing time. RAMCacheManager is intended for things that are computationally expensive. -- Paul Winkler http://www.slinkp.com
--- Paul Winkler <pw_lists@slinkp.com> wrote:
On Wed, May 19, 2004 at 07:49:43PM -0700, Trevor Read the Help text for RAMCacheManager. This is expected behavior. See [snip]
okie. Thanks.
lib/python/Products/StandardCacheManagers/help/RAM.stx
or just click teh "Help" button in the ZMI. work in the first place. At most you saved a little parsing time. RAMCacheManager is intended for things that are computationally expensive. [snip]
okie. Thanks, you have been very helpful paul.
--
Paul Winkler
===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer
Hi Trevor, You might want to take a look at the presentation entitled "Scaling Zope" at http://www.plope.com/misc/szweb/img0.html . I don't have much experience with other appserver platforms, but it's my general understanding that Zope is indeed slower on a per-machine basis than a lot of other systems. It attempts to make up for that liability by scaling across systems very well. - C On Mon, 2004-05-17 at 22:04, Trevor Warren wrote:
Morning Guys/Gals,
I write in regards some wierd performance issues that we have been facing at work. I will illustrate the same in brief.
We are a large consultancy based out of India evaluating App Servers for deployment by customers world wide. I am neither a code guru nor a zope admin guru but am getting along well with the same and work for the Performance Engineering Group here.
Towards benchmarking any app server we port our "TPC-W" certified web application to the enviornment. TPC-W is based in many flavours jsp/asp and now zope_dtml.
Some very simple basic transactions short-circuited(Without Sql queries) on Weblogic/Websphere give me 5-10 times the throughput that i got with simple zope pages. To illustrate the figures...i got a 30TPS(Transactions per sec) compared to a 150+TPS with weblogic/websphere. All zope code i have writte via the ZMI is very simple DTML code. Nothing fancy.
Lemme tell you all that i have 5+ years on gnu/linux and worked with Red Hat. Just to let you know i am serious about the figured above and just dont want to show something in poor light.
Do help me push zope to the limits and i will share the results of the benchmarks as obtained. Somethings i need to start with.....
Caching of Objects in Zope Dynamic Thread Management Features in Zope Shared pool connection management for SQL queries Tuning Documents Monitoring of current instance Capability to pump test load across numerous Zope Servers(If none of the above work)
Appreciate any feedback on the same fellas.
Trevor
===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/
__________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Chris McDonough wrote:
You might want to take a look at the presentation entitled "Scaling Zope" at http://www.plope.com/misc/szweb/img0.html .
Thanks, Chris. I hadn't seen that before. Some verification of some techniques/setups that we've been using, and some new pieces of information as well. I'll make sure the boss sees it. My favorite part: """ High computational expense of frequently accessed functions, aka "bad coding". """ :-) JZ
Hello Chris, --- Chris McDonough <chrism@plope.com> wrote:
than a lot of other systems. It attempts to make up for that liability by scaling across systems very well. [snip]
Thanks for the link Chris. How about scaling across SMP systems???. Trevor
- C
===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/
On Wed, 2004-05-19 at 00:25, Trevor Warren wrote:
Hello Chris,
--- Chris McDonough <chrism@plope.com> wrote:
than a lot of other systems. It attempts to make up for that liability by scaling across systems very well. [snip]
Thanks for the link Chris. How about scaling across SMP systems???.
Just use multiple Zope processes, one for each processor, all talking to the same ZEO server. For best performance, "bind" each Zope process to a single processor (the process for doing so differs across operating systems). - C
Thanks for the link Chris. How about scaling across SMP systems???.
Just use multiple Zope processes, one for each processor, all talking to the same ZEO server. For best performance, "bind" each Zope process to a single processor (the process for doing so differs across operating systems).
Trevor, Just to elaborate this a bit more, this is an issue to do with the global interpreter lock in python. It is an issue with any interpreter or virtual machine. Java has the same problems. I wrote a paper a few years ago on performance of Zope/Python on multi-processor Solaris boxes: http://zope.org/Members/glpb/solaris In it there is references to Java people (specifically BEA Weblogic people) finding that they were encountering the same thread locking issues as I was discovering. Since then Sun have changed their default threading libraries to be the 'alternative' ones discussed in that paper. :) I think most java app servers internally start multiple JVM processes and balance the load across them (I know mod_jk or mod_jserv does). This is that same as what you can achieve with multiple ZEO clients, one for each process, and is accepted as a 'standard' process within the Zope community on multi-processor systems. -Matt -- Matt Hamilton matth@netsight.co.uk Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Design | Zope/Plone Development & Consulting | Co-location | Hosting
--- Matt Hamilton <matth@netsight.co.uk> wrote:
This is that same as what you can achieve with multiple ZEO clients, one for each process, and is accepted as a 'standard' process within the Zope community on multi-processor systems.
[snip] Thanks Matt. I did read about your work profiling soem zope action on solaris. Am giving this ZEO thing a shot today. I am praying that by then end of this all i end with atleast 60-70% perf of the commercial servers else my whole saga of scaling "Open Source/Free Software" won't go anywhere inhouse..:(. Trevor
-Matt
===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer
Trevor Warren wrote:
I am praying that by then end of this all i end with atleast 60-70% perf of the commercial servers else my whole saga of scaling "Open Source/Free Software" won't go anywhere inhouse..:(.
Remember, scalability is not the same as performance. As Chris pointed out, Zope scales extrememly well. Better than pretty much anything else out there. The fact that it is a bit slower than other systems is not really an issue. We could go to town on optimizing it like crazy, or just chuck another server at it. The fact that you could buy another server for a ZEO client for the same cost as a few days of developer time means it is just not worth it. -Matt -- Matt Hamilton matth@netsight.co.uk Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Design | Zope/Plone Development & Consulting | Co-location | Hosting
--- Matt Hamilton <matth@netsight.co.uk> wrote:
Trevor Warren wrote: could buy another server for a ZEO client for the same cost as a few days of developer time means it is just not worth it. [snip]
Okie dear zopie..:D. I am trying to get zope-zeo working with 2.7. All docs i seem to lay my hand on are outdated since zeo is now part of the same tarball. Am glad to RTFM...please send me some links matt. My next tests are on zope-zeo. Need to see how much of your "scalability" mumbo-jumbo works for me. Please revert back asap. Trevor
-Matt
===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer
Trevor Warren wrote:
I am trying to get zope-zeo working with 2.7. All docs i seem to lay my hand on are outdated since zeo is now part of the same tarball.
Am glad to RTFM...please send me some links matt. My next tests are on zope-zeo. Need to see how much of your "scalability" mumbo-jumbo works for me.
Take a look at: http://www.plope.com/Members/chrism/whatsnew_27 Which has some details also, http://www.zopewiki.org/ZEO -Matt -- Matt Hamilton matth@netsight.co.uk Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Design | Zope/Plone Development & Consulting | Co-location | Hosting
--- Matt Hamilton <matth@netsight.co.uk> wrote:
Trevor Warren wrote: Take a look at: [snip]
Thanks Guru, it worked.
-Matt
===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer
Trevor Warren wrote:
Do help me push zope to the limits and i will share the results of the benchmarks as obtained. Somethings i need to start with.....
Caching of Objects in Zope
Look at the RAMCacheManager included with Zope. This will make a big difference.
Dynamic Thread Management Features in Zope
You can adjust the number of threads in the zope.conf file (for Zope 2.7).
Shared pool connection management for SQL queries
Be careful with this. Unlike most other systems, Zope has its own built in object store (ZODB) and hence does not 'look' like many other systems that have an app server and then persist the data to a separate SQL server.
Tuning Documents
Well, DTML is pretty much been superseded now by ZPT. I can't say ZPT is any quicker than DTML, but it is what should be used now. Please post the DTML you are using, as we may be able to offer some tuning hints. If you are doing something like an SQL select from a RDBMS and then iterating over a large result set, there are some well known techniques to speed things up.
Monitoring of current instance
There is a debug screen within Zope, or just use standard process monitoring tools.
Capability to pump test load across numerous Zope servers
This is where Zope is very good. It scales very well, and is extremely easy to do, and requires (in most cases) no changes to the application code. One thing to mention, is that python does not utilize multiple processes very well. Hence if you have a multi-processor server, you are better off running multiple ZEO clients, one for each processor. I hope this helps. If you can send us any more information about your test setup and benchmarks we may be able to help more. :) -Matt -- Matt Hamilton matth@netsight.co.uk Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Design | Zope/Plone Development & Consulting | Co-location | Hosting
Trevor Warren wrote at 2004-5-17 19:04 -0700:
... Do help me push zope to the limits and i will share the results of the benchmarks as obtained. Somethings i need to start with.....
Caching of Objects in Zope
Look at cache managers, e.g. RAMCacheManager to cache parts of pages. Z SQL Methods provide caching. You can tune the ZODB cache (in Zope 2.7 via the configuration file).
Dynamic Thread Management Features in Zope
You have little control. You can control the number of threads and the interval between thread switches are checked. Note that Python (and therefore Zope) usually cannot use multiprocessor systems efficiently. This is because in a multi-threaded Python application at most one thread can execute Python code -- even on a multiprocessor system. You need a different architecture (different processes sharing a common database via ZEO).
Shared pool connection management for SQL queries
The default pools are not bad (with respect to speed).
Tuning Documents
A major speed issue is Zope's security mechanism. Each single access to an object/a method is checked in TTW code. This slows things down considerably. When you are interested in high speed rendering, you can do it in an External Method that (maybe) renders a "DocumentTemplate" directly.
Monitoring of current instance
In what respect?
Capability to pump test load across numerous Zope Servers(If none of the above work)
Many Zope's + one ZEO. There is a "ZEO" HowTo around. -- Dieter
Note that Python (and therefore Zope) usually cannot use multiprocessor systems efficiently. This is because in a multi-threaded Python application at most one thread can execute Python code -- even on a multiprocessor system.
Is this planned to be fixed in Python in the near future? Tim
On Tue, May 18, 2004 at 11:19:25PM +0200, Tim Terleg?rd wrote:
Note that Python (and therefore Zope) usually cannot use multiprocessor systems efficiently. This is because in a multi-threaded Python application at most one thread can execute Python code -- even on a multiprocessor system.
Is this planned to be fixed in Python in the near future?
No. ZEO makes it trivial to use multiple processes instead. Don't worry about it. http://blog.colorstudy.com/ianb/weblog/2003/10/31.html -- Paul Winkler http://www.slinkp.com
--- Tim_Terleg�rd <tim@se.linux.org> wrote:
Note that Python (and therefore Zope) usually cannot use multiprocessor systems efficiently. This is because in a multi-threaded Python application at most one thread can execute Python code -- even on a multiprocessor system. [snip]
This is disastrous. What engineering marvel necessitated such an architecture. Would luv to be educated on this front. So this means if i have a Single CPU system, the max i can get from Zope multithreaded towards handling 100 diff threads simultaenously would be really meagre as compared to any other application server architectured to handle multiple threads simultaenously. Does this esplain the 30TPS as compared to the 100+ TPS for the simple short circuit(no sql) tests conducted on my SMP system here at the labs???. Trevor
Is this planned to be fixed in Python in the near future?
Tim
===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/
On Wed, 2004-05-19 at 01:31, Trevor Warren wrote:
--- Tim_Terlegrd <tim@se.linux.org> wrote:
Note that Python (and therefore Zope) usually cannot use multiprocessor systems efficiently. This is because in a multi-threaded Python application at most one thread can execute Python code -- even on a multiprocessor system. [snip]
This is disastrous. What engineering marvel necessitated such an architecture. Would luv to be educated on this front.
Actually, Tim's statement isn't entirely true. "Python code" consists of calls into the interpreter but it also obviously uses a bunch of C code and OS libraries do a lot of its work (opening files, sockets, doing regular expressions, sleeping, etc.) When Python code executes and it hits a patch of code in which it's safe to "release the global interpreter lock" (which can happen a lot), the process can execute code on multiple CPUs. So even a single Python process does and can execute code on multiple CPUs. I think someone stated after a bunch of research at some point (which I've lost) that running a single Zope process for some common application on a dual-processor machine made effective use of about 75% of each processor's resources. It *would* be far more disastrous if it actually made any measurable difference to Zope performance in a production environment, given that ZEO exists and you can use as many processes as you want on a single box or across as many boxes as you like to serve up Zope content.
So this means if i have a Single CPU system, the max i can get from Zope multithreaded towards handling 100 diff threads simultaenously would be really meagre as compared to any other application server architectured to handle multiple threads simultaenously.
Performance doesn't always equate to being able to spawn and service some number of threads. In fact, Zope's underlying web server architecture doesn't use threads at all. It's async-based. Zope itself uses a number of worker threads to service requests that get queued up by the async server. This is indeed for Zope where all the time is spent, so creating more threads may help. But other systems, like Squid, which can handle an ungodly number of requests per second doesn't need any extra threads to do so. That distinction is pedantic in this case, because you're right, increasing the number of threads (up to some point) should increase *Zope* performance. I haven't done any structured testing of performance vs. number of threads, however, so where the "knee" is, I don't know. It's also probably very application-dependent.
Does this esplain the 30TPS as compared to the 100+ TPS for the simple short circuit(no sql) tests conducted on my SMP system here at the labs???.
Maybe. I don't know what defines a "transaction" (you'd need to post the code and the steps you took to get the numbers). But actually, if you're following your own rules about testing the system "in situ", you would probably not connect Zope to any SQL server. Zope doesn't need a SQL server to store data. So the "shortcut" case might actually be the "real" case if you took the SQL server out of the mix. That said, there's no denying it: a single Zope process is slow. I hope no one here will try to convince you otherwise. I suspect that if you compare one Zope process to one Weblogic process, Weblogic will beat the snot out of it for many tests. But if you compare the performance of 40 instances of Zope on 20 machines serviced by a ZEO server to whatever you'd need to do to Weblogic to get it scaled across that much hardware sharing the same data storage, I suspect Zope would beat the living daylights out of it from a cost/performance perspective. Scaling Zope adequately requires you to believe that hardware is cheap but thinking is expensive. If you're unable/unwilling to take that leap of faith, you're probably better off sticking with a Java appserver. - C
Trevor Warren wrote at 2004-5-18 22:31 -0700:
... So this means if i have a Single CPU system, the max i can get from Zope multithreaded towards handling 100 diff threads simultaenously would be really meagre as compared to any other application server architectured to handle multiple threads simultaenously.
Python's threading model is good for *single* CPU systems. It usually cannot fully use the power of a *multi* processor system. The reason for this: Python uses reference counting for primary "garbage" detection. Reference count fields are a global resource and require protection. Reference count updates are very frequent. Therefore, it is more efficient (at least on a single CPU system) to protect large sequences of Python code by a lock (the so called Global Interpreter Lock (GIL)) than lock locally for every reference count update.
Does this esplain the 30TPS as compared to the 100+ TPS for the simple short circuit(no sql) tests conducted on my SMP system here at the labs???.
You can use my "ZopeProfiler" product to find out where the time is spent. Be warned, profiling drastically slows Zope down. You do it only to find out the bottlenecks. <http://www.dieter.handshake.de/pyprojects/zope> -- Dieter
Hello Dieter, --- Dieter Maurer <dieter@handshake.de> wrote:
Trevor Warren wrote at 2004-5-18 22:31 -0700: Python's threading model is good for *single* CPU systems. It usually cannot fully use the power of a *multi* processor system. [snip]
Am back to a single cpu system as mentioned in my previous mails. Lets now get this smarto to !!!rock!!!..:D. With your knowledge i am sure we can.
to protect large sequences of Python code by a lock (the so called Global Interpreter Lock (GIL)) than lock locally for every reference count update. [snip]
okie.
is spent. Be warned, profiling drastically slows Zope down. You do it only to find out the bottlenecks.
Shall use the zope profiler too. Will keep you posted on the same Dieter. Trevor
-- Dieter
===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer
Hello Dieter, Which of the following would help me get zope to scale better on a single box:
ZEO with multiple client instances apache+Zope
Lemme know and i will have some new benchmark tests run. Trevor ===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer
Trevor Warren wrote at 2004-5-19 19:43 -0700:
Which of the following would help me get zope to scale better on a single box:
ZEO with multiple client instances apache+Zope
If you have a single CPU system, ZEO will slow things down... Apache, too, will slow things down (although I would recommend to use it in production for other reasons and therefore include it in the benchmark) -- unless you use it to serve static content or provide caching. ZEO will only speed things up when more CPUs are involved. You will then also want to have a LoadBalancer (e.g. "pound") to send requests to the different Zope processes. -- Dieter
--- Dieter Maurer <dieter@handshake.de> wrote:
ZEO will only speed things up when more CPUs are involved. You will then also want to have a LoadBalancer (e.g. "pound") to send requests to the different Zope processes. [snip]
Thanks again Dieter, As of now the testing tool has been programmed to come up with hits to the Zope client processes as follows:
machine 1 (2cpu, 1gb ram) : 1 Zeo Server + 3 Zope Clients machine 2 (2cpu, 1gb ram) : 3 Zope Clients
Will have pound checked out too. Thanks again dieter. Trevor
-- Dieter
===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer
On Friday 21 May 2004 12.29, Trevor Warren wrote:
--- Dieter Maurer <dieter@handshake.de> wrote:
ZEO will only speed things up when more CPUs are involved. You will then also want to have a LoadBalancer (e.g. "pound") to send requests to the different Zope processes.
[snip]
Thanks again Dieter, As of now the testing tool has been programmed to come up with hits to the Zope
I don't really know what is it you do, but I can give you a few indicators: - Duron 1GHz, 256M, plain Zope + DirectoryStorage achieves an easy 30 reqs/sec on relatively static storage (DTML). - Same for heavier load (complex pages + images) does comfortably 20 reqs/sec Both are straight to Zope, no caches! - 2xAMD 2200+, 512M, ZEO + 1 client + Pound achieves sustained 120 reqs/sec on normal pages (ZPT). - 4 machines (each AMD 2000+, 256M), ZEO, 4 clients, Pound: sustained 280 reqs/sec, peaks over 400. All of the above are long-term statistics from our clients. I strongly suggest you have a look at your network topology, logging setup, profiling, etc. In most cases the kind of problems you describe have little to do with Zope - most often it's some name resolution problem or a badly written application. -- Robert Segall Apsis GmbH Postfach, Uetikon am See, CH-8707 Tel: +41-1-920 4904
Hey guys, Dieter, Paul, Robert and the rest. The past few week has indeed been a very ===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer
Hey guys, Dieter, Paul, Robert and the rest. The past few week has indeed been a very joyful experience. With Zope stalwarts coming out with their bouquets/brickbats towards helping me scale FLOSS into my enterprise. Which *hopfully* will translate to customers across 50 countries. I still have to repeat the previous tests with SQL queries but am quit satisfied with the performance achieved till date. Since everyoen has been asking, "what are these frigging transactions i am talking about??". In our inhouse tests we totally disregard hits/sec and focus our efforts on scalbility/performance/Montoring/Stability/System-Network Load. Thus i have been evry keen on ensuring the same. No doubt the hits's aer somthing i know the rest of the world can relate to and hence i post them here. My results are as follows:
Transactions : 3 Types consisting of an item buy/sell/view
Hardware : 2 x 2 Cpu(Hyperthreaded, which means the OS sees 4), 1 GB RAM, 36 GB SCSI and a SAN
Tests carried across various scenarios spaning finite time intervals.
DB Cache : 20000
RamCacheManager : Null (Get no performance boost with it on, some gurus say with more ZPT complexity it may help. But i had a nasty surprise. With the ZPT cached, there is total serving of the objects from mem which causes stale variables to be served. All efforts spent in making complex random quieries are naught with this option.)
DB Pool : 15
Zope client Threads : 10
Zeo Server : 1
Setup : 2 Zope CLients and 1 Zeo server
Test results....:D.
hits/sec: 460 hits/s TPS : 40+ System usage : <50%
The issue was the M$ client and n/w which brought me to conclude mid-way what i did. I am eating my own words and on record put down these values. Please write in for any further clarifications. I will still pursue other tests with complex sql's and will be in touch. Thanks again Dieter, Paul and others. Trevor ===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer
Trevor Warren
RamCacheManager : Null (Get no performance boost with it on, some gurus say with more ZPT complexity it may help. But i had a nasty surprise. With the ZPT cached, there is total serving of the objects from mem which causes stale variables to be served. All efforts spent in making complex random quieries are naught with this option.) That may depend on the nature of your actual production environment. If your RamCache is caching each template irrespective of the parameters sent to it, then yes, you'll get stale data. However, if, in practise, a given template with the same given parameters returns the same result, a RamCache is appropriate. My understanding (based on a quick look at the source) is that the RAMCacheManager indexes cached objects based on the request that generates them. Thus repeated accesses with exactly the same request URL will return the same object (subject to cache expiry). That's what caching *is*! You can adjust the cache max age (it's the max_age parameter on creation), so if, for example, your data isn't update more often than every n seconds but requests come more frequently, then set max_age to something less than n (say, n/2) and see if that helps.
Anyway, one reason I'm responding here is that I've been comparing effects of RamCache with use of AcceleratedHTTPCache to manage an Apache 2 cache. I pretty much get equivalent results, with Apache caching *slightly* faster. Appears that either Zope uses RAM to cache stuff, or Linux uses it to cache the disk or file page cache that Apache uses. Anyone else done this sort of testing?
hits/sec: 460 hits/s TPS : 40+ System usage : <50% Are you able to tell us how this compares with other setups (and other technologies) you've tried?
Please write in for any further clarifications. I will still pursue other tests with complex sql's and will be in touch. As a general rule of thumb in Zope testing, I've found that the more complexity I shift to the SQL and the less processing I do in Python, the faster it all goes (as one might expect). Of course, you lose a certain amount of flexibility that way, and given the choice I'd rather write Python than SQL :)
Glad to hear that you've found the source of your problems, Trevor. Ben Last Technical Director SleepyDog 07966 136572 ben@sleepydog.net ben@benlast.com
Ben Last (Zope) wrote:
Anyway, one reason I'm responding here is that I've been comparing effects of RamCache with use of AcceleratedHTTPCache to manage an Apache 2 cache. I pretty much get equivalent results, with Apache caching *slightly* faster. Appears that either Zope uses RAM to cache stuff, or Linux uses it to cache the disk or file page cache that Apache uses. Anyone else done this sort of testing?
The Zope result caching tools have a time and a place when they should be used, and several where they should not. The Accelerated HTTP Cache Management stuff doesn't belong in the same league as the RAM Cache Manager; the former is protocol and header control, the latter is physical cache of keys and values. Using a cache in your gateway server is different again, its only for caching entire resources. Its really important to understand the distinctions if you expect to get anything from caching. For example, using a RAM Cache Manager to accelerate the render times of static content is a waste of resources, using a RAM Cache Manager to accelerate times of dynamic content about to published is a waste of resourcs, and quite possibly dangerous from a security standpoint. Using a RAM Cache Manager to accelerate the rendering of intermediate objects that are not published directly and who's dynamic arguments have already been declared safe, is an appropriate use. In general, content that is about to be published should be cached by the gateway server, or by the Acclerated HTTP Cache Manager in the event that the gateway server doesn't have enough context to do a good job. -- Jamie Heilman http://audible.transient.net/~jamie/ "...thats the metaphorical equivalent of flopping your wedding tackle into a lion's mouth and flicking his lovespuds with a wet towel, pure insanity..." -Rimmer
Helo Ben, --- "Ben Last (Zope)" <zope@benlast.com> wrote:
Are you able to tell us how this compares with other setups (and other technologies) you've tried? [snip]
I won't specifically name any commercial app web servers out there for certain reasons. But with the java app web servers one can expect the following on the config i mentioned earlier:
100-150+ TPS (Test Transactions pertaining to a simple buy/sell/view) with a single instance of the commercial server, while i got a 20+ here with Single instance of Zope-Zeo. When scaling the setup to two machines there seems to be a non-liner increase in throghput as follows 40TPS and 450-500 hits/s.
250-350 hits/sec on the commercial app webservers with on instance running while about 150-200 hits/sec with once instance of the Zope-Zeo server running.
Glad to hear that you've found the source of your problems, Trevor. [snip]
Thanks. M$ almost killed me with their crappy s/w, but a last minute change of scenarion helped locate the crux of the issue. Intelluctual Property, consumer protection and Zope...:D. What kind of stuff are you into with Zope/python there at sleepydog?. Trevor
Ben Last Technical Director
===== ( >- -< ) /~\ ______________________________________ /~\ | \) / Scaling FLOSS in the Enterprise \ (/ | |_|_ \ trevorwarren@yahoo.com / _|_| \____________________________________/ __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer
Intelluctual Property, consumer protection and Zope...:D. What kind of stuff are you into with Zope/python there at sleepydog?. Using Zope to build a consumer-focused website (to support a mobile phone product) that may need to scale to vast numbers of hits. Hence a lot of focus on caching - it's dynamic in the sense that the pages are generated by templates, but they change sufficiently seldom that both levels of Zope cache can be used (as appropriate, as Jamie H. points out) to serve very high numbers of requests with minimal Zope load. I chose Zope because I have a bunch of extremely non-web-tech-literate people populating the site (all the content interfacing is via the ZMI) and because I have to do most of the engineering myself and I'd far rather work in Python than mess around with PHP or Perl (or even... shudder... ASP).
We're also working on a PlayStation game that has a vast database behind it; that's all Python/MySQL driven, but it uses ZODB for intermediate result caching of some very compute-intensive stuff that can take a couple of days to run. Which brings me to a question - I'm at the point of sorting out Zope hosting. Anyone got recommendations for a good hosting company, Linux-based, Zope-literate, that'll scale from a single dedicated server to a load-balanced cluster (as required)? UK preferred, EU second choice, US if we have to (I don't have anything against the US, it's the time difference that can be an issue). Ben
Ben Last (Zope) wrote:
Using Zope to build a consumer-focused website (to support a mobile phone product) that may need to scale to vast numbers of hits. Hence a lot of focus on caching - it's dynamic in the sense that the pages are generated by templates, but they change sufficiently seldom that both levels of Zope cache can be used (as appropriate, as Jamie H. points out) to serve very
Another general point to make about caching, and RAMCacheManager: you can cache *method calls* rather than entire http page requests. Whilst most people just use a RAMCacheManager to cache an entire page ZPT, you can cache individual sub-templates. This can be very useful to pages in which the majority of the page is static, an just a small part changes. We used this technique for an e-Commerce site in which the mail body of the page was a list of products, which was quite expensive to generate. We cache that central area (as a separate ZPT), but we don't cache the containing ZPT which contains things like the shopping basket details, etc.
We're also working on a PlayStation game that has a vast database behind it; that's all Python/MySQL driven, but it uses ZODB for intermediate result caching of some very compute-intensive stuff that can take a couple of days to run.
Cool :) It is always interesting to see systems that don't have the traditional web browser as the client. We did some work using Zope as a backend to a flash-based training app that made calls via XML-RPC to the backend.
Which brings me to a question - I'm at the point of sorting out Zope hosting. Anyone got recommendations for a good hosting company, Linux-based, Zope-literate, that'll scale from a single dedicated server to a load-balanced cluster (as required)? UK preferred, EU second choice, US if we have to (I don't have anything against the US, it's the time difference that can be an issue).
We are UK based (Bristol) and offer hosting. We don't offer shared Zope hosting, as we believe you really need filesystem access to make the most of Zope. We do offer a competitive colocation service, and have experience in scaling Zope and setting up ZEO clusters. Email me off-list if you want more details. -Matt -- Matt Hamilton matth@netsight.co.uk Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Design | Zope/Plone Development & Consulting | Co-location | Hosting
Trevor Warren wrote:
Please write in for any further clarifications. I will still pursue other tests with complex sql's and will be in touch.
Trevor, When you get to the point of having your *actual* transaction code written in Zope, let us know. It is quite easy in Zope to write code that performs badly (or rather there are some very simple easy optimizations that can be done). We may be able to help you optimize the transaction code as well. Especially if you have any loops in the code (e.g. fetching 100 rows from an SQL DB and displaying them in an HTML table). Glad to hear you are getting some decent results at last :) -Matt -- Matt Hamilton matth@netsight.co.uk Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Design | Zope/Plone Development & Consulting | Co-location | Hosting
Hello Matt, --- Matt Hamilton <matth@netsight.co.uk> wrote:
written in Zope, let us know. [snip]
I will matt. Am just back from mass and trying to get some reading up done on Zope. Working with the Zope book.
It is quite easy in Zope to write code that performs badly (or rather there are some very simple easy [snip]
yeh...:D. You can say that again. Personally i ain't a hacker so i shouldn't be talking about others code. On Most of the projects i have worked on till now "Getting the App to Perform and Scale" has been an after thought. And this is the norm until the Developers realise that some very basic code ethics/golden rules haven't been followed. Hopefully that will change some day.
optimizations that can be done). We may be able to help you optimize the transaction code as well. Especially if you have any loops in the code (e.g. fetching 100 rows from an SQL DB and displaying them in an HTML table). [snip]
Will be in touch. Generally using Stored Procedures, reducing joins, tuning the db, caching db objects until they get dirty in memory structures are activities we perform towards getting apps to scale. I will surely be in touch guruji(In hindi and india dialect it means master)...:D.
Glad to hear you are getting some decent results at last :)
[snip] Thanks to your <grumble>:D</grumble>. Trevor
-Matt
===== ( >- -< ) /~\ ______________________________________ /~\ | \) / Scaling FLOSS in the Enterprise \ (/ | |_|_ \ trevorwarren@yahoo.com / _|_| \____________________________________/ __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer
Trevor Warren wrote:
/~\ ______________________________________ /~\ | \) / Scaling FLOSS in the Enterprise \ (/ |
BTW, WTF is FLOSS? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
BTW, WTF is FLOSS?
http://www.google.com/search?q=floss and occam's razor sez 3rd hit from the top .. but yeah, Trevor, if you aren't already preaching to the converted, FLOSS isn't going to ring many bells .. -- Jean Jordaan http://www.upfrontsystems.co.za /training <-- Zope/Plone training! /training/af <-- Nie af nie, Afrikaans.
--- Jean Jordaan <jean@upfrontsystems.co.za> wrote:
already preaching to the converted, FLOSS isn't going to ring many bells .. [snip]
It was a compromise Jean, any suggestions/improvisation??. Unless i have something better it won't change. Trevor
-- Jean Jordaan
===== ( >- -< ) /~\ ______________________________________ /~\ | \) / Scaling FLOSS in the Enterprise \ (/ | |_|_ \ trevorwarren@yahoo.com / _|_| \____________________________________/ __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/
Trevor Warren wrote:
/~\ ______________________________________ /~\ | \) / Scaling FLOSS in the Enterprise \ (/ |
BTW, WTF is FLOSS?
Free, Libre, Open Source Software... or something like that :) You never heard Paul Browning's idea for 'The FLOSS club' in Bristol -- sounded a bit dodgy to me ;) -- Matt Hamilton matth@netsight.co.uk Netsight Internet Solutions, Ltd. Business Vision on the Internet http://www.netsight.co.uk +44 (0)117 9090901 Web Design | Zope/Plone Development and Consulting | Co-location | Hosting
--- Matt Hamilton <matth@netsight.co.uk> wrote:
Bristol -- sounded a bit dodgy to me ;) [snip]
Dodgy eh!!!. Any specific reason dear?. There are many reasons i use FLOSS...
open source hurts the fsf guys Closed source isn't my ball game Free Software can be misleading at times if not defined in the right perspective to the first timer
Trevor
-- Matt Hamilton
===== ( >- -< ) /~\ ______________________________________ /~\ | \) / Scaling FLOSS in the Enterprise \ (/ | |_|_ \ trevorwarren@yahoo.com / _|_| \____________________________________/ __________________________________ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/
Trevor Warren wrote:
--- Matt Hamilton <matth@netsight.co.uk> wrote:
Bristol -- sounded a bit dodgy to me ;)
[snip]
Dodgy eh!!!. Any specific reason dear?. There are many reasons i use FLOSS...
...who also appears to lack understanding of english humour ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Matt Hamilton wrote:
Trevor Warren wrote:
/~\ ______________________________________ /~\ | \) / Scaling FLOSS in the Enterprise \ (/ |
BTW, WTF is FLOSS?
Free, Libre, Open Source Software... or something like that :) You never heard Paul Browning's idea for 'The FLOSS club' in Bristol -- sounded a bit dodgy to me ;)
Ah, okay, so his sig really is pointless buzzword bollocks then ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Many Zope's + one ZEO. There is a "ZEO" HowTo around. [snip]
Thanks again. I will have that worked out and perform the same test. Will post the results once done. How about apache taking the http hits and zope doing the dynamic work. Will that be any better/worse than what you are suggesting???. Trevor
-- Dieter
===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? SBC Yahoo! - Internet access at a great low price. http://promo.yahoo.com/sbc/
On Wed, May 19, 2004 at 06:34:42AM -0700, Trevor Warren wrote:
Many Zope's + one ZEO. There is a "ZEO" HowTo around. [snip]
Thanks again. I will have that worked out and perform the same test. Will post the results once done.
How about apache taking the http hits and zope doing the dynamic work. Will that be any better/worse than what you are suggesting???.
I would venture a guess that apache with caching enabled - or Squid - will give you a much more noticeable increase in performance than adding one or more additional nodes to your ZEO cluster... IF you are serving a significant amount of cacheable data: images, semi-static content... OTOH, if you are doing a lot of really dynamic stuff - updating content, running catalog queries that need to be very up to date, etc. - then ZEO will give good benefits. Read Chris M's paper. It's got a lot of good info. -- Paul Winkler http://www.slinkp.com
--- Paul Winkler <pw_lists@slinkp.com> wrote:
On Wed, May 19, 2004 at 06:34:42AM -0700, Trevor updating content, running catalog queries that need to be very up to date, etc. - then ZEO will give good benefits.
Read Chris M's paper. It's got a lot of good info. [snip]
Thanks paul.
Paul Winkler http://www.slinkp.com
===== ( >- -< ) /~\ __ Scaling FLOSS in the __ /~\ | \) / Enterprise : trevor.w@pvision.biz \ (/ | |_|_ \ Call Now: 9820349221 / _|_| \____________________________________/ __________________________________ Do you Yahoo!? Yahoo! Domains � Claim yours for only $14.70/year http://smallbusiness.promotions.yahoo.com/offer
participants (12)
-
Ben Last (Zope) -
Chris McDonough -
Chris Withers -
Dieter Maurer -
Jamie Heilman -
Jean Jordaan -
John Ziniti -
Matt Hamilton -
Paul Winkler -
Robert Segall -
Tim Terlegård -
Trevor Warren