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/j6uxYMxo5qI/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 <achatterjee...@gmail.com> 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 web2py+unsubscr...@googlegroups.com. > 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 web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
