За последние 24 часа нас посетили 16666 программистов и 1646 роботов. Сейчас ищут 1846 программистов ...

Скорость выполнения скрипта JQ

Тема в разделе "JavaScript и AJAX", создана пользователем Taktreba, 22 дек 2017.

  1. Taktreba

    Taktreba Активный пользователь

    С нами с:
    11 янв 2017
    Сообщения:
    543
    Симпатии:
    132
    Есть сервис, я делаю похожий, и там где, вроде одинаковые события, я решил посмотреть в нетворке скорость (что как названия цифры и показатели я не знаю что означают)
    Есть чужое событие - в network timing, показатель Waiting (TTFB) в среднем равен 50-150ms
    Мое событие (вроде такое же по функционалу) в среднем 600ms ((

    делал на JQ
    Вопрос:
    Насколько плоха цифра в 600ms
    Как оптимизировать?
    Может лучше использовать JS чистый?
    Может забить и не париться?

    зы. чужой сервер где на "просторах", мой локально на openserver
     
  2. Ganzal

    Ganzal Суперстар
    Команда форума Модератор

    С нами с:
    15 мар 2007
    Сообщения:
    9.893
    Симпатии:
    965
    Ожидание первого байта оно как бы от сервера зависит а не от клиента. Клиент делает запрос. При этом сначала он резолвит ип к которому надо подключиться. устанавливает соединение. При тлс - обменивается рукопожатиями. Далее записывает на сокет заголовки и данные запроса. Веб-сервер ориентируясь на полученные данные разрешает исполнителя - будет отдавать данные сам с диска или по какому-либо механизму вызовет какой-либо другой процесс, ответственный за обработку запроса, и передаст ему данные запроса. Ну и соответственно, когда сам веб-сервер начал выдавать в сокет вывода - читая файл с диска или получая ответные данные (выступая в роли практически прокси) от стороннего обработчика - тогда клиент и ставит отсечку принятия первого байта ответа. От того какой технологией ты делаешь запрос это зависит менее, чем от оптимизированности скриптов и/или нагруженности сервера. Ну а если учесть полный цикл жизни запроса то важен еще и канал связи и скорость обмена с днс-сервером.
     
  3. Fell-x27

    Fell-x27 Суперстар
    Команда форума Модератор

    С нами с:
    25 июл 2013
    Сообщения:
    12.156
    Симпатии:
    1.770
    Адрес:
    :сердА
    И количество узлов на трассе между клиентом и сервером. И длина этой трассы. И ее техническое состояние. И состояние узлов. Если посреди трассы твой запрос проходит через раскаленный помирающий кэшпрокси очередного "говнотелекома", то вот ваще пофигу насколько у тебя быстрый сервер и насколько там стогигабитные каналы. Если умирающий прокси зажует запрос на пару секунд, ты получишь +2000ms к ожиданию.
    --- Добавлено ---
    Сделай tracert до своего сайта, увидишь своими глазами, где проблемы.
     
  4. Алекс8

    Алекс8 Активный пользователь

    С нами с:
    18 май 2017
    Сообщения:
    1.730
    Симпатии:
    359
    Подводя итог... Забей...
     
  5. Fell-x27

    Fell-x27 Суперстар
    Команда форума Модератор

    С нами с:
    25 июл 2013
    Сообщения:
    12.156
    Симпатии:
    1.770
    Адрес:
    :сердА
    Не, все проще - хочешь быть уверенным, что тормозит не твое творение, делай замеры отзывчивости системы, крутящейся на локальном сервере, чтобы исключить влияние трассы.
     
  6. Ganzal

    Ganzal Суперстар
    Команда форума Модератор

    С нами с:
    15 мар 2007
    Сообщения:
    9.893
    Симпатии:
    965
    это на транспортном уровне проблемы покажет. то что я обобщил до канала связи. а всякие прокси, веб-серверы, генераторы трафика и клиенты - чуть другой уровень модель оси.