On Thursday, July 2, 2015 at 8:10:03 PM UTC+5:30, Edward Boyer wrote: > > Good Morning > > I am wondering if anyone has deployed Trytond to AWS and performed load > testing in that environment. >
Yes. More than 90% of the implementations I have done have been on Amazon Web Services. Initially we deployed to EC2 instances directly, while currently we deploy to EC2 but as docker containers. > I am considering using Trytond as the backend to a very large and complex > retail operation. > Tryton scales "out" really well. You could have it work behind an ELB and distribute the load over multiple EC2 instances in an auto scaling group. > > I know that this testing depends on database engine tuning, and numbers of > server,CPUs, threads, and concurrent users. > We use RDS at the moment for Postgres. With a little tuning of work_mem, random_page_cost (depending on IOPS of disk) and max_connections it could scale out. However, we have not managed to scale the database up or down without downtime - so we prefer to have an RDS instance which is larger than required. > I am just looking for a brief insight on real world experiences with > Trytond and any challenges ahead of time. > The default trytond (daemon script) is not well suited for scaling out. We have a WSGI script which is launched by gunicorn [1]. The Tryton cron runs as a thread of the trytond daemon. Not the best way to have crons at web scale. We are currently considering using celerybeat as an alternative. For a really large implementation, you would need something that is distributed and fault tolerant like chronos by AirBnB [2]. > > We are considering deployment of a large ecommerce (10000+ hits per day) > and 100+ stores with 50 POS users each store (so 5000 users active but not > concurrent). > Not sure what you are going to use for eCommerce, but with nereid we made all GET requests start readonly cursors. This made us write the APIs better which ensured that there were no waiting locks. This might not initially seem relevant but, tryton uses repeatable-read [3] isolation which is a very strict level of transaction isolation for an ecommerce system. We also had to make order processing asynchronous because it is both blocking and slow. If shipments are created and assigned on order processing, this could also result in locks causing rollbacks. So this is important for both eCommerce and POS. Nereid eCommerce leaves orders in the confirmed state, while the POS orders are processed by a separate process. [1] http://gunicorn.org/ [2] http://nerds.airbnb.com/introducing-chronos/ [3] http://www.postgresql.org/docs/9.3/static/transaction-iso.html Thanks & Regards Sharoon Thomas President & CEO Fulfil.IO Inc.
