Re: Pylons Evaluation -Questions
On Fri, 2007-04-27 at 17:27 -0700, Shannon -jj Behrens wrote: On 4/27/07, Cliff Wells [EMAIL PROTECTED] wrote: Out of curiosity, how is this ugly? This should be mostly handled transparently by the proxy (i.e. sends same sessions to same backend). If one Web server dies, all the users using that Web server lose their sessions. That sucks. It also limits the effectiveness of the load balancer. It can only redistribute *new* users instead of each new request. Ah. Makes sense. I guess reading books *does* help! or b) use a session server (less ugly). And what do you recommend for this? If I had to make the decision today, I'd probably use memcache. mmm. Memcached rocks. I've not seen this approach, so I'm curious (or maybe the proxy acts as a session server, so we're talking about the same thing?). What do you mean the proxy acts as a session server? I don't know of any load balancers who can act as session servers. I wasn't sure exactly what you meant by session server, but now I do. So you are correct. I was thinking perhaps you meant external process that maintains sessions across backends in which case some load balancers do. By the way, this topic is covered nicely in Scalable Internet Architectures and Building Scalable Web Sites. (weird, de ja vu ;) If only I had time to read actual books rather than bug people on the net for answers... Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons Evaluation -Questions
Oh, by the way, do you have a recipe or a URL to a tutorial of Pylons using memcache? Thanks againf On Apr 28, 2:27 am, Shannon -jj Behrens [EMAIL PROTECTED] wrote: On 4/27/07, Cliff Wells [EMAIL PROTECTED] wrote: On Fri, 2007-04-27 at 16:50 -0700, Shannon -jj Behrens wrote: It's the same as everything else. You can add more Web servers. If you use sessions, you'll need to either a) use session stickiness (ugly) Out of curiosity, how is this ugly? This should be mostly handled transparently by the proxy (i.e. sends same sessions to same backend). If one Web server dies, all the users using that Web server lose their sessions. That sucks. It also limits the effectiveness of the load balancer. It can only redistribute *new* users instead of each new request. or b) use a session server (less ugly). And what do you recommend for this? If I had to make the decision today, I'd probably use memcache. I've not seen this approach, so I'm curious (or maybe the proxy acts as a session server, so we're talking about the same thing?). What do you mean the proxy acts as a session server? I don't know of any load balancers who can act as session servers. By the way, this topic is covered nicely in Scalable Internet Architectures and Building Scalable Web Sites. (weird, de ja vu ;) Happy Hacking! -jj --http://jjinux.blogspot.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Upgrading to 0.9.5 - unicode issue
Max Ischenko wrote: I am afraid I can't give a helpful answer but I'll tune in anyway. ;) Thanks for taking the time to chime in. Hmm. The str class doesn't have 'is_file_component' either, does it? No, but the Myghty code has: if type(component) == types.StringType: component = self.fetch_lead_component(component) elif component.is_file_component(): ... If you want to turn it off I believe you need to dig into Paste, not Pylons because it happens there IIRC. The current workaround is to call str() on the param before every call to render() - it looks like I'll have to dig deeper. Robert --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: AJAX how to replace DOM object's value from controller
Thanks Ben. I'll give that approach a try.
ben adam wrote:
the way i do it is by using the webhelpers as follows (using myghty):
from template:
form ..
... your select options, etc...
span id="txtfld"% h.text_field("res", value=initial_val) %/span
/form
% h.observe_form("your_form_with_select",
url="" update="txtfld", with='value') %
and from controller:
new_val = request.params.get('val')
return Response(h.text_field("res", value=new_val))
On Apr 27, 6:15 am, Dan [EMAIL PROTECTED] wrote:
Would someone give an example how I could replace a DOM object from the
controller?
For example, I have an onChange for a select that calls a function
within the controller. The controller function is receiving the
this[this.selectedIndex].value (an integer). I can pass the int value
from the select onChange into the controller, storing it as c.value.
I want the controller to take c.value and update the 'value' of a text
field on the same page without a refresh.
All I can figure out is how to replace an entire element, such as, a
div or the entire input by return render_response('some_template')
Thanks!
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons Evaluation -Questions
Thanks Dan for your answer. I think I would just concentrate on Database clustering and Session storage in databases On Apr 28, 2:07 pm, Dan [EMAIL PROTECTED] wrote: stores all data in the database... even session data. This way, it doesn't matter what web server in your farm takes users requests. They will all ask the database (the db will be your bottleneck) but at least they will *mostly* know how to a --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Upgrading to 0.9.5 - unicode issue
On Apr 28, 2007, at 12:42 AM, Robert Leftwich wrote: I note in the internationalisation document it mentions using a request_settings in the config, which I *don't* have, as the way I read it, you only need to use this dict to turn the coercion on, implying it is off by default. Is there a way to stop this automatic coercion of these params to unicode or do I need to tackle this problem in some other way? In this case, its Routes which is making the route variables unicode objects, there's already a bug report filed for this which is high on my list to optionally disable this feature. HTH, Ben --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Hold my hand, please
I'll definitely check it out now that I have more of an idea of what's going on :) On Apr 22, 6:31 pm, Graham Higgins [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 20 Apr 2007, at 02:28, Heather wrote: So, any takers? Okay, I'll give it a shot. Seehttp://bel-epa.com/wiki/ AnOverviewOfPylons Dunno about acting as groundwork but if it helps you put a couple of the pieces into place, that's good enough. Do let me know if any of it appears especially inarticulate or confusing. Cheers, Graham. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iQCVAgUBRiviYVnrWVZ7aXD1AQK/0wP/UkfcVhb8rfHr0Mq9YeL8Xj0Q1A5GOISv 83hFLweCsKOKWL+pG0oAu7IeNWK3RGwlWUsIqyCjwrC/6Xu3d5fEQrapQIeo72Fw ISD0wVf+XXfQN0e0aG9qksJIW/xgB1G8Dn4IrSFyu1PDh5tmJe+MADQYWL0tXZfA k2Cw+pUnbN8= =d3Z1 -END PGP SIGNATURE- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylons Evaluation -Questions
On Sat, 2007-04-28 at 08:07 -0400, Dan wrote: IMHO. I never implemented memcache, but the distributed memory concept is *not* by itself scalable architecture. The key is session data. Typically (as in default Pylons setup) session data is tied to physical hardware... your web server. To make use of memcache, one would first need to implement scalable architecture, such as the 'share nothing' approach. And this is what Memcached does. Simply store your session data in Memcached. Again, I'm not claiming to be an expert on the 'share nothing' architecture, but my understanding is that 'share nothing' stores all data in the database... even session data. But of course, database doesn't have to mean SQL database. Memcached provides a hash in the sky quite ideal for this type of problem. This way, it doesn't matter what web server in your farm takes users requests. They will all ask the database (the db will be your bottleneck) but at least they will *mostly* know how to access and store data. Again, this is exactly what Memcached is meant to do. Memcached can share data transparently across servers and will typically be *much* faster than database access (and much, *much* easier to implement - distributed databases are not fun [or cheap]). If you'll recall, Memcached was developed to help solve LiveJournal's scalability issues, so it's quite well-tested: http://www.linuxjournal.com/article/7451 Also, if your architecture consists of storing your data in a single database, you will certainly *not* scale beyond a certain point. The database itself will become a bottleneck. In fact, if you read the above article, you'll find that Memcached was in fact developed to help remove load from the LiveJournal databases. So the basic point to my post is that scalable architecture is more about theory than specific tools. The theory behind building scalable web applications is a growing subject in system engineering that I find interesting. You can check a decent article about myspace.com struggles at - http://www.baselinemag.com/article2/0,1540,2084131,00.asp I found the articles on scaling Wikipedia interesting, although I can't find the link to them at the moment... Despite the fact that MySpace obviously scales to a large degree, I put little trust in their technical abilities (they can't even do CSS or search properly). I suspect their scalability is largely derived from millions of dollars in investments rather than actual architecture. *Anyone* can scale if they can throw unlimited money at it ;-) 'memcache' is a tool, when applied to a scalable architecture, could provide performance improvements. Distributed information is a cornerstone of a scalable architecture (sessions are simply information in this context). Memcached provides exactly this and is therefore more than just a tool. It's a foundation point for building a scalable architecture. Of course, for most of us, this is interesting but purely theoretical. For most of the sites I do, the required scalability of a Pylons app consists of running multiple instances of the app behind a load balancer on the same server ;-) Of course, the same problems and solutions apply but on a much smaller scale. Planned right, scaling from multiple processes on a single machine to hundreds of processes across multiple machines really is a matter of scale rather than architecture. Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
Re: Pylon with Apache
On Apr 28, 6:40 am, Cliff Wells [EMAIL PROTECTED] wrote: On Fri, 2007-04-27 at 07:36 -0600, Orr, Steve wrote: What are the advantages/disadvantages pros/cons to doing a proxy instead of just usingmod_python? Typically, proxying is: 1. easier to setup thanmod_python 2. easier to upgrade Python (nomod_python/python version issues) Can you elaborate further on what the specific mod_python/python versions issues are? Note that I ask this to learn what the problems supposedly are and why it may be any more problematic than having to recompile any third party C extension modules for Python which you may have also installed into the Python site packages directory. Such feedback would be useful because although people grumble about this and use it as a reason against using mod_python, those same people never actually come over to the mod_python mailing list to describe the problems so that mod_python may if required be improved or so they may be corrected in their understanding as to how things work. FWIW, here are the specific issues that are already known about in respect of Python version issues when using mod_python. Do your specific problems match one of these or are they something else? First issue is not actually mod_python's fault and arises from fact that most binary Python distributions are not configured with --enable- shared. This means that no shared library is generated for Python, only a static library. The consequence of this is that the static objects have to be embedded within the mod_python.so Apache module. If one later upgrades Python to a newer patch revision of the same major/ minor version but don't correspondingly recompile mod_python or obtain correct new binary version of it, you run the risk of problems because the core Python code you would be running would be older and not match the Python code files and Python C extension modules in the Python installation. Newer versions of mod_python will log warnings in the Apache error log when this problem occurs. The second issue is not completely mod_python's fault but arises from how Python works out where the installed Python code files and extension modules are installed. That is, how it works out what to set sys.prefix and sys.exec_prefix to. The way Python when being initialised does this is to find which 'python' executable is in its PATH and then from that try and work out where the library directory is. Problem with this is if you have multiple Python installations of the same major/minor version number but different patch revision installed in totally different locations, eg., /usr/bin and /usr/local/ bin, it can find the wrong version as the Python version you want may not be that in the PATH for the user Apache is started as. With mod_python only way around this is to set PATH, PATHEXECUTABLE or PATHHOME environment variables in the environment of the user that Apache is started as. What should be done is for new directives to be added to mod_python called PythonExecutable and PythonHome which achieve the same thing so it can be done in Apache configuration instead. This would make it easier to resolve for those small percentage of people who have multiple Python installations on their system. Upgrading to a completely new major/minor version of Python without also using a recompiled version of mod_python will obviously also create lots of problems as it will continue to use an older version of Python, or may not even be able to find the installed mod_python Python code files anymore if old installation of Python was removed. The only other problem area is transitioning to a newer version of Python using the same system. That is, where you might want to be able to run applications using different versions of Python. To do this would mean running two distinct instances of Apache on the same box but with different installations of mod_python/Python. Preferably if doing this one should just perhaps use two different hosts. So except for the two quite specific issues noted above, are your problems perhaps really just an issue of dependency management, something that is going to occur for any software components and not just mod_python itself? Any feedback would be most appreciated so the real problems can be understood. Unfortunately when I have tried to dig into such claims in the past, there is usually dead silence, so can never find out what the real problems are so they can be addressed in mod_python if need be. :-( Graham 3. doesn't require restarting Apache as often 4. just as fast 5. frees you from having to use Apache at all (other proxy solutions are available that are usually faster and lighter than Apache) Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL
Re: Pylons Evaluation -Questions
Cliff Wells wrote: On Sat, 2007-04-28 at 08:07 -0400, Dan wrote: IMHO. I never implemented memcache, but the distributed memory concept is *not* by itself scalable architecture. The key is session data. Typically (as in default Pylons setup) session data is tied to physical hardware... your web server. To make use of memcache, one would first need to implement scalable architecture, such as the 'share nothing' approach. And this is what Memcached does. Simply store your session data in Memcached. Data (you want to save) eventually has to be written to disk. The longer you keep data in memory, the longer you run the risk of losing that data. Memcached is a *tool* to speedup disk access. Again, I'm not claiming to be an expert on the 'share nothing' architecture, but my understanding is that 'share nothing' stores all data in the database... even session data. But of course, "database" doesn't have to mean "SQL database". Memcached provides a "hash in the sky" quite ideal for this type of problem. I somewhat agree. A database is simply a way of storing data on a disk. This can be a flat file w/ XML or a RDMS w/ SQL. A 'hash in the sky' is not a database, even when using virtual memory (a disk), its volatile. This way, it doesn't matter what web server in your farm takes users requests. They will all ask the database (the db will be your bottleneck) but at least they will *mostly* know how to access and store data. Again, this is exactly what Memcached is meant to do. Memcached can share data transparently across servers and will typically be *much* faster than database access (and much, *much* easier to implement - distributed databases are not fun [or cheap]). I'd agree that memcached is faster, as its storing data from disk into memory. RAM is always faster than disk I/O. However, byte-for-byte hard disk drives are cheaper than RAM. If you'll recall, Memcached was developed to help solve LiveJournal's scalability issues, so it's quite well-tested: http://www.linuxjournal.com/article/7451 Thanks for the link. I haven't read it yet, but I plan on it. Also, if your architecture consists of storing your data in a single database, you will certainly *not* scale beyond a certain point. The database itself will become a bottleneck. In fact, if you read the above article, you'll find that Memcached was in fact developed to help remove load from the LiveJournal databases. Agreed. It removes load, speeds up access, but does not eliminate a database (disk). The slower speed of a physical disk will always be the bottleneck. So the basic point to my post is that scalable architecture is more about theory than specific tools. The theory behind building scalable web applications is a growing subject in system engineering that I find interesting. You can check a decent article about myspace.com struggles at - http://www.baselinemag.com/article2/0,1540,2084131,00.asp I found the articles on scaling Wikipedia interesting, although I can't find the link to them at the moment... Despite the fact that MySpace obviously scales to a large degree, I put little trust in their technical abilities (they can't even do CSS or search properly). I suspect their scalability is largely derived from millions of dollars in investments rather than actual architecture. *Anyone* can scale if they can throw unlimited money at it ;-) Agreed 'memcache' is a tool, when applied to a scalable architecture, could provide performance improvements. Distributed information is a cornerstone of a scalable architecture (sessions are simply information in this context). Memcached provides exactly this and is therefore more than just a "tool". It's a foundation point for building a scalable architecture. Somewhat agreed. I give you that Memcached is an important tool, but its still just a tool. A database is a tool. The fiber cable connecting your memcached servers is a tool. Scalable architecture is a system. A system is a set of tools. Again my point is that one needs to understand the big picture and not just say 'wow, I implemented memcached so I'm scalable' Of course, for most of us, this is interesting but purely theoretical. For most of the sites I do, the required scalability of a Pylons app consists of running multiple instances of the app behind a load balancer on the same server ;-) Of course, the same problems and solutions apply but on a much smaller scale. Planned right, scaling from multiple processes on a single machine to hundreds of processes across multiple machines really is a matter of scale rather than architecture. I hope that one of your projects takes off and I can be reading about your growing pains! As for myself, I get paid as a network engineer and I know more Cisco CLI than SQL. I simply enjoy building web applications in Pylons in my
Re: Pylon with Apache
On Sun, 2007-04-29 at 01:42 +, Graham Dumpleton wrote: On Apr 28, 6:40 am, Cliff Wells [EMAIL PROTECTED] wrote: On Fri, 2007-04-27 at 07:36 -0600, Orr, Steve wrote: What are the advantages/disadvantages pros/cons to doing a proxy instead of just usingmod_python? Typically, proxying is: 1. easier to setup thanmod_python 2. easier to upgrade Python (nomod_python/python version issues) Can you elaborate further on what the specific mod_python/python versions issues are? Note that I ask this to learn what the problems supposedly are and why it may be any more problematic than having to recompile any third party C extension modules for Python which you may have also installed into the Python site packages directory. Such feedback would be useful because although people grumble about this and use it as a reason against using mod_python, those same people never actually come over to the mod_python mailing list to describe the problems so that mod_python may if required be improved or so they may be corrected in their understanding as to how things work. I can give you a very specific example as I'll be dealing with it in the next couple of days ;-) A customer has an old Fedora (2 or 3) installation already running lots of stuff under Apache. mod_python (as shipped by Red Hat) is compiled against Python 2.3. Python 2.4 is installed but not used by mod_python. The client now wishes to run a Django application and requires 2.4. Most likely this will mean running two instances of Apache or (more likely), having to run Django as a fastcgi. Personally, I have no problem with running Django as a fastcgi, but it wasn't the client's first choice (and I believe mod_python to be the recommended deployment method for Django). Anyway, I'm not 100% certain there's anything that can be done by the mod_python project to resolve this particular type of issue (unless perhaps it would be possible to run multiple mod_python compiled against different versions of Python on the same Apache instance, but even then, we're still talking about lots of configuration, compiling, etc that simply aren't required for a proxied application). In short, the looser coupling between the webserver and the application that proxying provides gives all the usual benefits one might expect over a fully integrated solution and frankly, there isn't much downside as far as I can tell. The only other problem area is transitioning to a newer version of Python using the same system. That is, where you might want to be able to run applications using different versions of Python. To do this would mean running two distinct instances of Apache on the same box but with different installations of mod_python/Python. Preferably if doing this one should just perhaps use two different hosts. And this is my point: with proxying this isn't even remotely an issue. So except for the two quite specific issues noted above, are your problems perhaps really just an issue of dependency management, something that is going to occur for any software components and not just mod_python itself? It occurs with any tightly coupled software system. Sometimes a tight coupling brings benefits that outweigh the issues you incur, but in this case I simply don't see the benefit of tightly integrating with the webserver. Performance benefits are usually negligible to non-existent over fastcgi or proxying and frankly I'm not sure what other benefits might even be claimed. Any feedback would be most appreciated so the real problems can be understood. Unfortunately when I have tried to dig into such claims in the past, there is usually dead silence, so can never find out what the real problems are so they can be addressed in mod_python if need be. :-( Well, here you have it ;-) Regards, Cliff --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-discuss@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~--~~~~--~~--~--~---
