Сообщество
Логин
Пароль
Забыли пароль?     Регистрация
Ещё проектики
Рабочее время
Минималистичный счётчик рабочего времени онлайн
Общение / Веб версия / Скорость работы сервиса

Скорость работы сервиса

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
Подтверждаю последний пост: если страница грузится очень неспешно - то проблемы при внесении записей
1 2  Туда  
Чтобы отвечать на сообщения - зарегистрируйтесь и войдите в личный кабинет.