If you want easy performance improvement (easy is relative here) you can try to use pypy interpreter or ironpython, ironpython don't have GIL, pypy suppose to execute 5x faster the same python code (http://speed.pypy.org/)... Other interpreters : http://docs.python-guide.org/en/latest/starting/which-python/
The problem that happen often is that dependencies are not pypy "compliant". But depending of the app you have wrote (if few dependency) it may be a proper path for you... Good luck Richard On Fri, Feb 10, 2017 at 10:25 AM, Ron Chatterjee <[email protected]> wrote: > Thank you for explaining Richard. That's very nice of you. May be we can > have a module that makes some of web2py code executable for faster > processing. Something for someone to look at may be. > > On Monday, February 6, 2017 at 4:39:49 PM UTC-5, Richard wrote: >> >> I guess partly for the same reason we can't make cpython faster (GIL - >> https://wiki.python.org/moin/GlobalInterpreterLock)... But not only for >> this reason of course. But let ask the question differently, why is >> clienteside app faster? You move computer processing load to client in many >> part, you reduce the size of the data that have to move back and forth as >> you only have to transmit json instead of the whole DOM. Also, web2py can >> be really fast, it all depends how you use it. For instance if you don't >> need auth on every page you can avoid a lot of queries to the backend. The >> same is true, you can use auth.has_membership() which triggers many queries >> or you can initialize a varibale that you can cache for the duration of the >> session. You use to check membership against this cached variable, that way >> you avoid many queries to the backend which is most probably the bottleneck >> of any application. The drawback is that you can't modify users privileges >> once they are connected without maintaining the the cache variable up to >> date (which is not that difficult you just have to make sure you update it >> each time you manipulate membership) or ask them to logout and login again >> when you modify their membership. >> >> At some point if you really need more speed and you already have make it >> sure your app is lean and properly tuned, you have to look on the side of >> replication and redundancy... >> >> You also have to gave a look at "model-less" app paradigm which involve >> moving models definition into module which have some drawback. Before, that >> make sure you don't defined any function into you models files, since the >> code defined there is execute at each request. You can also activate lazy >> table (http://web2py.com/books/default/chapter/29/06/the-database- >> abstraction-layer#Lazy-Tables--a-major-performance-boost). >> >> Also, notice that SSL has it pound in the balance... I had issue recently >> since Chrome start to trigger error for certificate using SHA-1 hashing >> key... I had to read and create a new private key... The out come despite >> having a new secure certificate that pass Chrome validation was that using >> Elliptic Curve key (https://www.digicert.com/ecc.htm) ECDSA 256 bits >> that give an ssl certificate as secure as RSA 2048 bits (at least it said >> to be as secure) which make ssl data encryption much faster. I wasn't able >> to properly benchmark the speed improvement, but it seems as much as 25% >> faster them my previous certficate. >> >> Finally, Massimo is looking to find a solution that will allow us develop >> client side app within web2py with help of ractivejs/vuejs (vuejs seems >> much easier to pickup than ractive and much more well supported so I guess >> it will win the battle). He had propose proof of concept in the past : >> >> https://github.com/mdipierro/w3 >> >> But until now there were no traction from core developpers. Basically >> because they are buzzy fixing issues and improving stuff (and speed : >> https://groups.google.com/d/msg/web2py-developers/j6uxYMxo >> 5qI/OQPEpJ5CWIoJ), porting web2py over python 3 ( >> https://github.com/web2py/web2py/issues/1353) which turn to be a big >> undertake as we didn't have a new release for months now. >> >> From what I do understand, and I didn't have much time to follow and >> contribute much recently, we are trying to make web2py build python 3 >> compliant then we will undertake others challenges. >> >> In either way, once we will have web2py/web3py we will have to rewrite >> (your are not forced because you will still be able to use python 2) our >> apps, so Massimo is planning to seize the opportunity to break the promise >> of backward compatibility and introducing client side goodies into web2py. >> At least it's my understanding of what is going on rigth now. >> >> Have a good day! >> >> Richard >> >> >> On Mon, Feb 6, 2017 at 11:23 AM, Ron Chatterjee <[email protected]> >> wrote: >> >>> Why can't we make web2py faster ? >>> >>> >>> On Thursday, February 2, 2017 at 9:36:34 AM UTC-5, mcm wrote: >>>> >>>> >>>> I agree nice and could be useful in speedy services and we should see >>>> if it can be used in front of web2py. >>>> >>>> But it is more important for the long term that we start to think about >>>> leveraging HTTP/2 soon >>>> >>>> Il giorno mercoledì 1 febbraio 2017 16:23:46 UTC+1, Anthony ha scritto: >>>>> >>>>> On Wednesday, February 1, 2017 at 4:54:31 AM UTC-5, Massimo Di Pierro >>>>> wrote: >>>>>> >>>>>> I just discovered this: >>>>>> >>>>>> https://github.com/squeaky-pl/japronto >>>>>> >>>>>> I am impressed. I like the speed and the semantics. >>>>>> >>>>> >>>>> Seems interesting, though the benchmarks seem a bit contrived. It does >>>>> so well because it uses HTTP pipelining with a workload designed to get >>>>> maximum benefit from pipelining (24 identical and fast pipelined requests >>>>> requiring no work in Python). Since most browsers do not support HTTP >>>>> pipelining by default, and most workloads would not benefit so much from >>>>> pipelining, this has little real world value. On the other hand, it does >>>>> *not >>>>> *support HTTP/2 with request multiplexing, which *is *supported by >>>>> most browsers and would likely have real benefits for more typical >>>>> workloads. >>>>> >>>>> Regarding the API, how do you think it compares with Sanic >>>>> <http://sanic.readthedocs.io/en/latest/index.html> (also based on >>>>> uvloop and allowing async handlers)? >>>>> >>>>> Anthony >>>>> >>>> -- >>> Resources: >>> - http://web2py.com >>> - http://web2py.com/book (Documentation) >>> - http://github.com/web2py/web2py (Source code) >>> - https://code.google.com/p/web2py/issues/list (Report Issues) >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "web2py-users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > Resources: > - http://web2py.com > - http://web2py.com/book (Documentation) > - http://github.com/web2py/web2py (Source code) > - https://code.google.com/p/web2py/issues/list (Report Issues) > --- > You received this message because you are subscribed to the Google Groups > "web2py-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
