Para tornar o endereço URL mais amigável (é claro que pode haver outros motivos), muitos sites usam a reescrita de URL, como http://www.cnblogs.com/life . Essa reescrita de URL geralmente é feita em asp.net. *.* deve ser mapeado para aspnet_isapi.dll (C:WINDOWSMicrosoft.NETFrameworkv1.1.432aspnet_isapi.dll) no IIS, em seguida, faça a configuração correspondente em web.config e, finalmente, escreva o programa de processamento correspondente , na maioria dos casos fazemos assim, e o Boke Park faz da mesma forma, e não parece haver nenhum problema.
Porém, há muito tempo que há problemas de desempenho no Boke Park, Dudu e muitos amigos da horta também pensaram em muitas maneiras de melhorar o desempenho e alcançaram ótimos resultados, mas ainda não é o ideal. Gosto muito do BoKe Park. Aprendi muito no jardim. Basicamente, li os artigos acima de manhã, ao meio-dia e à noite. Só ontem à noite um amigo do grupo técnico me fez uma pergunta sobre URL. reescrevendo que de repente percebi que o problema de desempenho do BoKe Park é provavelmente causado pela reescrita de URL.
A pergunta do meu amigo é esta:
http://www.wodecity.com/food e http://www.wodecity.com/food.html (este link agora é inválido) localizam a mesma página http://www.wodecity por meio da reescrita de URL .com. /page/food.aspx , ambos usam o mesmo programa de processamento. A única diferença é que para processar endereços sem extensões como http://www.wodecity.com/food , ele deve mapear *.* para aspnet_isapi. e http://www.wodecity.com/food.html mapeia *.html para aspnet_isapi.dll Foi descoberto que o desempenho de http://www.wodecity.com/food.html é melhor que http:/. / www.wodecity.com/food é dez a vinte vezes melhor. Ele testou com loadrunner e ficou muito deprimido com o resultado. Também fiquei surpreso no início. Qual é a diferença entre *.* e *.html *.* significa que todas as solicitações da página, incluindo arquivos css e todos os arquivos de imagem, são processadas pelo manipulador de reescrita de URL escrito por ele? ., *.html não existe, é apenas uma solicitação. O problema surge aqui A página http://www.wodecity.com/food deve ter mais de 20 fotos. reescrever o manipulador ao mesmo tempo. Não pode ser lento ao processar tantas fotos? O que fazer? Como eles querem usar URLs como http://www.wodecity.com/food , que é mais amigável, eles ainda precisam usar *.*. Depois de pensar um pouco, eu disse a ele para deixar seu programa de reescrita de URL. não processar esses arquivos de imagem. É isso, como fazer? Existem dois métodos: Método 1, converta a pasta onde as imagens estão armazenadas em um diretório virtual e, em seguida, mova o mapeamento do diretório virtual *.*, para que seu programa de reescrita de URL não processe os arquivos de imagem. o armazenamento de outros arquivos que não requerem um programa de reescrita de URL deve ser tratado de forma semelhante à pasta de imagens. O método 2 é criar um novo site, como usar http://img.wodecity.com/ para armazenar arquivos de imagem. o mesmo. Sim, tudo significa que seu manipulador de reescrita de URL não processa esses arquivos de imagem.
Estava tudo bem. Ele me disse que iria à empresa testar esta manhã.
Para verificar minha ideia, também escrevi um programa para testá-la hoje. O desempenho também é quase 20 vezes diferente. Bom, minha ideia está correta.
Talvez minhas idéias ou resultados de testes estejam errados, PK é bem-vindo aqui. msn:cxbsky#hotmail.com.
Também espero que este artigo seja útil para os problemas de desempenho do Blog Park, porque os problemas no Blog Park podem ser muito semelhantes aos do site do meu amigo.
ps: Quando terminei de escrever este artigo, perguntei ao meu amigo sobre o resultado do teste e ele disse: "Originalmente só suportava 50 pessoas. Agora não é problema para mais de 700 pessoas."
http://www.cnblogs.com/csky/archive/2006/08/09/urlrewrite.html