Speeding up ORMReload()

[Thomas Messier]

I wanted to check with others who have experience with working with a fairly large number of persistent objects in ORM if using ORMReload() is supposed to be slow. When I say slow, I mean 30+ seconds at times. And when I say large number, in my case I have around 250 persistent CFCs with many relationships between them. Because I'm still figuring things out and making a bunch of changes, I have to call ORMReload() fairly often, and it takes a while to run. Sometimes the app times out, and I've gotten the "Another CacheManager with same name already exists in the same VM" error. Sometimes I end up restarting ColdFusion to get rid of the error. I wouldn't be surprised if it does take that long to run this, but I was wondering if there could be anything specific that makes things slow or any way to speed it up while in development. FYI, the reason I have this many CFCs to start with is that I'm converting an existing app, so I did some code generation to get a bunch of CFCs already somewhat configured and then I can tweak them as I go along. Maybe the best thing would be to slowly add them manually instead so at least at the beginning when I have only a handful of CFCs things will be fast?

[Dan Vega]

What db are you using? 

Thank You
Dan Vega
dan...@gmail.com
http://www.danvega.org/

On Tue, May 22, 2012 at 9:46 AM, Thomas Messier <thomas....@gmail.com> wrote:

I wanted to check with others who have experience with working with a fairly large number of persistent objects in ORM if using ORMReload() is supposed to be slow. When I say slow, I mean 30+ seconds at times. And when I say large number, in my case I have around 250 persistent CFCs with many relationships between them. Because I'm still figuring things out and making a bunch of changes, I have to call ORMReload() fairly often, and it takes a while to run. Sometimes the app times out, and I've gotten the "Another CacheManager with same name already exists in the same VM" error. Sometimes I end up restarting ColdFusion to get rid of the error. I wouldn't be surprised if it does take that long to run this, but I was wondering if there could be anything specific that makes things slow or any way to speed it up while in development. FYI, the reason I have this many CFCs to start with is that I'm converting an existing app, so I did some code generation to get a bunch of CFCs already somewhat configured and then I can tweak them as I go along. Maybe the best thing would be to slowly add them manually instead so at least at the beginning when I have only a handful of CFCs things will be fast?

--
You received this message because you are subscribed to the Google Groups "cf-orm-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/cf-orm-dev/-/cFc504oX3mcJ.
To post to this group, send email to cf-or...@googlegroups.com.
To unsubscribe from this group, send email to cf-orm-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cf-orm-dev?hl=en.

[Thomas Messier]

SQL Server

[John Whish]

Are you using, this.ormsettings.cfclocation to make sure only the "entity" cfcs are indexed, also adding this.ormsettings.dialect = "MicrosoftSQLServer" will speed it up a tiny bit, but probably not very much.

Do you cfcs also mention the column names for joins or do you let CF find the foreign keys set?

Also 250 cfcs is a lot, so even just to do a directory search and read the meta data is going a bit of time to run.

- John

[Sam Farmer]

Thomas,

I had a similar situation...about 200 entities in a 1,200 table database. The slowdown was caused mainly by this setting in ormsettings:

useDBForMapping 

When true that will first get metadata about all tables which takes time. We set that to false and made sure each property had an ormtype and the ormreload time is down to 2-4 seconds.

Cheers,

Sam

[Thomas Messier]

Yes, I am using cfclocation and I do have the dialect set. I do also supply the fkcolumn on relationships.

On Tuesday, May 22, 2012 10:01:42 AM UTC-4, John Whish wrote:

Are you using, this.ormsettings.cfclocation to make sure only the "entity" cfcs are indexed, also adding this.ormsettings.dialect = "MicrosoftSQLServer" will speed it up a tiny bit, but probably not very much.

Do you cfcs also mention the column names for joins or do you let CF find the foreign keys set?

Also 250 cfcs is a lot, so even just to do a directory search and read the meta data is going a bit of time to run.

- John

On 22 May 2012 14:51, Thomas Messier wrote:

SQL Server

On Tue, May 22, 2012 at 9:49 AM, Dan Vega wrote:

What db are you using? 

Thank You
Dan Vega
http://www.danvega.org/

On Tue, May 22, 2012 at 9:46 AM, Thomas Messier wrote:

I wanted to check with others who have experience with working with a fairly large number of persistent objects in ORM if using ORMReload() is supposed to be slow. When I say slow, I mean 30+ seconds at times. And when I say large number, in my case I have around 250 persistent CFCs with many relationships between them. Because I'm still figuring things out and making a bunch of changes, I have to call ORMReload() fairly often, and it takes a while to run. Sometimes the app times out, and I've gotten the "Another CacheManager with same name already exists in the same VM" error. Sometimes I end up restarting ColdFusion to get rid of the error. I wouldn't be surprised if it does take that long to run this, but I was wondering if there could be anything specific that makes things slow or any way to speed it up while in development. FYI, the reason I have this many CFCs to start with is that I'm converting an existing app, so I did some code generation to get a bunch of CFCs already somewhat configured and then I can tweak them as I go along. Maybe the best thing would be to slowly add them manually instead so at least at the beginning when I have only a handful of CFCs things will be fast?

--
You received this message because you are subscribed to the Google Groups "cf-orm-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/cf-orm-dev/-/cFc504oX3mcJ.
To post to this group, send email to cf-or...@googlegroups.com.

To unsubscribe from this group, send email to cf-orm-dev+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/cf-orm-dev?hl=en.

--
You received this message because you are subscribed to the Google Groups "cf-orm-dev" group.
To post to this group, send email to cf-or...@googlegroups.com.

To unsubscribe from this group, send email to cf-orm-dev+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/cf-orm-dev?hl=en.

--
You received this message because you are subscribed to the Google Groups "cf-orm-dev" group.
To post to this group, send email to cf-or...@googlegroups.com.

To unsubscribe from this group, send email to cf-orm-dev+unsubscribe@googlegroups.com.

[Thomas Messier]

That makes a lot of sense. And should be pretty easy for me to generate the ormtype for all properties. I'll give this a try and report back. Thanks all for the quick answers!

On Tuesday, May 22, 2012 10:03:08 AM UTC-4, Sam Farmer wrote:

Thomas,

I had a similar situation...about 200 entities in a 1,200 table database. The slowdown was caused mainly by this setting in ormsettings:

useDBForMapping 

When true that will first get metadata about all tables which takes time. We set that to false and made sure each property had an ormtype and the ormreload time is down to 2-4 seconds.

Cheers,

Sam

On Tue, May 22, 2012 at 8:51 AM, Thomas Messier wrote:

SQL Server

On Tue, May 22, 2012 at 9:49 AM, Dan Vega wrote:

What db are you using? 

Thank You
Dan Vega
http://www.danvega.org/

On Tue, May 22, 2012 at 9:46 AM, Thomas Messier wrote:

I wanted to check with others who have experience with working with a fairly large number of persistent objects in ORM if using ORMReload() is supposed to be slow. When I say slow, I mean 30+ seconds at times. And when I say large number, in my case I have around 250 persistent CFCs with many relationships between them. Because I'm still figuring things out and making a bunch of changes, I have to call ORMReload() fairly often, and it takes a while to run. Sometimes the app times out, and I've gotten the "Another CacheManager with same name already exists in the same VM" error. Sometimes I end up restarting ColdFusion to get rid of the error. I wouldn't be surprised if it does take that long to run this, but I was wondering if there could be anything specific that makes things slow or any way to speed it up while in development. FYI, the reason I have this many CFCs to start with is that I'm converting an existing app, so I did some code generation to get a bunch of CFCs already somewhat configured and then I can tweak them as I go along. Maybe the best thing would be to slowly add them manually instead so at least at the beginning when I have only a handful of CFCs things will be fast?

--
You received this message because you are subscribed to the Google Groups "cf-orm-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/cf-orm-dev/-/cFc504oX3mcJ.
To post to this group, send email to cf-or...@googlegroups.com.

To unsubscribe from this group, send email to cf-orm-dev+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/cf-orm-dev?hl=en.

--
You received this message because you are subscribed to the Google Groups "cf-orm-dev" group.
To post to this group, send email to cf-or...@googlegroups.com.

To unsubscribe from this group, send email to cf-orm-dev+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/cf-orm-dev?hl=en.

--
You received this message because you are subscribed to the Google Groups "cf-orm-dev" group.
To post to this group, send email to cf-or...@googlegroups.com.

To unsubscribe from this group, send email to cf-orm-dev+unsubscribe@googlegroups.com.

[Cameron Childress]

On Tue, May 22, 2012 at 9:46 AM, Thomas Messier <thomas....@gmail.com> wrote:

Sometimes the app times out, and I've gotten the "Another CacheManager with same name already exists in the same VM" error. 

Side note - you may be able to wrap that ORMReload() call in a named lock to prevent this... I wouldn't do it in production, but then I would avoid ORMReload() in production.

-Cameron

--
Cameron Childress
--
p:   678.637.5072

im: cameroncf

facebook | twitter | google+

[Thomas Messier]

So I've already implemented this and it's beautiful, the reload is now super fast, like not even one second. Thanks a bunch Sam, this is gonna save me tons of time!

-TM

[Thomas Messier]

OK, good to know. If I run into it again I'll give it a try, but I have a feeling it won't happen anymore. The problem seems linked to timeouts, so with the ormreload now being super fast, application won't timeout anymore.

On Tuesday, May 22, 2012 11:19:54 AM UTC-4, Cameron Childress wrote:

[Marc Esher]

Thomas,

did you measure whether the biggest impact came from the
useDBForMapping setting, or from the addition of ormType?

Marc

> --
> You received this message because you are subscribed to the Google Groups
> "cf-orm-dev" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/cf-orm-dev/-/tS8JMYSQaF8J.

>
> To post to this group, send email to cf-or...@googlegroups.com.
> To unsubscribe from this group, send email to

> cf-orm-dev+...@googlegroups.com.

[Thomas Messier]

It's definitely useDBForMapping, because if you set it to false the system has to inspect all tables/columns to figure out types as Sam explained. But they go hand in hand. Chances are you can't just set useDBForMapping to false and have everything speed up and work properly because your ORM will have no clue what data type to use for the different fields. So you need to do both. The results are well worth it, this thing is just zipping away now!

On Tuesday, May 22, 2012 11:53:25 AM UTC-4, Marc Esher wrote:

Thomas,

did you measure whether the biggest impact came from the
useDBForMapping setting, or from the addition of ormType?

Marc

> cf-orm-dev+unsubscribe@googlegroups.com.

[Thomas Messier]

Oops, I said "if you set it to false the system has to inspect" when I meant "if you set it to true the system has to inspect".

[Wesley Hampton]

My goodness, adding useDBForMapping = false to my config saved me so much time. I was having such a headache during ReInit using ColdBox (so slow and timeouts) until I found this gem of a thread. Thanks guys -- where's the donate a beer button??

Wes

[Martie Henry]

I just wanted to let folks know that years later, this thread helped me tremendously.

A HUGE thank you to Sam Farmer.

On an OrmReload or application restart, my 60 table/persistent cfc database was taking over 5 minutes to load. In fact, I had to add cfsetting requesttimeout="20000" for it to work at all.

All of my orm persistent cfcs already specified each of the orm types. There are no relationships specified, because ColdFusion orm does not support how our relationships are set up [we do not use the primary key, but a ColdFusion UUID plus a boolean Active]

Wasn't aware of the useDBForMapping setting, which evidently defaults to true.

When I added useDBForMapping = false to my Application.cfc, WHAM, my load now takes less than a minute.

Again, many thanks to everyone in this thread.

[Sam Farmer]

Glad to help.

Sent from my iPhone

> --
> You received this message because you are subscribed to the Google Groups "cf-orm-dev" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to cf-orm-dev+...@googlegroups.com.

> To post to this group, send email to cf-or...@googlegroups.com.

> Visit this group at http://groups.google.com/group/cf-orm-dev.
> For more options, visit https://groups.google.com/d/optout.