Чтобы сделать URL-адрес более дружелюбным (конечно, могут быть и другие причины), многие сайты используют перезапись URL-адресов, например http://www.cnblogs.com/life . Такое переопределение URL-адресов обычно выполняется в asp.net. *.* необходимо сопоставить с aspnet_isapi.dll (C:WINDOWSMicrosoft.NETFrameworkv1.1.432aspnet_isapi.dll) в IIS, затем выполнить соответствующую настройку в web.config и, наконец, написать соответствующую программу обработки. , в большинстве случаев мы поступаем именно так, и Боке Пак делает то же самое, и вроде бы никаких проблем не возникает.
Тем не менее, в Боке-парке уже давно существуют проблемы с производительностью. Дуду и многие друзья в саду также придумали множество способов улучшить производительность и добились отличных результатов, но это все еще не идеально, потому что я тоже хочу внести свой вклад. Мне очень нравится BoKe Park. Я многому научился в саду. В основном я читал вышеуказанные статьи утром, днём и вечером, пока вчера вечером друг из технической группы не задал мне вопрос об URL. переписывая, я вдруг понял, что BoKe Park Проблема с производительностью, скорее всего, вызвана перезаписью URL-адреса.
Вопрос моего друга таков:
http://www.wodecity.com/food и http://www.wodecity.com/food.html (эта ссылка теперь недействительна) обнаруживают одну и ту же страницу http://www.wodecity посредством переписывания URL-адреса .com. /page/food.aspx оба используют одну и ту же программу обработки. Единственная разница заключается в том, что для обработки адресов без расширений, таких как http://www.wodecity.com/food , он должен сопоставить *.* с aspnet_isapi dll. , а http://www.wodecity.com/food.html сопоставляет *.html с aspnet_isapi.dll. Было обнаружено, что производительность http://www.wodecity.com/food.html выше, чем http:/. / www.wodecity.com/food в десять-двадцать раз лучше. Он проверил это с помощью loadrunner. Результат его очень расстроил. Я тоже вначале удивился. В чем разница между *.* и *.html? *.* означает, что все запросы к странице, включая css-файлы и все файлы изображений, обрабатываются написанным им обработчиком перезаписи URL-адресов. , *.html не существует, это просто запрос. На странице http://www.wodecity.com/food должно быть более 20 изображений. При запросе страницы необходимо использовать URL. переписать обработчик одновременно не может быть медленно при обработке такого количества картинок? Что делать? Поскольку они хотят использовать URL-адреса типа http://www.wodecity.com/food , что более дружелюбно, им все равно придется использовать *.*. Подумав некоторое время, я посоветовал ему разрешить использовать вашу программу переписывания URL-адресов. не обрабатывать эти файлы изображений. Вот и все, как это сделать? Есть два метода: метод 1: преобразовать папку, в которой хранятся изображения, в виртуальный каталог, а затем переместить сопоставление виртуального каталога *.*, чтобы его программа перезаписи URL-адресов не обрабатывала файлы изображений. к хранению других файлов, не требующих программы перезаписи URL-адресов, следует относиться так же, как и к папке с изображениями. Метод 2 заключается в создании нового сайта, например, с использованием http://img.wodecity.com/ для хранения файлов изображений. то же самое. Да, все это означает, что ваш обработчик перезаписи URL-адресов не обрабатывает эти файлы изображений.
Все было в порядке. Он сказал мне, что поедет в компанию, чтобы протестировать это сегодня утром.
Чтобы проверить свою идею, я также написал программу для ее проверки. Производительность также отличается почти в 20 раз. Хорошо, моя идея верна.
Возможно, мои идеи или результаты тестов неверны, ПК приветствуется здесь. MSN: cxbsky#hotmail.com.
Я также надеюсь, что эта статья будет полезна для решения проблем с производительностью Blog Park, поскольку проблемы в Blog Park могут быть очень похожи на проблемы на сайте моего друга.
ps: Когда я закончил писать эту статью, я спросил своего друга о результатах теста, и он сказал: «Изначально он мог поддерживать только 50 человек. Теперь это не проблема для более чем 700 человек».
http://www.cnblogs.com/csky/archive/2006/08/09/urlrewrite.html