spring mvc - медленная работа ajax + 500 мс за каждый звонок - PullRequest
0 голосов
/ 08 марта 2011

Мы работаем над проектом Spring mvc и испытываем некоторые проблемы с производительностью наших вызовов ajax. Каждый звонок занимает минимум 500мс :(. У кого-то была эта проблема раньше? Есть ли хороший способ профилировать эту проблему?

Мы используем:

  • пружинный мвк
  • пружина безопасности
  • Спящий режим 3.6.1
  • кот 7
  • JQuery 1.4.4

После использования профилировщика Spring Insight мы обнаружили, что это проблема:

    try {
        HibernateTemplate ht = new HibernateTemplate(sf);
        List<Route> r = ht.findByNamedParam("select r from Route r inner join r.carPoolers as carPooler where (( r.owner.id  = :userid ) or ( carPooler.user.id = :userid )) AND r.id =:routeID", new String[]{"userid", "routeID"} , new Object[]{ u.getId() , id});
        if (r.size() == 1) {
            return r.get(0);
        } else {
            return null;
        }
    } catch (DataAccessException ex) {
        LogFactory.getLog(RouteRepository.class).fatal(ex);
        return null;
    }

Этот запрос занимает минимум 460 мс ...

SELECT ROUTE0_.ID AS ID4_, ROUTE0_.ARRIVALTIME AS ARRIVALT2_4_, 
    ROUTE0_.CAR_ID AS CAR13_4_, ROUTE0_.DATE AS DATE4_, 
    ROUTE0_.DAYOFWEEK AS DAYOFWEEK4_, ROUTE0_.DEPARTURETIME AS 
    DEPARTUR5_4_, ROUTE0_.ENDDATE AS ENDDATE4_, ROUTE0_.MESSAGEID 
    AS MESSAGEID4_, ROUTE0_.OPENSEATS AS OPENSEATS4_, 
    ROUTE0_.OWNER_ID AS OWNER14_4_, ROUTE0_.ROUTECACHE_ID AS 
    ROUTECACHE11_4_, ROUTE0_.ROUTEOPTIMIZED AS ROUTEOPT9_4_, 
    ROUTE0_.START_ID AS START12_4_, ROUTE0_.STOP_ID AS STOP10_4_ 
FROM ROUTE ROUTE0_ INNER JOIN CARPOOLER CARPOOLERS1_ ON 
    ROUTE0_.ID=CARPOOLERS1_.ROUTEID 
WHERE (route0_.owner_id=? or carpoolers1_.user_id=?) and route0_.id=?

SELECT CAR0_.ID AS ID5_3_, CAR0_.BRAND_ID AS BRAND8_5_3_, CAR0_.CARNAME 
    AS CARNAME5_3_, CAR0_.CARTYPE AS CARTYPE5_3_, CAR0_.IMAGEURL AS 
    IMAGEURL5_3_, CAR0_.PRICEKM AS PRICEKM5_3_, CAR0_.SEATS AS 
    SEATS5_3_, CAR0_.USER_ID AS USER7_5_3_, BRAND1_.ID AS ID6_0_, 
    BRAND1_.BRANDNAME AS BRANDNAME6_0_, USER2_.ID AS ID0_1_, 
    USER2_.EMAIL AS EMAIL0_1_, USER2_.FACEBOOKID AS FACEBOOKID0_1_, 
    USER2_.FIRSTNAME AS FIRSTNAME0_1_, USER2_.GENDER AS GENDER0_1_, 
    USER2_.IMAGEURL AS IMAGEURL0_1_, USER2_.LANGUAGE_ID AS 
    LANGUAGE12_0_1_, USER2_.LASTNAME AS LASTNAME0_1_, 
    USER2_.MOBILEPHONE AS MOBILEPH8_0_1_, USER2_.PASSWORD AS 
    PASSWORD0_1_, USER2_.SMOKER AS SMOKER0_1_, USER2_.TELEPHONE AS 
    TELEPHONE0_1_, LANGUAGE3_.ID AS ID9_2_, LANGUAGE3_.LANGUAGE AS 
    LANGUAGE9_2_, LANGUAGE3_.LANGUAGECODE AS LANGUAGE3_9_2_ 
FROM CAR CAR0_ LEFT OUTER JOIN BRAND BRAND1_ ON 
    CAR0_.BRAND_ID=BRAND1_.ID LEFT OUTER JOIN USER USER2_ ON 
    CAR0_.USER_ID=USER2_.ID LEFT OUTER JOIN LANGUAGE LANGUAGE3_ ON 
    USER2_.LANGUAGE_ID=LANGUAGE3_.ID 
WHERE car0_.id=?

SELECT USER0_.ID AS ID0_1_, USER0_.EMAIL AS EMAIL0_1_, 
    USER0_.FACEBOOKID AS FACEBOOKID0_1_, USER0_.FIRSTNAME AS 
    FIRSTNAME0_1_, USER0_.GENDER AS GENDER0_1_, USER0_.IMAGEURL AS 
    IMAGEURL0_1_, USER0_.LANGUAGE_ID AS LANGUAGE12_0_1_, 
    USER0_.LASTNAME AS LASTNAME0_1_, USER0_.MOBILEPHONE AS 
    MOBILEPH8_0_1_, USER0_.PASSWORD AS PASSWORD0_1_, USER0_.SMOKER 
    AS SMOKER0_1_, USER0_.TELEPHONE AS TELEPHONE0_1_, LANGUAGE1_.ID 
    AS ID9_0_, LANGUAGE1_.LANGUAGE AS LANGUAGE9_0_, 
    LANGUAGE1_.LANGUAGECODE AS LANGUAGE3_9_0_ 
FROM USER USER0_ LEFT OUTER JOIN LANGUAGE LANGUAGE1_ ON 
    USER0_.LANGUAGE_ID=LANGUAGE1_.ID 
WHERE user0_.id=?

SELECT ROUTECACHE0_.ID AS ID7_2_, ROUTECACHE0_.AANTALM AS AANTALM7_2_, 
    ROUTECACHE0_.AANTALMIN AS AANTALMIN7_2_, ROUTECACHE0_.ACTIVE AS 
    ACTIVE7_2_, ROUTECACHE0_.JSON AS JSON7_2_, 
    ROUTECACHE0_.LOCATIONS AS LOCATIONS7_2_, 
    ROUTECACHE0_.LOCATIONSOPTIMIZED AS LOCATION7_7_2_, 
    ROUTECACHE0_.ROUTEOPTIMIZED AS ROUTEOPT8_7_2_, 
    ROUTECACHE0_.START_ID AS START10_7_2_, ROUTECACHE0_.STOP_ID AS 
    STOP9_7_2_, LOCATION1_.ID AS ID2_0_, LOCATION1_.LANG AS 
    LANG2_0_, LOCATION1_.LAT AS LAT2_0_, LOCATION1_.NUMBER AS 
    NUMBER2_0_, LOCATION1_.STREET AS STREET2_0_, LOCATION1_.ZIPCODE 
    AS ZIPCODE2_0_, LOCATION2_.ID AS ID2_1_, LOCATION2_.LANG AS 
    LANG2_1_, LOCATION2_.LAT AS LAT2_1_, LOCATION2_.NUMBER AS 
    NUMBER2_1_, LOCATION2_.STREET AS STREET2_1_, LOCATION2_.ZIPCODE 
    AS ZIPCODE2_1_ 
FROM ROUTECACHE ROUTECACHE0_ LEFT OUTER JOIN LOCATION LOCATION1_ ON 
    ROUTECACHE0_.START_ID=LOCATION1_.ID LEFT OUTER JOIN LOCATION 
    LOCATION2_ ON ROUTECACHE0_.STOP_ID=LOCATION2_.ID 
WHERE routecache0_.id=?

 SELECT ROUTECACHE0_.ROUTECACHESPUNTENTUSSEN_ID AS ROUTECAC1_1_, 
    ROUTECACHE0_.ROUTECACHETUSSENPUNTEN_ID AS ROUTECAC2_1_, 
    LOCATION1_.ID AS ID2_0_, LOCATION1_.LANG AS LANG2_0_, 
    LOCATION1_.LAT AS LAT2_0_, LOCATION1_.NUMBER AS NUMBER2_0_, 
    LOCATION1_.STREET AS STREET2_0_, LOCATION1_.ZIPCODE AS 
    ZIPCODE2_0_ 
FROM ROUTECACHE_LOCATION_PUNTEN ROUTECACHE0_ LEFT OUTER JOIN LOCATION 
    LOCATION1_ ON 
    ROUTECACHE0_.ROUTECACHETUSSENPUNTEN_ID=LOCATION1_.ID 
WHERE routecache0_.routecachesPuntenTussen_id=?

 SELECT CARPOOLERS0_.ROUTEID AS ROUTEID5_, CARPOOLERS0_.ID AS ID5_, 
    CARPOOLERS0_.ID AS ID3_4_, CARPOOLERS0_.APPROVED AS 
    APPROVED3_4_, CARPOOLERS0_.ONETIME AS ONETIME3_4_, 
    CARPOOLERS0_.ROUTEID AS ROUTEID3_4_, CARPOOLERS0_.START_ID AS 
    START5_3_4_, CARPOOLERS0_.STOP_ID AS STOP7_3_4_, 
    CARPOOLERS0_.USER_ID AS USER6_3_4_, LOCATION1_.ID AS ID2_0_, 
    LOCATION1_.LANG AS LANG2_0_, LOCATION1_.LAT AS LAT2_0_, 
    LOCATION1_.NUMBER AS NUMBER2_0_, LOCATION1_.STREET AS 
    STREET2_0_, LOCATION1_.ZIPCODE AS ZIPCODE2_0_, LOCATION2_.ID AS 
    ID2_1_, LOCATION2_.LANG AS LANG2_1_, LOCATION2_.LAT AS LAT2_1_, 
    LOCATION2_.NUMBER AS NUMBER2_1_, LOCATION2_.STREET AS 
    STREET2_1_, LOCATION2_.ZIPCODE AS ZIPCODE2_1_, USER3_.ID AS 
    ID0_2_, USER3_.EMAIL AS EMAIL0_2_, USER3_.FACEBOOKID AS 
    FACEBOOKID0_2_, USER3_.FIRSTNAME AS FIRSTNAME0_2_, 
    USER3_.GENDER AS GENDER0_2_, USER3_.IMAGEURL AS IMAGEURL0_2_, 
    USER3_.LANGUAGE_ID AS LANGUAGE12_0_2_, USER3_.LASTNAME AS 
    LASTNAME0_2_, USER3_.MOBILEPHONE AS MOBILEPH8_0_2_, 
    USER3_.PASSWORD AS PASSWORD0_2_, USER3_.SMOKER AS SMOKER0_2_, 
    USER3_.TELEPHONE AS TELEPHONE0_2_, LANGUAGE4_.ID AS ID9_3_, 
    LANGUAGE4_.LANGUAGE AS LANGUAGE9_3_, LANGUAGE4_.LANGUAGECODE AS 
    LANGUAGE3_9_3_ 
FROM CARPOOLER CARPOOLERS0_ LEFT OUTER JOIN LOCATION LOCATION1_ ON 
    CARPOOLERS0_.START_ID=LOCATION1_.ID LEFT OUTER JOIN LOCATION 
    LOCATION2_ ON CARPOOLERS0_.STOP_ID=LOCATION2_.ID LEFT OUTER 
    JOIN USER USER3_ ON CARPOOLERS0_.USER_ID=USER3_.ID LEFT OUTER 
    JOIN LANGUAGE LANGUAGE4_ ON USER3_.LANGUAGE_ID=LANGUAGE4_.ID 
WHERE carpoolers0_.RouteId=?

, Ты заранее

Ответы [ 3 ]

1 голос
/ 08 марта 2011

Дайте Spring Insight попробовать.Вот демоверсия:

http://www.youtube.com/watch?v=P_EskssNDU8

и вот несколько документов:

http://static.springsource.com/projects/tc-server/6.0/devedition/cinintro.html

Если вы используете STS довольно просто подключить его к вашему веб-приложению, и он покажет вам конечную производительность и все ваши узкие места.

Есть действительно хороший пост в блоге с некоторыми скриншотами здесь

1 голос
/ 08 марта 2011

Судя по вашей публикации, узким местом является SQL-запрос (460 мс из 500 мс).Есть несколько вещей, которые я бы порекомендовал вам попробовать:

  • Попробуйте изменить режим сброса сеанса Hibernate.В двух словах, по умолчанию всякий раз, когда вы выполняете запрос, Hibernate должен перебирать каждый объект в сеансе, чтобы определить, нужно ли что-либо сбрасывать в базу данных перед выполнением запроса.В зависимости от того, сколько материала находится в вашем сеансе, этот процесс может занять больше времени, чем фактический запрос для выполнения!Вот некоторые ссылки с дополнительной информацией об изменении режима очистки.

https://forums.hibernate.org/viewtopic.php?p=2263250&sid=3c1db460d6d28155799cf95f76730606 http://docs.jboss.org/hibernate/core/3.5/api/org/hibernate/FlushMode.html

  • Попробуйте сначала поставить проверку на идентификатор маршрута.Это может быть быстрее, в зависимости от того, какую базу данных вы используете
  • Запустите ваш SQL через инструмент профилирования.Все основные базы данных имеют их.Инструмент профиля покажет вам, какая часть вашего запроса самая дорогая, и может даже показать, где индекс может значительно сократить время запроса.
0 голосов
/ 08 марта 2011

Пожалуйста, используйте Fiddler2

http://www.fiddler2.com/fiddler2/

, вы сможете увидеть, есть ли отметки времени запроса / ответа, а также узнать, находится ли горлышко бутылки на сервере или клиенте.Вы можете сделать это, нажав правую кнопку мыши на запросе в Fiddler.

Надеюсь, это поможет.

...