|
Anastasia
|
|
18 декабря 2011 18:44
|
|
Что-то в последнее время онлайн сервис стал жутко тормозить. Вот сейчас нажала на смену даты и смотрю на надпись "Секунду..." уже минуты три. И так постоянно ((( Остальные сайты летают, только Дребеденьги как-будто через dial-up работает. А когда вносишь длинные чеки, это начинает раздражать настолько, что хочется сменить сервис, вы уж меня простите!
Я понимаю, что количество пользователей растет, количество коннектов к сайту тоже, но надо же как-то тогда мощности наращивать...
Очень не хочется от вас уходить, но иногда просто терпения не хватает.
|
|
|
|
Admin
|
|
18 декабря 2011 18:51
|
|
Здравствуйте,
Если "Секунда" крутится уже минуты три - это не сайт тормозит. Скорее всего у вас закэшировались какие-то скрипты и теперь они выполняются с ошибкой. Посмотрите в javascript консоль, нет ли там ошибок? И какой у вас браузер - случаем не Chrome?
Если есть возможность - проверьте работу в другом браузере, посмотрите, есть ли там эта проблема?
PS
У нас достаточно серверных мощностей и мы постоянно мониторим нагрузку, которая в среднем не превышает 1%, т.е. сервер практически "ничего не делает" с текущим запасом мощности. Так что на этот счёт можете не переживать.
|
|
|
|
Admin
|
|
18 декабря 2011 18:53
|
|
Вобщем, с проблемой нужно разбираться.
Ответьте на вопросы из прошлого сообщения и опишите подробнее как происходит дело, сколько в среднем занимает у вас ввод траты (т.е. сколько крутится индикатор "секунду")?
|
|
|
|
Anastasia
|
|
18 декабря 2011 19:03
|
|
Браузер Mozilla Firefox, в консоли ошибок нет, кэш вычищен.
Через IE Дребеденьги грузятся с тем же "успехом": сижу медитирую на скорость загрузки ;-)
С андроида через Dolphin - та же ерунда: все медленно и печально.
Есть, конечно, вариант, что нужно грешить на провайдера: может, ему чем-то ваш сервис не нравится ))) хотя трассировка выдает всего 7 хопов с адекватными задержками.
|
|
|
|
Admin
|
|
18 декабря 2011 19:11
|
|
А в demo аккаунте тоже так же долго вводятся траты?
Вы не ответили, сколько секунд в среднием крутится индикатор при фиксировании траты.
|
|
|
|
Ivan
|
|
30 декабря 2011 10:13
|
|
Кстати, я тоже замечал (пользуюсь на десктопе хромом), что иногда операция по добавлению расходов (первая в сессии) не проходит. И f5 проблему лечит.
Если это и вправду проблема с обновлениями ваших скриптов и инвалидацией кэша браузера, то довольно легко на корню это решается добавлением текущей версии (ревизии, билда, или что у вас ещё есть, что меняется от билда к билду) в урл до статических проблемных ресурсов
/js/tab6.js
->
/js/v42/tab6.js
Ну и модреврайтом завернуть все /js/v[^/]+/.*
|
|
|
|
Admin
|
|
30 декабря 2011 10:24
|
Ivan Пишет: Если это и вправду проблема с обновлениями ваших скриптов У нас все обновляемые скрипты имеют номер версии и нормально обновляются.
Было замечено, что похоже по крайней мере часть подобных проблем присуща только гугл Хрому.
|
|
|
|
Ivan
|
|
30 декабря 2011 10:25
|
|
Занятно. Ну ок, тогда в следующий раз не будем паниковать и таки поглядим что там творится в консоли
|
|
|
|
Ivan
|
|
30 декабря 2011 10:30
|
|
Кстати, а у вас на js вообще нет ни етегов, ни Last-Modified. 23.5кб только на одних жсах на каждый запрос гоняются просто так
|
|
|
|
Admin
|
|
30 декабря 2011 11:02
|
Ivan Пишет: Кстати, а у вас на js вообще нет ни етегов, ни Last-Modified. 23.5кб только на одних жсах на каждый запрос гоняются просто так Вроде бы не гоняются, сервер отдаёт статус 304 not modified, если только вы ctrl+f5 не нажимаете.
Скажите точное название скрипта и последовательность ваших действий, когда вы видите скачку 23.5Кб в каждом запросе?
|
|
|
|
Ivan
|
|
30 декабря 2011 11:06
|
1. Открываем drebedengi.ru
2. Кликаем на "личный кабинет"
3. Получаем вот что: http://i32.fastpic.ru/big...e.png
У клиента и сервера недостаточно информации, чтобы отдать 305:
Запрос:
Accept:*/*
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-GB,en-US;q=0.8,en;q=0.6
Connection:keep-alive
Referer: https://www.drebedengi.ru...ivate
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.63 Safari/535.7
Ответ:
Connection:Keep-Alive
Content-Encoding:gzip
Content-Length:9562
Content-Type:text/html
Date:Fri, 30 Dec 2011 07:03:37 GMT
Keep-Alive:timeout=15, max=100
Server:Apache/2.0.63 (FreeBSD) DAV/2 SVN/1.6.11 PHP/5.3.2 with Suhosin-Patch mod_ssl/2.0.63 OpenSSL/0.9.8e
Vary:Accept-Encoding
X-Powered-By:PHP/5.3.2
Таким образом сервер нам не отдал ни etag, ни Last-Modified. Соответственно клиент не может эти два заголовка отправить при следующем запросе. Соответственно сервер нам отдаёт весь файл
|
|
|
|
Ivan
|
|
30 декабря 2011 11:07
|
|
Ох, потрите, пожалуйста, в моём предыдущем посте куки.
|
|
|
|
Admin
|
|
30 декабря 2011 16:10
|
|
Вы были правы, last-modified отдавался только для самого большого скрипта, а про маленькие мы забыли. Поправили, теперь должны браться из кэша.
|
|
|
|
Ivan
|
|
2 января 2012 08:27
|
|
Всё таки нет, проблема не с закешированным жс.
В консоли ошибок нет. А примерно минутное ожидание, пока ввод траты закончится - в итоге завершился таким вот безобразием: http://i28.fastpic.ru/big/2012/0102/45/76d7af52a26e2493bf6a5674f2643345.png
|
|
|
|
Ivan
|
|
2 января 2012 08:30
|
|
Хотя нет, вот вам и ошибки: http://i28.fastpic.ru/big/2012/0102/3a/74812a3e9a7a969d6624f7bd3b17473a.png
|
|
|
|
Admin
|
|
2 января 2012 13:38
|
Ivan Пишет: в итоге завершился таким вот безобразием Это другая проблема, которая иногда проявляется только в браузере Chrome. Есть подозрение, что сказывается какая-то особенность этого браузера, при работе с нашим сервером.
Попробуйте отключить опцию "Предсказывать сетевые действия для ускорения загрузки страниц"
|
|
|
|
Ivan
|
|
2 января 2012 13:59
|
|
Гхм, не могу представить как это prediction может влиять. В итоге-то ваш код ведь выплёвывает вывод аяксового на страницу, вместо его (вывода) обработки.
|
|
|
|
Admin
|
|
2 января 2012 14:22
|
|
Будем ещё с этой проблемой разбираться, пока не понятно в чём причина.
|
|
|
|
Ivan
|
|
2 января 2012 14:23
|
|
Угу. Оно как бы особо не раздражает, но очень странно выглядит :-S
|
|
|
|
Admin
|
|
2 января 2012 14:25
|
|
А включен ли у вас при этом SSL режим?
|
|
|
|
Ivan
|
|
2 января 2012 14:26
|
|
Угу, всегда
|
|
|
|
Admin
|
|
2 января 2012 14:32
|
|
Похоже использование SSL тоже оказывает влияние. Без SSL такой проблемы не замечалось.
Пока известно только то, что иногда в теле расшифрованного ответа от сервера присутствует не корректный первый символ. На вашем скриншоте его тоже видно, перед HTTP/1.1.
Либо его вставляет сервер, либо сам Хром.
|
|
|
|
Ivan
|
|
2 января 2012 14:34
|
|
В следующий раз посмотрю какой у него код, но почти наверняка это BOM
|
|
|
|
Admin
|
|
2 января 2012 14:57
|
|
BOM это три байта, а там виден только один.
|
|
|
|
Ivan
|
|
2 января 2012 15:01
|
|
BOM это от 2 до 4 байт. Вопросик - это отсутствующий в шрифте знак в любой двухбайтной кодировке.
Вопрос только в том уже, что ajax традиционно предполагает utf8 (двухбайтную кодировку), а у вас везде cp1251
|
|
|
|
Ivan
|
|
3 января 2012 08:20
|
|
Поймал ситуацию и немного поизучал: http://i27.fastpic.ru/big/2012/0103/76/3e2c9d5dac07b9d83dc126f557030976.png
Как вы видите - в ответ на запрос скрипта wick.js перед заголовками ваш сервер выплюнул знак <, и в итоге все заголовки оказались в непосредственно ответе. Как результат - ошибки выполнения жс и бесконечно крутящийся троббер.
Аналогичные проблемы были при отдаче calendar-ru_win_.js
|
|
|
|
Admin
|
|
3 января 2012 13:07
|
Ivan Пишет: ваш сервер выплюнул знак < ..либо его вставил сам Chromе, т.к. в других браузерах и без SSL такой проблемы не зафиксировано.
|
|
|
|
Ivan
|
|
3 января 2012 14:09
|
|
Хром, который избирательно только на дребеденьгах вставляет непонятный символ. Звучит как заговор корпорации зла против вас :-)
|
|
|
|
Admin
|
|
3 января 2012 16:02
|
Ivan Пишет: который избирательно только на дребеденьгах Может и не только на дребеденьгах, а при каких-то особых параметрах конфигурации сервера, + ajax, +SSL. Так же есть возможность не корректной работы кэша браузера, о которой в интернете уже писали.
Впрочем, пока нет ясности в этом вопросе, утверждать точно ничего нельзя. Можно лишь строить предположения и догадки.
На стороне сервера будем ещё смотреть и разбираться. Просто дело усложняется тем, что траффик зашифрован и очень сложно посмотреть и убедиться приходит ли действительно этот символ от сервера, или вставляется на клиенте.
|
|
|
|
RsH
|
|
5 января 2012 02:55
|
|
аналогичная проблема появилась на chrome и IE9.
Заметил начиная с октября-начала ноября. Возможно, но не точно - после отмены перехода на зимнее время.
проявляется как: при простое более 1 минуты (иногда 30 сек) секунд, вводить траты или изменять планы - бесполезно - не сохранится. F5 помогает не всегда. самое простое - перейти на из трат в планирование и обратно.
в чем проблема не разбирался, но иногда бесит.
|
|
|
|
Admin
|
|
5 января 2012 10:46
|
|
Вероятно с IE9 проблема в чём-то другом. Посмотреть бы в средствах разработчика и в консоли что при этом происходит..
|
|
|
|
Admin
|
|
11 января 2012 13:32
|
Ivan Пишет: Как вы видите - в ответ на запрос скрипта wick.js перед заголовками ваш сервер выплюнул знак < Выяснилось, что это не просто знак <, а 4 какие-то байта перед началом заголовков, 3 из которых не отображаются..
"�HTTP"
Продолжаем разбираться с проблемой, но суть пока непонятна.
|
|
|
|
Ivan
|
|
11 января 2012 13:35
|
|
Занимательно... :-S Но вообще симптоматика очень странная. Я бы, скорее всего, в первую очередь начал смотреть в сторону всяких сжимающе-оптимизирующих модулей веб-сервера (или реверс-прокси, если у вас таковые есть)
|
|
|
|
Admin
|
|
11 января 2012 13:38
|
|
Сжатый контент идёт уже после не сжатых HTTP заголовков, врятли это играет роль.
Более всего странным является тот факт, что без SSL такой проблемы нет даже в Chrome.
|
|
|
|
Бисквит
|
|
20 января 2012 21:17
|
|
Сегодня вводил траты на десктопе через мобильную версию. Через обычный интерфейс ни в какую не хочет. Надпись "Секунду..." висит по 5 минут, а потом как повезет - может, сохранится, а может и нет.
|
|
|
|
Admin
|
|
20 января 2012 23:45
|
Бисквит Пишет: Через обычный интерфейс ни в какую не хочет Уточните какой у вас браузер, используется ли SSL?
|
|
|
|
Бисквит
|
|
20 января 2012 23:52
|
Администратор Пишет: Бисквит пишет:Через обычный интерфейс ни в какую не хочетУточните какой у вас браузер, используется ли SSL? Firefox 7.0 и 9.0.1
Пробовал заходить и с SSL, и без. Результат одинаковый.
|
|
|
|
Admin
|
|
21 января 2012 11:54
|
Бисквит Пишет: Firefox 7.0 и 9.0.1
Пробовал заходить и с SSL Это видимо какая-то другая проблема. Опишите подробнее, что именно вы делаете, что видите и как часто это происходит? Есть ли при этом ошибки в javascript консоли? Происходит ли то же самое если зайти под demo пользователем?
|
|
|
|
Бисквит
|
|
21 января 2012 12:19
|
|
Что делаю: захожу в личный кабинет, секунд 10 вижу такую картину (http://i.imgur.com/9CSRh.jpg), т.е. грузится долго и по частям, не так как обычно. SSL/не SSL, Demo/не Demo на это никак не влияют.
Как часто это происходит - постоянно.
Как долго это происходит - последние дня 3-4 точно, может и чуть раньше началось, но я не придавал этому особого значения, думал, может какие сервисные работы проводите.
Проблема замечена на Firefox 7.0 и 9.0.1. Только что пробовал Opera 11.00 - там все нормально как под demo, так и под моим аккаунтом.
Вот что показывает консоль FF просто после загрузки страницы (у меня закладка настроена сразу на личный кабинет) - http://i.imgur.com/AjowD.png
А вот что после ввода двух тестовых трат (почти 20 сек каждая) - http://i.imgur.com/fGhbr.png
|
|
|
|
Ivan
|
|
21 января 2012 12:21
|
|
Подтверждаю последний пост: если страница грузится очень неспешно - то проблемы при внесении записей
|
|
|
Секунду ...
