Here’s my opinion: You can do this however you want. It’s your website. Most of my work has been for other people. When I was working on my own startup it made me honest. Nothing was dynamic. The rationale was “do everything ahead of time so users never wait for anything and the site has 100% uptime”.
So for your usecase - why make your users pay the price of your hashmap lookup? Why not publish/rewrite your content to the “right” site structure ahead of time? Sure, nginx with openresty / lua can be a super fast appserver. But boring solutions beat clever every time. My two cents, Peter Sent from my iPhone > On Mar 23, 2019, at 8:17 PM, Hemant Bist <[email protected]> wrote: > > Hi, > I want to know if this a right way to make the change ( or if there is a > better /recommended method). So far we have only tweaked the configuration of > nginx which scales very nicely for us The change I need to do looks like a > common case to me. > > Currently our urls map directly to the local dir structure > e.g. the url /foo/10000/1234/9999/my.jpg is local file > /var/www/html/foo/10000/1234/9999/my.jpg so > > Now the url /foo/first/second/third/my.jpg will map to > /newfoo/new_first/new_second/new_third/my.jpg > where newfoo folder is done by lookup of a static Hash_map/table of about > 10000 to 20000 entries. > new_first (new_second and new_third) are calculated by some arithmatic > operation on first(second and new third). > > My plan is: a) pass all handling to a lua script that will do > internal_redirect to the correct physical url... And do a load test to make > sure that is not too much performance hit. [ I haven't implemented it, but > it looks possible from the examples I have looked at so far] > > Best, > HB > > > _______________________________________________ > nginx mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
