3 ms·
I'm the project lead of Crowdcrafting (powered by PyBossa) with 21.7k lines of code written in Python. Our stack in Crowdcrafting is fairly simple in terms of
by teleyinex 12y ago
I'm the project lead of Crowdcrafting (powered by PyBossa) with 21.7k lines of code written in Python.
Our stack in Crowdcrafting is fairly simple in terms of hardware (we've two servers with 2 GB of RAM each and only 2 cores, while the DBs have 4 GB of RAM with 4 cores). You can read more about it here: http://daniellombrana.es/blog/2015/02/10/infrastructure.html http://daniellombrana.es/blog/2015/02/10/infrastructure.html
In my experience the problems that we've had are always related about how we develop, not the technologies. One of our ways of solving problems is avoiding increasing the resources of the hardware as it will "hide" the real issues of your software. Thanks to this approach we were able to store more than 1.5 records per second over a period of 24 hours in 2014 with a DB running on less than 1GB of RAM and our servers with 2GB of them. It worked really well! (Actually after that our provider called us to expend more on our hardware).
Our platform is designed to scale horizontally without problems. We use a very simple set of technologies that are widely used, and we try to use very simple libraries all the time. This has proven to us to be very efficient and we've managed to scale without problems.
We heavily test and analyze our software. This is mandatory. We've almost 1000 tests written covering 97% of our code base. We also analyze the quality of our code using a third party service and we've an score of 93%, and this helps people to help sending patches and new developers joining the platform.
Right now our servers are responding in less than 50ms in average, and we are not even using Varnish (check out this blog post: http://daniellombrana.es/blog/2015/03/05/uwsgi.html http://daniellombrana.es/blog/2015/03/05/uwsgi.html). Thus, yes Python is a good language, it can scale, and if you usually have a problem it will be basically in your own code. Hence debug it!
Cheers,
Daniel