[Zope-dev] how bad are per-request-write-transactions
Hi, How bad are per-request transactions in a non-ZEO environment? I.e. each request on a folder or its subobjects will cause a write transaction (somewhat like a non-fs counter, but worse as it happens for all subobjects) And if this is really bad, are there any workarounds except for writing to the filesystem? Cheers Ivo -- Drs. I.R. van der Wijk -=- Brouwersgracht 132 Amaze Internet Services V.O.F. 1013 HA Amsterdam, NL -=- Tel: +31-20-4688336 Linux/Web/Zope/SQL/MMBase Fax: +31-20-4688337 Network Solutions Web: http://www.amaze.nl/Consultancy Email: [EMAIL PROTECTED] -=- ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] death to index_html; ObjectManager?
I am seeing some undesirable effects of the recent 'death to index_html' changes. Folders now have a 'Settings' tab to allow managers to change the default document. This is good. However, the implementation of this lies in the ObjectManager class. The browser-default capabilities may not make sense for other classes, derived from ObjectManager, which are not general purpose 'folders'. I think it would make more sense for the browser-default implementation to sit in a new mixin base class, perhaps OFS.BrowserDefaultManager.BrowserDefaultManager, to be included as a base class of OFS.Folder.Folder but not OFS.ObjectManager.ObjectManager. Any thoughts? Toby Dickenson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: death to index_html; ObjectManager?
The implementation adds the API to manage browser default for all objectmanagers. However, no browser_default handler is actually added to the object unless you specify a default other than index_html What was the specific undesirable effects you were seeing? If it is agreed that this management should apply to folders rather than all object managers, then I can make this change. In that case using a separate mix-in makes sense to me. It could even be registered for use as a base class for ZClasses then, which would be some advantage I suppose. Thanks for the feedback. -Casey Toby Dickenson wrote: I am seeing some undesirable effects of the recent 'death to index_html' changes. Folders now have a 'Settings' tab to allow managers to change the default document. This is good. However, the implementation of this lies in the ObjectManager class. The browser-default capabilities may not make sense for other classes, derived from ObjectManager, which are not general purpose 'folders'. I think it would make more sense for the browser-default implementation to sit in a new mixin base class, perhaps OFS.BrowserDefaultManager.BrowserDefaultManager, to be included as a base class of OFS.Folder.Folder but not OFS.ObjectManager.ObjectManager. Any thoughts? Toby Dickenson [EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] how bad are per-request-write-transactions
This will kill performance, especially concurrent use of the site. It will also cause large amounts of database bloat. Do you need real time numbers, or is a delay (such as 24 hours) acceptable? If you can stand a delay, another approach would be to write a script which scans the z2.log file (or another log that you generate on page hits) each night and in a single transaction updates a counter on each object hit. If you use the z2.log, no additional writing is needed to the FS, and you get the benefit of easy access to the counts directly from the objects, without degrading performance or db bloat. -Casey Ivo van der Wijk wrote: Hi, How bad are per-request transactions in a non-ZEO environment? I.e. each request on a folder or its subobjects will cause a write transaction (somewhat like a non-fs counter, but worse as it happens for all subobjects) And if this is really bad, are there any workarounds except for writing to the filesystem? Cheers Ivo ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: death to index_html; ObjectManager?
On Tuesday 16 Apr 2002 3:53 pm, Casey Duncan wrote: What was the specific undesirable effects you were seeing? 1. The extra tab in the management interface. 2. That an ObjectManager-derived classes might have a default method which is something other than index_html. (I havent digested this proposal enough to see whether an ObjectManager-derived class can prevent his default method from being changed, but It feels wrong that he should have to) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [RFClet]: What about the request method and the client side trojan?
Oliver Bleutgen [EMAIL PROTECTED] wrote: Although I repeat myself, implementing this proposal would give me a lot of options to prevent myself from this kind of attack, completely or partially. - In Internet Explorer I can disable javascript. (problem solved) - In Internet Explorer I use the zone restrictions (prevents attacks from untrusted servers) - I can do the same in mozilla - additionally, in mozilla I can just disable form submitting in javascript, with something like (this is surely wrong) user_pref(capability.policy.default.HTMLFormElement.submit, noAccess); Put this your prefs.js file and you are done. Really, it _would_ help. Okay, I agree that it does indeed help. Florent -- Florent Guillaume, Nuxeo (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: death to index_html; ObjectManager?
On 4/16/02 8:53 AM, Casey Duncan [EMAIL PROTECTED] wrote: The implementation adds the API to manage browser default for all objectmanagers. However, no browser_default handler is actually added to the object unless you specify a default other than index_html What was the specific undesirable effects you were seeing? If it is agreed that this management should apply to folders rather than all object managers, then I can make this change. In that case using a separate mix-in makes sense to me. It could even be registered for use as a base class for ZClasses then, which would be some advantage I suppose. +1 for the separate mix-in. I use ObjectManager as a base class frequently for non-folderish objects, for which the whole 'death to index_html' notion is moot. -- Jeffrey P Shell www.cuemedia.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: death to index_html; ObjectManager?
Well I honestly hadn't considered that. So, I suppose changing to to a mix-in inherited by folder is better. However, you should know that the crux of this change is really to the publisher, the mixin is just the management piece. *any* object can define a browser_default hook that overrides 'index_html', not just objectmanagers. -Casey Jeffrey P Shell wrote: On 4/16/02 8:53 AM, Casey Duncan [EMAIL PROTECTED] wrote: The implementation adds the API to manage browser default for all objectmanagers. However, no browser_default handler is actually added to the object unless you specify a default other than index_html What was the specific undesirable effects you were seeing? If it is agreed that this management should apply to folders rather than all object managers, then I can make this change. In that case using a separate mix-in makes sense to me. It could even be registered for use as a base class for ZClasses then, which would be some advantage I suppose. +1 for the separate mix-in. I use ObjectManager as a base class frequently for non-folderish objects, for which the whole 'death to index_html' notion is moot. ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
RE: [Zope-dev] Speaking of 2.6...
...I sent out a note a while ago now trying to scare up some ideas on how to vet the current list of 2.6 proposals and get to a final plan. I didn't get much (any?) response :( I am, as the author of the dtml-set tag, of course willing to commit to the implementation of this tag for 2.6 How about 'vetted' - It's set to N, when will I know if I should start coding? Ivo - I don't have a problem with the spelling of this. I _do_ have a problem with the fact that it (your existing release) actually stores the variable in REQUEST. If it were to store them somewhere more appropriate in the DTML namespace stack, I'd be happy to OK it. We'd also need someone to commit to providing the extra docs for the help system and the dtml reference section of the online Zope book. Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: death to index_html; ObjectManager?
On Tue, 16 Apr 2002, Casey Duncan wrote: However, you should know that the crux of this change is really to the publisher, the mixin is just the management piece. *any* object can define a browser_default hook that overrides 'index_html', not just objectmanagers. All the more reason to make it a mixin, yes? --RDM ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Speaking of 2.6...
On Tuesday 16 April 2002 03:44 pm, Brian Lloyd wrote: ...I sent out a note a while ago now trying to scare up some ideas on how to vet the current list of 2.6 proposals and get to a final plan. I didn't get much (any?) response :( By the way, Brian, if I can with the remaining amount of time left, I'll do the work I volunteered to do. However, perhaps I speak for others in that I look to you and ZC for leadership as to *whether* I should do the work. I simply don't know how to vet the list, and I feel like you guys are the leaders. I offered to help, and I meant it, but I feel you guys are the leaders for this, particularly for a release, for what seems to be obvious reasons. So, at least to go back to basics and give you a practical answer to your question of ancient history, I have no idea how to vet the list. If it is vetted and I am called on to do some work, then I'm happy to do it if my schedule still permits it by the time the decision is made. This seems like another community initiative that fizzled: at least in my part that is so because I felt you guys should lead this, but I never got around to telling you so. So, sorry. :-( But better late than never, perhaps. Maybe other folks disagree. Thanks. Gary ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Speaking of 2.6...
On Tue, 9 Apr 2002 13:47:49 -0400 Brian Lloyd [EMAIL PROTECTED] wrote: ...I sent out a note a while ago now trying to scare up some ideas on how to vet the current list of 2.6 proposals and get to a final plan. I didn't get much (any?) response :( Hello Brian, just to give some feedback and ask for guidance with the further process. My college, Nils Kassube, has implemented the proposed features, regarding an enhanced MailHost, namely the usage of timeoutsocket in the SMTP-module and the archiving of outgoing mails. We also asked the programmer of timeoutsocket for permission, although the module has a BSD-license. He has no problem with the incorporation of the module into the Zope2 code base. Our current plan is to upload a patch to the collector, so other people, specifically people with a server setup under windows can test this and to send a note to Zope-Dev seeking for feedback. I have checkin privileges and also signed the the necessary papers, so later I can integrate the patch into the code base. Would it be enough to put a documentation in the proposal wiki and is the proposal sufficient? Should we take other actions? We would like to have this incorporated. Please take this mail as a commitment notification :-). Thanks for any answers, with regards, __Janko Hauser -- i.A. Dr. Janko Hauser Software Engineering c o m . u n i t G m b H online-schmiede seit 1994 http://www.comunit.de/ mailto:[EMAIL PROTECTED] Eiffestr. 598 20537 Hamburg | Germany Fon 040 | 21 11 05 25 Fax 040 | 21 11 05 26 ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] how bad are per-request-write-transactions
I developed a profiler service for a production site about 8 months ago. I essentially did what you are asking. I needed to see how customers were using the various navigational elements and other services provided within the site layout. The logging service could not give me a sense of the context. To make a long story short, I had a method in the standard_html_header that kicked off the evaluation process. I essentially created a mirror of the site (containers/sub-containers/methods) for each hit for each day for each month , etc... This provided me with a way to see specific site activity in real-time. Each object that was evaluated (for each day) had two tinyTable instances. One recorded each hit as a record (IP, referrer, username, time) while the other tallied the numbers per hit (per unique IP). This was all running on a Sun on a terrible network and I saw little or no performance difference and the ZODB growth was as you might expect adding the additional folder objects and tinyTable instances. It wasn't a high profile site (about 3000 hits per week). I ran the service for three months with no problems. The key was the hits recorded in the tinyTable's did not create a ZODB transaction. Hope this helps Eric - Original Message - From: Casey Duncan [EMAIL PROTECTED] To: Ivo van der Wijk [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, April 16, 2002 10:04 AM Subject: Re: [Zope-dev] how bad are per-request-write-transactions This will kill performance, especially concurrent use of the site. It will also cause large amounts of database bloat. Do you need real time numbers, or is a delay (such as 24 hours) acceptable? If you can stand a delay, another approach would be to write a script which scans the z2.log file (or another log that you generate on page hits) each night and in a single transaction updates a counter on each object hit. If you use the z2.log, no additional writing is needed to the FS, and you get the benefit of easy access to the counts directly from the objects, without degrading performance or db bloat. -Casey Ivo van der Wijk wrote: Hi, How bad are per-request transactions in a non-ZEO environment? I.e. each request on a folder or its subobjects will cause a write transaction (somewhat like a non-fs counter, but worse as it happens for all subobjects) And if this is really bad, are there any workarounds except for writing to the filesystem? Cheers Ivo ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
