Здравствуйте, dmz, Вы писали:
dmz>Привет,
dmz>Есть некий метод, делающий выборку из базы, который вызывается из xmlrpc-метода. dmz>Когда вызывается локально — отрабатывает где-то за 0 — 1 ms (по xmlrpc с localhost-а),
dmz>Когда вызывается по сети с другого хоста — случаются провалы по 2 — 3 секунды на каждый, скажем, 10-ый или 20-ый dmz>вызов.
dmz>Куда копать, интересно?
Просьба — когда разберешься, не мог бы ты подробно отписать сюда, в чем была проблема и как вы ее решили? Thnx.
К>>А пустая заглушка тоже так себя ведёт? База мнезийная или одбц? К>>В erlang questions копать по-моему было бы полезно
dmz>Насчет пустой не уверен, но вроде бы нет. База тут должна быть иррелевантна, потому что если вызывать dmz>локально, даже по xmlrpc, но на localhost, то все работает без затыков.
Кроме метода дедукции даже не знаю что посоветовать. Для начала базу выкиньте и доведите "бажный" пример до минимального, а потом анализируйте. Плюс все логи возможные, которые бы проливали свет на ситуацию задействуйте.
Хотя это, я думаю, и без меня понятно
dmz>Про erlang-questions... Ну если сами не заборем, то придется туда обращаться.
Имхо там люди будут посолидней по знанию Эрланга, чем тут на рсдн
Здравствуйте, dmz, Вы писали:
dmz>Привет,
dmz>Есть некий метод, делающий выборку из базы, который вызывается из xmlrpc-метода. dmz>Когда вызывается локально — отрабатывает где-то за 0 — 1 ms (по xmlrpc с localhost-а),
dmz>Когда вызывается по сети с другого хоста — случаются провалы по 2 — 3 секунды на каждый, скажем, 10-ый или 20-ый dmz>вызов.
dmz>Куда копать, интересно?
1) Нашпиговать код трейсами или добавлять к инфе таймстампы, чтобы локализовать место задержки.
2) Посмотреть профайлером, что происходит в течении этих 2-х секунд.
3) Убрать базу, посмотреть — как ведет себя пустой xmlrpc.
4) Здать вопрос в erlang questions.
Есть некий метод, делающий выборку из базы, который вызывается из xmlrpc-метода.
Когда вызывается локально — отрабатывает где-то за 0 — 1 ms (по xmlrpc с localhost-а),
Когда вызывается по сети с другого хоста — случаются провалы по 2 — 3 секунды на каждый, скажем, 10-ый или 20-ый
вызов.
К>А пустая заглушка тоже так себя ведёт? База мнезийная или одбц? К>В erlang questions копать по-моему было бы полезно
Насчет пустой не уверен, но вроде бы нет. База тут должна быть иррелевантна, потому что если вызывать
локально, даже по xmlrpc, но на localhost, то все работает без затыков.
Про erlang-questions... Ну если сами не заборем, то придется туда обращаться.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, dmz, Вы писали:
dmz>>Привет,
dmz>>Есть некий метод, делающий выборку из базы, который вызывается из xmlrpc-метода. dmz>>Когда вызывается локально — отрабатывает где-то за 0 — 1 ms (по xmlrpc с localhost-а),
dmz>>Когда вызывается по сети с другого хоста — случаются провалы по 2 — 3 секунды на каждый, скажем, 10-ый или 20-ый dmz>>вызов.
dmz>>Куда копать, интересно?
G>1) Нашпиговать код трейсами или добавлять к инфе таймстампы, чтобы локализовать место задержки. G>2) Посмотреть профайлером, что происходит в течении этих 2-х секунд. Кстати — проц загружен? Откройте без профайлера процесс монитор, посмотрите, чем занята система. G>3) Убрать базу, посмотреть — как ведет себя пустой xmlrpc. G>4) Здать вопрос в erlang questions.
5) Проверить надежность сетевого соединения — нет ли дропнутых пакетов.
6) Нет ли проблем на клиенте? На чем написан клиент?
Здравствуйте, dmz, Вы писали:
G>>5) Проверить надежность сетевого соединения — нет ли дропнутых пакетов. G>>6) Нет ли проблем на клиенте? На чем написан клиент?
dmz>Проблема в сервере. Ерланга не касается. Остается понять, что происходит.
Как поняли, что в сервере, и не касается эрланга? Можешь лог рассуждений бросить?
dmz>>Проблема в сервере. Ерланга не касается. Остается понять, что происходит.
G>Как поняли, что в сервере, и не касается эрланга? Можешь лог рассуждений бросить?
Ну в общем, характер затыков после некоторого размышления наводил на мысли, что дело не в каких-то проблемах эрланга, а где-то еще.
Примеры:
XMLRPC:
Доступ с локалхоста: 100% запросов < 1ms
Доступ удаленно: 10% первых запросов ~10ms, остальные ~3000ms
Бинарный Эрланговый RPC:
Полностью аналогичная картина. Причем, времена запросов в одной сессии составляют четкую ступень,
никакого разброса — первые N запросов выполняются единицы миллисекунд, остальные — тысячи, причем в одной
сессии время этих запросов четко одинаковое.
Согласитесь, ситуация несколько ненатуральная. Уже тут понятно, что дело не может быть в Эрганге, поверить, что он может так тормозить на своем бинарном RPC невозможно.
Посмотрев на эту картину, поднял на сервере lighttpd и запустил аналогичны тесты для него.
Картина абсолютно аналогична. Первые N запросов — 0ms, следующие — XXXms или XXXXms,
причем в одной сессии четко одинаково.
Хорошо подумав, я вcпомнил, что есть дружественный сервер, стоящий в этой серверной, в рамках того-же свича. Допустим, мой будет Alpha, дружественный — Beta (там уже стоял апач)
Попросил на нем логин, и проделал серию тестов (при помощи ab):
Beta -> Beta ( Xms, без нареканий, все мгновенно, апач)
Remote Host -> Beta ( Xms -> XXXXms, но серия запросов, когда время равно X — в разы длиннее, чем для Alpha)
Alpha -> Beta ( Xms )
Beta -> Alpha ( Xms )
В общем, пришли к выводу, что дело в некоем трафик-шейпере в данной сети, в понедельник будем разбираться с провайдером.
Но очень задалбывает отлаживать приложение (морду), которое широко использует AJAX, и ходит за данными на эрланговый сервер, который как раз на Alpha, и деть его оттуда некуда...
Здравствуйте, Аноним, Вы писали:
А>Проблема таки похожа на медленный резолвинг.
+1 при солидной нагрузке DNS вполне может стать узким местом, для обхода надо или лоадбалансинг для него применять (правда если внешний хостинг не знаю насколько это применимо) или организовывать что-то наподобие keep-alive, если позволяет ТЗ, насколько я понимаю epmd помнит уже отрезолвленные айпишники, поэтому повторно резолвить адреса не надо.
P.S. Хотя в данном случае, видимо, рассуждения по 2-му варианту особого смысла не несут, потому что связь не erlang-erlang (xmlrpc практически не знаю).
А>>Проблема таки похожа на медленный резолвинг.
К>+1 при солидной нагрузке DNS вполне может стать узким местом, для обхода надо или лоадбалансинг для него применять (правда если внешний хостинг не знаю насколько это применимо) или организовывать что-то наподобие keep-alive, если
Здравствуйте, dmz, Вы писали:
dmz>Это точно не DNS.
Ну как ещё мысль по поводу: Анатоликс в своих презентациях показывал "пики" в производительности яндекса, может тоже ретрансмиты виноваты? (см. здесь, 25/26 страницы презентахи)
Порядок заморочек, наверное, не яндексовский, но может проблемы в настройках оборудования?
К>Ну как ещё мысль по поводу: Анатоликс в своих презентациях показывал "пики" в производительности яндекса, может тоже ретрансмиты виноваты? (см. здесь, 25/26 страницы презентахи) К>Порядок заморочек, наверное, не яндексовский, но может проблемы в настройках оборудования?
Проблема, как я уже писал, скорее всего в трафик шейпере в сети провайдера. Будем разбираться с ним, в первую очередь.
К>>Ну как ещё мысль по поводу: Анатоликс в своих презентациях показывал "пики" в производительности яндекса, может тоже ретрансмиты виноваты? (см. здесь, 25/26 страницы презентахи) К>>Порядок заморочек, наверное, не яндексовский, но может проблемы в настройках оборудования?
dmz>Проблема, как я уже писал, скорее всего в трафик шейпере в сети провайдера. Будем разбираться с ним, в первую очередь.
А если просто поставить файл с http качаться ?
Если это shaper -- на нем вы ЧЕТКО увидите пики ))
dns может влиять только на время от запроса до установления подключения, потом на передачу данных он никак не влияет.
)) 