SpringBoot wolny czas uruchamiania

Witam,
czy ktoś jest w stanie wyjaśnić dlaczego prosty projekt spring boot jpa (https://github.com/MirekSz/spring-boot-slow-startup) uruchamia się tak wolno (na moim laptopie ponad 60 sekund). Oczywiście znajduję się tak 2000 prostych encji z dwoma polami oraz 4000 serwisów bez metod/wstrzyknieć. Struktury są po to aby zasymulować średniej wielkości projekt

Ponieważ musi być stworzony cały model mapowania oraz wszystkie beany. 60 sekund to niezły wynik. Serio.

edit: u mnie wstawało 40 sek.

Kurcze to sławo bo odpalenie testu integracyjnego też będzie tyle trwało :-(.
Kurcze 6000 klas to nie jakaś masakra nie widze powodu dla którego to ma tyle trwać. Jak robie test bez Spring to wczytanie 6000 klas + stworzenie z ich instancji to 4 sekundy a nie 60

poza tym encje i serwisu są banalne

Samo tworzenie, wywołanie new, jest banalne. Jednak masz na to całą otoczkę zaczynając od rejestracji w kontekście poprzez inspekcję, aż na generowaniu proxy kończąc.

edit: jak na boota 6k klas to duża aplikacja.

edit: u mnie wstawało 40 sek.

Ponieważ musi być stworzony cały model mapowania oraz wszystkie beany. 60 sekund to niezły wynik. Serio.
Ja bym problemy szukał gdzie indziej (znaczy wydaje mi się że masz trochę racji, ale).

bo paczajcie, co ma @SpringBootApplication pod spodem,

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@Configuration
@EnableAutoConfiguration
@ComponentScan

rzuciłem na okiem na googla, i ludzie faktycznie mają problem z tym component-scanem - nie wgłębiałem się, nie wiem dokładnie co on robi (może jakieś cache, albo ten algorytm jest po prostu głupi i nie wydajny(konczyl go moze ktos po agehu DD:D #trolo)). Ale kiedy wskazałem mu te dwa pakiety z serwisem i modelem, czas spadł do

Weź sprawdź ile u ciebie będzie wstawał z taką konfiguracją

@SpringBootApplication(exclude = ComponentScan.class)
@ComponentScan(basePackages = "[java.hello.service, java.hello.model, java.hello]")

Mozna by się było pokusić o mały heapdump tego cuda zaraz po starcie żeby popatrzeć jak ładnie component-scan robi brzydkie rzeczy :)

EDIT:

to jednak nie to :( z podaniem poprawnego packaga do scanowania czas jest na takim samym poziomie.

Przecież to jest całkiem niezły czas, jak na taką skalę projektu. Przecież zwykle przy takiej złożoności projekt rozbija się na mniejsze, niezależne moduły obecnie.

Pracowałem w jednym z największych projektów IT w Polsce i nie sądzę, by poszczególne moduły miały większą złożoność. A kobyła wstawała z 5-10 minut (i zżerał 6gb ramu na start).

Twoja aplikacja wstaje mi w czasie którym podałem wyżej i tworzy 4064 beanów (tyle pokazuje context)
Spring boot z błędnym component scanem wstaje mi 8.608 seconds - tworzy 64 beany
Aplikacja postawiona z pure xml'a wstała w** 5.503 ** stworzyła 4009 beanów

Jak się komuś chce może sprawdzić ile syfu dodaje Spring Boot na starcie :)

EDIT:

To jest różnica w beanach (głównie te związane z persystencją)

org.springframework.boot.autoconfigure.AutoConfigurationPackages
org.springframework.boot.autoconfigure.PropertyPlaceholderAutoConfiguration
org.springframework.boot.autoconfigure.condition.BeanTypeRegistry
propertySourcesPlaceholderConfigurer
org.springframework.boot.autoconfigure.jmx.JmxAutoConfiguration
mbeanExporter
objectNamingStrategy
mbeanServer
org.springframework.boot.autoconfigure.aop.AopAutoConfiguration$JdkDynamicAutoProxyConfiguration
org.springframework.aop.config.internalAutoProxyCreator
org.springframework.boot.autoconfigure.aop.AopAutoConfiguration
org.springframework.boot.autoconfigure.transaction.jta.JtaAutoConfiguration
spring.jta.CONFIGURATION_PROPERTIES
org.springframework.boot.context.properties.ConfigurationPropertiesBindingPostProcessor
org.springframework.boot.context.properties.ConfigurationPropertiesBindingPostProcessor.store
org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration$JdbcTemplateConfiguration
jdbcTemplate
namedParameterJdbcTemplate
org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration$NonEmbeddedConfiguration
dataSource
org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration$DataSourceInitializerConfiguration
dataSourceInitializer
org.springframework.boot.autoconfigure.jdbc.metadata.DataSourcePoolMetadataProvidersConfiguration$TomcatDataSourcePoolMetadataProviderConfiguration
tomcatPoolDataSourceMetadataProvider
org.springframework.boot.autoconfigure.jdbc.metadata.DataSourcePoolMetadataProvidersConfiguration
org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration
spring.datasource.CONFIGURATION_PROPERTIES
dataSourceInitializerPostProcessor
org.springframework.boot.autoconfigure.orm.jpa.HibernateJpaAutoConfiguration
transactionManager
jpaVendorAdapter
entityManagerFactoryBuilder
entityManagerFactory
spring.jpa.CONFIGURATION_PROPERTIES
dataSourceInitializedPublisher
org.springframework.boot.autoconfigure.context.ConfigurationPropertiesAutoConfiguration
org.springframework.boot.autoconfigure.dao.PersistenceExceptionTranslationAutoConfiguration
persistenceExceptionTranslationPostProcessor
org.springframework.boot.autoconfigure.data.jpa.JpaRepositoriesAutoConfiguration
org.springframework.data.repository.core.support.RepositoryInterfaceAwareBeanPostProcessor
emBeanDefinitionRegistrarPostProcessor
jpaMappingContext
jpaContext
customerRepository (TEN JEDEN NIE :) ALE JUZ MI SIE NIE CHCIAŁO USUWAĆ, WĄTPIE ŻE TO WPŁYNĘŁO NA TEN TEST JAKOŚ BARDZO :D )
org.springframework.transaction.annotation.ProxyTransactionManagementConfiguration
org.springframework.transaction.config.internalTransactionAdvisor
transactionAttributeSource
transactionInterceptor
org.springframework.transaction.config.internalTransactionalEventListenerFactory
org.springframework.boot.autoconfigure.jdbc.DataSourceTransactionManagerAutoConfiguration$TransactionManagementConfiguration
org.springframework.boot.autoconfigure.jdbc.DataSourceTransactionManagerAutoConfiguration
org.springframework.boot.autoconfigure.transaction.TransactionAutoConfiguration
transactionTemplate

ale co to za test wymagający całej aplikacji? Taki to się robi na postawionej testowej instancji. A aplikacje dzieli się na moduły żeby można było postawić fragment i testować integrację konkretnych modułów.

Jeśli chodzi o aplikacje to tak mamy podział na moduły (400 modułów mavena). Ale testy integracyjne cross modułowe mają największą wartość i teraz przypuścmy, że robie test integracyjny modułu A, on do swojej pracy potrzebuje modułu B, znów B potrzebuje C itp.

Czyli okazuje się ze uruchamiając context springa potrzebuje wszystkie moduły bo nie wiadomo co z czego korzysta. Znów mockowanie nieraz odpada bo skoro odwojue się do modułu B aby on założył wpis w bazie zwrócił ID i ja go ustawiam jako swój FK to nie da się tego zamokować bo poleci błąd bazy

raz miałem taka śmieszną akcję ze spring bootem, ze na windowsie startował (to byl taki serwis z 1 restem, prawie nic) w porządku w ok 5-10 sekund?, ale na CentOS zajmowało mu to ok 10 minut.
Problemem było generowanie SecureRandom i przez jedną zmienną w JRE zajmowało to kilka minut. On to robił na podstawie chyba czasu komputera, a gdyby robił na podstawie takiego pliku to zajęłoby mu to krótej. I faktycznie zajęło, ale szczegółów nie podam bo nie pamietam więcej ;-)

jak dla mnie 15 sekund to spoko. Przy okazji można od razu zrobić forumowy ranking kto ma najwydajniejszą jave na kompie:

1. miejsce -> @maryiusz 11.615 sekund (ciekawe jaki to komputer)

2. miejsce -> @ja (laptop Lenovo ztiuningowany)
   

3. miejsce -> @Koziołek 40 sekund

4. miejsce -> @Szczery 60 sekund

5. miejsce -> @datdata 5-10 minut

6. miejsce -> @azalut CentOS zajmowało mu to ok 10 minut.

2 ostatnie miejsca trochę suabe wyniki. a i @Shalom nie podał wyniku.

W domu:

2016-05-25 1843.810 INFO 7526 --- [main] hello.Application: Started Application in 15.148 seconds (JVM running for 15.581)

W nowej pracy* myślę, że zszedłbym poniżej 10s spokojnie.

*Chwalenie się sprzętem: http://www.pcconnection.com/product/lenovo-thinkpad-w541-core-i7-4940mq-3.1ghz-32gb-512gb-dvd-ac-bt-fr-wc-9c-xr-k2100m-15.5-3k-w7p64-w8.1p/20eg000hus/18446895