Hi there - I must give you our feedback too.
I fully agree with Dave: transfer is a great framework but it works well for small web sites or applications. It was a *NIGHTMARE* for us with a 160 objets model with some memory leaks... Our situation is not fully stabilized yet but our application survives more than one week and we live in peace with an auto restart each week (at the worst moment the application crashed every 2 or 3 hours...). Transfer is not fully responsible of these problems there was some bad usage also, but it opens doors to this kind of situation. Take note about the "pluggable" cache branch you'll find on the SVN, it's base on EHCache. We run this version more reliable and it should allow you to run on a cluster. The second point is CF9 includes Hibernate and we start our new projects base on this ORM and we intend to migrate existing applications too. Mark coded a *very* great framework, I love transfer, but until CF9 is out there is no sense to go with transfer anymore. This is only my point of view. Aurelien On 7 déc, 03:52, Dave <[email protected]> wrote: > Long story short; Transfer gives you a great programming model at the > expense of performance and scalability. > > I did some tests a year ago which showed that decorated transfer > objects were between 4 and 60 times slower than Hibernate/CF9 or hand- > coded DAO objects, depending on the type of test. > > These tests were against our specific environment, and if you are > contemplating using Transfer I suggest you do your own tests against > your proposed environment. Search for thread titled "CF9 performance > boost?" for more info on my results. > > The bigger limit to scalability is cache management. Transfers cache > is not distributed. > > Cache sizes >8-10gig on a single server become very hard to manage and > will often cause the server to crash due to the overhead of transfer > and the JVM’s internal cache management. > > The only solution we had to this problem is to check the size of the > cache every minute or so, and once it exceeds a certain value we dump > the entire cache and start again. As you can imagine, dumping your > entire cache isn’t great for scalability. > > Whilst transfer is great for small sites, you might find you come up > against hard-limits to scalability where throwing more kit at the > problem does not help. > > We are a very large transfer shop, slowly migrating to hard-coded DAO > objects, however I cannot give any more info than that. > > Dave > > On Dec 7, 2:57 am, Neo <[email protected]> wrote: > > > > > > > > > Hello: > > > I'm a relatively new user of transfer ORM. > > > One of my goals at my current job is to evaluate transfers' ability to > > scale in a high transactional application. > > > Does anyone have reliable statistics that demonstrates performance > > thresholds or the like? > > > I know that there are several factors that can affect performance > > (hardware, how transfer is configure, etc). > > > However, in my case, my assumptions would be that all aspects of the > > application are optimized. > > > In addition, does anyone have information on companies that currently > > use transfer-orm? > > Stats of each company would be useful, but names would help too. > > > Any information relating to the above-mentioned topics is very much > > appreciated. > > > Thank you, Neo -- Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer Try out the new Transfer ORM Custom Google Search: http://www.google.com/cse/home?cx=002375903941309441958:2s7wbd5ocb8 You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en
