Здравствуйте.

Делаю выгрузку данных список большой и очень грузить страницу. Хотелось бы спросить есть ли пути по оптимизации. На данный момент выгрузка идет через пхп модуль который запрашивает процедуру SqlServer.

vklekomilесть ли пути по оптимизацииЧто именно хотите оптимизировать, что устраивает в существующей реализации и что не устраивает?


Спасибо за участие в обсуждении, на данный момент при обновлении страницы расходуется много времени, время загрузки минута.
Это очень долго хочется по быстрее.

Код для выборки из БД:




Попробовал добавить индекс в таблицу но не помогло. Посоветуйте что нибудь из своего опыта.

Спасибо.

vklekomil,

Под временем загрузки Вы подразумеваете промежуток между отдачей запроса к вебсерверу и до окончания рендеринга ответной страницы или что-то другое? В любом случае, следует уточнить, сколько времени выполняется каждый этап. Поставьте вывод меток времени в самом начале страницы, до коннекта к БД, перед и после sqlsrv_query и после окончания цикла while. Это позволит оценить скорость обработки на стороне сервера. На стороне клиента временные затраты можно посмотреть в файрбаге, например.

Теперь смотрим на запрос SELECT. Вы запрашиваете все поля из таблицы, а используете только два. В таблице реально только два поля, или их больше? Все данные, возвращенные в результате запроса, будут сохранены в памяти. Есть смысл ограничить выборку только нужными полями. Меньше данных - меньше затрат ресурсов. Вообще, за "select *" могут и тухлыми помидорами закидать :-)

Далее (или это следовало уточнить в первую очередь), а много ли записей в таблице?
Обратите внимание, что на каждой записи вызывается iconv. Обилия использования этой функции можно избежать двумя путями. Можно хранить в БД данные в нужной кодировке, а можно конвертнуть уже собранный, полный список опций, сохраняя его в переменной или взяв из буфера вывода. Конечно, первый вариант (без преобразования) предпочтительнее. Разумеется, я не думаю что этот вызов iconv вносит сильные тормоза. Однако, он есть и от него можно избавиться, если хотите.

Если записей в таблице ОЧЕНЬ много - сотни, тысячи... Ну, фиг знает, как пользователь может работать с таким списком... да оставим эту головную боль пользователю. Однако, браузеру придется формировать HTML-документ для отображения по полной программе и тут много зависит уже от самого браузера, от плагинов, свободных ресурсов компьютера и т.д.

Для начала смотрите, на что уходит эта минута, как она распределяется между этапами формирования страницы - отдельно по серверной части и отдельно по клиентской. А после уж можно будет оценить проблемные места и смотреть в сторону их оптимизации. Ну и дохлый канал передачи данных тоже может вносить свой вклад. Оцените уж и объем передаваемых данных (хтмл-код страницы).

Спасибо, очень познавательно.
На счет SELECT сам уже думал :) если честно данных очень много в таблице и просто выборка прямо с БД относительно долго обрабатывается. Скорее участок уже известен так как выборка из базы долго работает, как оптимизировать выборку с таблицы?

komil,

а так в форме более 10-и selectbox-ов и все загружаются с БД, видимо это тоже дает о себе знать.

vklekomil,

Сам по себе запрос слишком прост, чтоб его оптимизировать. Ну, явно указать только используемые поля, да и на этом и все. Возможно, есть смысл подумать о кешировании. Как часто изменяются данные в таблице? Если это справочник с изменением раз в несколько минут/часов/недель, то есть смысл закешировать селект в готовом виде. Сохранить как файл, например, или в мемкеше. Отдача готового контента из файла будет в тысячи раз быстрее происходить. Ну, над действиями при изменении таблицы придется немного подумать.

Едем дальше.

Селектов много. Они идентичны или разные? Если идентичны - отдали клиенту один селект, а остальное яваскриптом склонировать.

Если селекты разные и с кешированием на стороне сервера уж совсем напряжно, тогда можно посмотреть в сторону динамической их подгрузки. Например, подтягивать их аяксом. В этом случае одновременно пойдут несколько запросов к серверу, которые вполне могут работать параллельно. Впрочем, аяксом можно подтягивать и готовые файлики с кодом селектов. Один момент надо учесть: с кешированием на стороне клиента и на прокси придется разбираться довольно тщательно (или, в крайнем случае, вообще его запретить).

Спасибо огромное за ответ, сегодня начну копать в сторону кэширования, данные там статические и редко меняются так что кэш то что надо будет. Другие списки тоже не часто меняются, можно AJAX-ом но хотелось бы чтобы после не мучили меня а чтобы сами пользователи могли менять данные