OK Hadi, good luck to you too. It sounds to me like you’re falling into the trap of premature optimisation; you’re worrying about serialisation or network overhead before you’ve even got the data model straight. Remember what Donald Knuth said, a guy who knows his stuff more than most [1] -
"We should forget about small efficiencies, say about 97% of the time: premature optimisation is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
Until you’ve done some testing, it’s safer to assume you’re in the 97%, and quite likely a waste of time to do optimisations for the 3% without having found out for sure. Purely from what you’ve written I think you might be focusing on the wrong thing. But of course it’s your call, you might have other requirements or factors we don’t know about. Best of luck.
Cheers Igor
Thank You Igor...
your message will help me,
yeah I will try to test them but I think redis is slower than Shared Dict because of network communication requirement...
yeah json format is pretty enough but also breaking info object as compound keys can help us like:
ngx.shared.human:set("007_name","james")
ngx.shared.human:set("007_family","bond")
ngx.shared.human:set("007_age","40" or 40) in this way, there is no any Serialization/Deserialization,so I think it's faster! good luck...
all the best,
HadiOn Saturday, April 27, 2019 at 1:38:50 PM UTC+4:30, Igor Clark wrote: Hi Hadi,
Of course it depends on your app, but if you can structure it so that you store the table as a json string, fetch it at the beginning of the request, do whatever manipulations you need in memory, then json encode it and store it when you’re done, you might well find cjson is fast enough not to cause any problems. It’s pretty fast. If so then you have the benefit of the atomic shared dict and can carry on with the nice simple programming model it provides. Personally I would try it rather than assume it’ll be too slow - it might be fine, and if it’s not, then at least you’ll know for sure.
To paraphrase Joe Armstrong - first make it work, then make it elegant, and only then try to make it faster if you really need to. In this case, given that you want to take advantage of the shared dict and its atomicity (which are pretty darn good), I’d say that means: choose the appropriate data model for the environment, code it as simply and cleanly as possible, and if you *then* find you’re having performance problems with the encoding and decoding, try out different json libraries, try tweaking the structure of the data, or the access pattern to speed things up. If that still doesn’t work, maybe the shared dict isn’t the right way, maybe you should be using redis or something like that. Either way, making a simple test case and whacking it with a load test tool like siege or httperf (or even ab, though remember it lies) will show you pretty quickly whether it’ll do what you need it to do. It’ll have been worth it either way.
I often find myself trying to second-guess which route will be better, so I can avoid spending the time having to come back and do something again if route #1 doesn’t work out. In one way that makes a lot of sense - but just as often it turns out a lot better to try out the simplest realistic test of both routes and measure, because then you know, so you’re not relying on intuition and the net time and effort gain is usually pretty good. (Obviously over time intuition improves based on all the testing, so in the long run I find it also helps me not having to test *quite* so much :-))
Cheers Igor
.
|
