Это называется History API, но поддерживается не во всех браузерах, вот видимо Google и использует менее красивую, но единую и кроссбраузерную реализацию.
Это нужно для воспроизводимости результатов живого поиска. По этому то, что изменялось на странице JavaScript'ом отражается в якоре (после #), в результате получается ссылка как бы на результат работы скриптов страницы, которую можно копировать, сохранять, передавать другим и повторно к ней возвращаться.
Если присмотреться к URL, то там видно две части — до # и после #. Налоговая инспекция находится в части до решетки, следовательно это оригинальный запрос, который был введен, например, в строке адреса браузера. Искомый же запрос находится после символа #, следовательно он был добавлен туда веб-интерфейсом гугла после ввода запроса в строку поиска в результатах поиска. Таким образом в адресную строку попало два запроса, которые и выполнились, отобразив результат последнего запроса.
Странно, но возможно так оно и есть…
В самой то лицензии ( www.virtualbox.org/wiki/VirtualBox_PUEL ) такого расширения термина «personal use» похоже нет, а дальше я не углублялся, так как мое использование «VirtualBox Extension Pack» ограничивается действительно персональным и академическим использованием.
Добавлю, что только сам VirtualBox.
Есть еще «VirtualBox Extension Pack», который бесплатен только для личного и академического использования, но для виртуализации офиса его функциональность вряд-ли потребуется.
Видение подходов напрямую является следствием задач (резервов объективно может не быть), а новые ряды стоек с оборудованием могут обойтись существенно дороже пути, который начнется с анализа проблемы.
Я теряю сколько долларов каждый час из-за того, что я теряю клиентов, из-за того что программа тормозит.
Я могу дать пару часов разработчикам на создание заплатки, или поручить админам купить компьютер помощнее, в надежде что это поможет, но вот чего я не могу, так это ждать пока вы там проводите исследования.
Вы сами себе противоречите. Если Вы знаете, что «теряете», то вы знаете каких показателей Вам нужно добиться(а вначале вы сказали, что показателей нет) и исходя из оценки недополученной прибыли(потерь у Вас нет, есть только сумма, которую Вы могли бы дополнительно получить работая сервис быстрее) можете оценивать сколько вы можете дать времени программистам на анализ и исправление конкретной проблемы. И это будет обоснованная цифра, а не абстрактные пара часов.
Прошу прощения, просмотрел в Вашем сообщении iostat.
Что именно «это» является порочной практикой? Минимизация усилий?
Вот это:
Да, конечно, возможно ваша программа криво написана и клепает короткоживущие объекты. Но если ситуацию можно временно улучшить потратив 10 минут на игру с параметрами gc, почему бы это не сделать?
Если есть косяк в программе, то его и нужно исправлять, а не прикручивать подпорки в виде параметров gc, так как в следующий раз подпорки могут не помочь, а времени на реакцию может и не остаться.
Я не согласен с тем что вы ставите разницу между понятиями «для собеседования» и «для жизни».
Ее ставлю не я. Она есть априори и задача интервьюера эту разницу минимизировать. А суть этой разницы в том, что любое интервью или в широком смысле оценка чьих то знаний — это всегда стресс, который в обычной работе отсутствует полностью (могут быть в работе конечно и другие стрессы, но речь не об этом).
Ну вообще iostat+gclog — и вы за минуту узнаете — есть ли overcommit по диску, есть ли излишняя нагрузка на gc, есть ли излишняя нагрузка на проц, не уходит ли ваша программа в своп.
Видите сколько инструментов и направлений анализа вылезло из простой на первый взгляд задачи? А все из-за того, что нет требований к тому, что нужно получить и нет никакой информации о среде запуска и т.д. Все, что необходимо даже для начала решения необходимо выспрашивать отдельно, а это с моей точки зрения большой минус…
Кроме того, я вам уже подсказал, что у меня есть серьезные подозрения что проблема именно в gc — т.к. характерные паузы в работе приложении говорят именно об этом.
Диск и сеть могут давать точно такие-же паузы, так что тут не все так очевидно. Опять-же вместо того, чтобы просто потыкать профайлером приходится еще анализировать окружение, алгоритмы работы приложения и многое другое. Не слишком ли размыта задача и критерий признания ее решенной?
Но если ситуацию можно временно улучшить потратив 10 минут на игру с параметрами gc, почему бы это не сделать?
Это порочная практика, так как она не решает проблемы, а лишь маскирует ее и по закону Мерфи проблема выстрелит в полный рост тогда, когда ее будут ждать меньше всего.
P.S. Возможно, конечно, что задача кажется мне столь неопределенной из-за того, что я программист не на Java, а на С++ и всего-лишь не знаю Java-инструментов…
Я думаю, что поставленная Вами задача будет в большей степени неразрешима, а в худшем случае вредна, так как оптимизация большой программы без анализа того, что она делает приведет либо к появлению трудночитаемых костылей из-за микрооптимизаций, либо к тому, что программа будет сломана.
Ответ конечно получился не для собеседования :), но в жизни скорее это будет так. Что-бы проводить оптимизации нужно понимать, что делает программа, так как без этого не понятно куда прикладывать профайлер, непонятно, нужен ли он вообще (может быть сервер перегружен на все 146% или приложение активно читает/пишет на диск, а диски не справляются или проблема в сети по которой приложение получает какие-то данные или ...), а может быть в программе сортируются гигабайты пузырьковой сортировкой и нужные оптимизации на самом деле алгоритмические, которые без анализа алгоритма не сделать.
Хотя может и нет. На самом деле я даже не уверен что она работает «медленно» — может быстрее эта задача в принципе не решается. Но все же, хочется ускорить.
— Те у Вас даже требований по необходимой производительности/отзывчивости системы нет? (возможный вариант продолжения разговора).
На мой взгляд, единственно верный вариант продолжения разговора в случае вопроса о медленности — это узнать критерий этой самой медленности и условия измерения. И только после этого можно приступать к анализу ибо велик риск варианта, что не устраивает latency, а до сервиса ~13000км по кратчайшему пути в трехмерном пространстве, что даже еще не изобретенная нейтринная связь не поможет получать результат быстрее чем за 44мс :)
Но и совсем не простая.
Во первых мало что из коробки умеет так делать, во вторых такая сегментация данных иногда нежелательна, а иногда и невозможна, но самая большая проблема в том, что неэффективность нарастает с ростом расстояния(все проблемы от скорости света) и в результате многополосная передача может перестать давать тот-же эффект из-за взаимовлияния потоков друг на друга.
По этому сейчас вполне развиваются оба направления и то, как передавать данные параллельно и то, как увеличить эффективность передачи в каждом соединении.
В это сложно поверить, но Амазон — это далеко не только облачные сервис. Это в первую очередь сервисы для своих внутренних нужд и что-то мне подсказывает, что для себя они и кроссдатацентровую репликацию используют и много чего еще, что для внешних клиентов только за отдельные деньги продается.
Я не теоретик, я практик, и практика моя очень обширна в данных вопросах.
Прошу прощения за нескромный вопрос, но, например?
В очередной раз убеждаюсь, что невежество за версту видно, но в очередной раз я искренне надеялся, что это просто незнание фактов, а не их активное отрицание.
Если продолжить логику, то среди обывателей прошло незамеченным подавляющее большинство событий статьи, но она почему-то существует…
Вопрос в другом. Сколько времени займет такая миграция по сети?
Если у нас 10G между ЦОДами в соседних комнатах, то перекачивать данные на такой скорости не проблема, но если ЦОДы в разных городах, то получить ~10G полезной скорости становится задачей нетривиальной. Вот и получается в результате, что записать диски (ленты) и перевести их на другую площадку грузовиком или самолетом может оказаться быстрее, даже в случае если это репликация.
Когда же мы говорим о больших передачах данных, например, между дата центрами, этот вариант не пройдет :)
Но, тем не менее, это не мешает использовать данный метод и крупным компаниями для передачи данных между датацентрами :)
К сожалению, я вынужден остаться голословным, так как этот удивительный для меня факт я узнал из личной беседы с европейскими коллегами о смысле жизни в системах передачи данных.
Спасибо за ссылку!
Я изначально где-то час исследовал их сайт на предмет сравнений, описаний и т.д., но только после Вашей ссылки заметил надпись «Free Trial» прямо в меню основного сайта.
Жизненно необходимая кстати вещь для AJAX-сайтов.
Если присмотреться к URL, то там видно две части — до # и после #. Налоговая инспекция находится в части до решетки, следовательно это оригинальный запрос, который был введен, например, в строке адреса браузера. Искомый же запрос находится после символа #, следовательно он был добавлен туда веб-интерфейсом гугла после ввода запроса в строку поиска в результатах поиска. Таким образом в адресную строку попало два запроса, которые и выполнились, отобразив результат последнего запроса.
(с) А. Эйнштейн.
И, если не воспринимать эти утверждения дословно и буквально, то, по моему мнению, они достаточно хорошо описывают наблюдаемые в реальности процессы.
В самой то лицензии ( www.virtualbox.org/wiki/VirtualBox_PUEL ) такого расширения термина «personal use» похоже нет, а дальше я не углублялся, так как мое использование «VirtualBox Extension Pack» ограничивается действительно персональным и академическим использованием.
Есть еще «VirtualBox Extension Pack», который бесплатен только для личного и академического использования, но для виртуализации офиса его функциональность вряд-ли потребуется.
Вы сами себе противоречите. Если Вы знаете, что «теряете», то вы знаете каких показателей Вам нужно добиться(а вначале вы сказали, что показателей нет) и исходя из оценки недополученной прибыли(потерь у Вас нет, есть только сумма, которую Вы могли бы дополнительно получить работая сервис быстрее) можете оценивать сколько вы можете дать времени программистам на анализ и исправление конкретной проблемы. И это будет обоснованная цифра, а не абстрактные пара часов.
Прошу прощения, просмотрел в Вашем сообщении iostat.
Вот это:
Если есть косяк в программе, то его и нужно исправлять, а не прикручивать подпорки в виде параметров gc, так как в следующий раз подпорки могут не помочь, а времени на реакцию может и не остаться.
Ее ставлю не я. Она есть априори и задача интервьюера эту разницу минимизировать. А суть этой разницы в том, что любое интервью или в широком смысле оценка чьих то знаний — это всегда стресс, который в обычной работе отсутствует полностью (могут быть в работе конечно и другие стрессы, но речь не об этом).
Видите сколько инструментов и направлений анализа вылезло из простой на первый взгляд задачи? А все из-за того, что нет требований к тому, что нужно получить и нет никакой информации о среде запуска и т.д. Все, что необходимо даже для начала решения необходимо выспрашивать отдельно, а это с моей точки зрения большой минус…
Диск и сеть могут давать точно такие-же паузы, так что тут не все так очевидно. Опять-же вместо того, чтобы просто потыкать профайлером приходится еще анализировать окружение, алгоритмы работы приложения и многое другое. Не слишком ли размыта задача и критерий признания ее решенной?
Это порочная практика, так как она не решает проблемы, а лишь маскирует ее и по закону Мерфи проблема выстрелит в полный рост тогда, когда ее будут ждать меньше всего.
P.S. Возможно, конечно, что задача кажется мне столь неопределенной из-за того, что я программист не на Java, а на С++ и всего-лишь не знаю Java-инструментов…
Ответ конечно получился не для собеседования :), но в жизни скорее это будет так. Что-бы проводить оптимизации нужно понимать, что делает программа, так как без этого не понятно куда прикладывать профайлер, непонятно, нужен ли он вообще (может быть сервер перегружен на все 146% или приложение активно читает/пишет на диск, а диски не справляются или проблема в сети по которой приложение получает какие-то данные или ...), а может быть в программе сортируются гигабайты пузырьковой сортировкой и нужные оптимизации на самом деле алгоритмические, которые без анализа алгоритма не сделать.
— Те у Вас даже требований по необходимой производительности/отзывчивости системы нет? (возможный вариант продолжения разговора).
На мой взгляд, единственно верный вариант продолжения разговора в случае вопроса о медленности — это узнать критерий этой самой медленности и условия измерения. И только после этого можно приступать к анализу ибо велик риск варианта, что не устраивает latency, а до сервиса ~13000км по кратчайшему пути в трехмерном пространстве, что даже еще не изобретенная нейтринная связь не поможет получать результат быстрее чем за 44мс :)
Во первых мало что из коробки умеет так делать, во вторых такая сегментация данных иногда нежелательна, а иногда и невозможна, но самая большая проблема в том, что неэффективность нарастает с ростом расстояния(все проблемы от скорости света) и в результате многополосная передача может перестать давать тот-же эффект из-за взаимовлияния потоков друг на друга.
По этому сейчас вполне развиваются оба направления и то, как передавать данные параллельно и то, как увеличить эффективность передачи в каждом соединении.
Прошу прощения за нескромный вопрос, но, например?
Если продолжить логику, то среди обывателей прошло незамеченным подавляющее большинство событий статьи, но она почему-то существует…
Интерфейс сокетов (Berkeley sockets), который вначале стал стандартом де-факто, а потом переродился в сокеты стандарта POSIX.
Если у нас 10G между ЦОДами в соседних комнатах, то перекачивать данные на такой скорости не проблема, но если ЦОДы в разных городах, то получить ~10G полезной скорости становится задачей нетривиальной. Вот и получается в результате, что записать диски (ленты) и перевести их на другую площадку грузовиком или самолетом может оказаться быстрее, даже в случае если это репликация.
Но, тем не менее, это не мешает использовать данный метод и крупным компаниями для передачи данных между датацентрами :)
К сожалению, я вынужден остаться голословным, так как этот удивительный для меня факт я узнал из личной беседы с европейскими коллегами о смысле жизни в системах передачи данных.
Я изначально где-то час исследовал их сайт на предмет сравнений, описаний и т.д., но только после Вашей ссылки заметил надпись «Free Trial» прямо в меню основного сайта.