మాట్లాడే SQL యాప్ VPN ద్వారా ఎందుకు నెమ్మదిగా వెళ్తుంది మరియు ఏమి బ్యాచ్ చేయాలి
వంద ఆధారిత క్వెరీలను పంపే స్క్రీన్ రౌండ్ ట్రిప్‌ను వంద సార్లు చెల్లిస్తుంది. నిరీక్షణలను లెక్కించండి, స్వతంత్రమైనవి బ్యాచ్ చేయండి, తర్వాత అమలును తరలించండి.
స్థానిక నెట్‌వర్క్‌లో ఒక సెకనులోపు తెరుచుకునే ఫారం VPN ద్వారా ఐదు సెకన్లు తీసుకుంటుంది, అదే లింక్‌పై ఫైల్ కాపీ పూర్తి వేగంతో నడుస్తుంది. తేడా బ్యాండ్‌విడ్త్ కాదు. ఫారం సమాధానాల క్రమం కోసం వేచి ప్రతి అడుగులో పూర్తి రౌండ్ ట్రిప్ చెల్లిస్తుంది, ఫైల్ కాపీ బైట్లను నిరంతరం ప్రయాణంలో ఉంచుతుంది. యాక్సెస్ లైన్‌ను తాకే ముందు ఆ నిరీక్షణలను లెక్కించండి.
లక్షణం ఒక స్క్రీన్, క్వెరీ కాదు
ఆ స్క్రీన్‌పై ప్రతి క్వెరీ వేగంగా ఉండవచ్చు, స్క్రీన్ ఇప్పటికీ నెమ్మదిగా ఉండవచ్చు, ఎందుకంటే మొత్తం అమలు సమయాల మొత్తం కాదు, నిరీక్షణల మొత్తం. రెండు మిల్లీసెకన్లలో నడిచే స్టేట్‌మెంట్ కూడా, తదుపరిది పంపే ముందు ఫలితం రావాల్సి ఉన్నప్పుడు పూర్తి రౌండ్ ట్రిప్ ఖర్చు చేస్తుంది. నలభై మిల్లీసెకన్ల ఆలస్యం ఉన్న మార్గంలో, వంద ఆధారిత కాల్స్ ఏదైనా రెండరింగ్ పని ప్రారంభమయ్యే ముందు సుమారు నాలుగు సెకన్లకు చేరుతాయి. ఈ గణితం నిరీక్షణకు ఒక నమూనా, మీ లింక్ కొలత కాదు.
అందుకే స్పీడ్ టెస్ట్ అమాయకంగా కనిపిస్తుంది. బల్క్ బదిలీ త్రూపుట్‌ను కొలుస్తుంది, మాట్లాడే ఫారం ఆలస్యాన్ని కొలుస్తుంది, VPN ఒకదానిలో అద్భుతంగా ఉండి మరొకదానిలో సాధారణంగా ఉండవచ్చు. కాబట్టి స్క్రీన్‌ను నిర్ధారించడం అంటే లింక్ కాదు, స్క్రీన్‌ను కొలవడం.
ఏదైనా మార్చే ముందు ఒక వినియోగదారు చర్య యొక్క ప్రారంభం నుండి ముగింపు వరకు సమయాన్ని నమోదు చేయండి. తర్వాతి సరిదిద్దు పనిచేసిందా అని చెప్పగల ఏకైక ఆధారం ఆ సంఖ్య.
ఒక వినియోగదారు చర్యలో వరుస నిరీక్షణలను లెక్కించండి
ఊహించడం కాకుండా క్లయింట్‌లో కొలత చేర్చండి. psql లో \timing on ప్రతి స్టేట్‌మెంట్ గడిచిన సమయాన్ని ముద్రిస్తుంది, EXPLAIN (ANALYZE, BUFFERS) ఆ సమయంలో సర్వర్ నిజంగా పనిపై ఎంత ఖర్చు చేసిందో చూపిస్తుంది.
ఆ రెండు సంఖ్యల మధ్య గ్యాప్ మీ నెట్‌వర్క్ మరియు క్లయింట్ వ్యయం. ఒక స్టేట్‌మెంట్ రెండు మిల్లీసెకన్లలో నడిచి క్లయింట్ అరవై నమోదు చేస్తే, మిగిలిన యాభై ఎనిమిది ప్రయాణం మరియు స్థానిక ప్రాసెసింగ్, ఏ ఇండెక్స్ వాటిని తొలగించదు. స్క్రీన్ పంపే ప్రతి స్టేట్‌మెంట్‌కు ఈ పోలికను పునరావృతం చేయండి, అమలు సమయాలు కాదు గ్యాపులను కూడండి.
ఫలితాన్ని వరుస నిరీక్షణల సంఖ్యగా రాయండి. తదుపరి రెండు విభాగాలు తగ్గించగల పరిమాణం అదే, అది సాక్ష్యంతో వాదించగల సంఖ్య.
స్వతంత్ర కాల్స్ బ్యాచ్ చేయండి, ఆధారితమైనవి ఉంచండి
ఒకదాని ఫలితాన్ని మరొకటి చదవని రెండు స్టేట్‌మెంట్‌లు కలిసి ప్రయాణించి ఒకసారి సేకరించబడతాయి, ఇది రెండు నిరీక్షణలను ఒకటిగా మారుస్తుంది. రెండవదానికి మొదటి విలువ అవసరమయ్యే రెండు స్టేట్‌మెంట్‌లు అలా చేయలేవు, ఎందుకంటే ఆధారత నిజమైనది, బ్యాచింగ్ ప్రోగ్రామ్ చేసే పనిని మారుస్తుంది. ఏదైనా తిరిగి రాసే ముందు కాల్స్‌ను ఆ రెండు కుప్పలుగా విభజించండి, ప్రతి కుప్ప పరిమాణం ఏమి సాధ్యమో చెబుతుంది.
సెట్ ఆధారిత పని బ్యాచింగ్ కంటే సంపూర్ణంగా నిరీక్షణలను తొలగిస్తుంది. లూప్ ఒక్కొక్కటిగా తీసుకున్న వరుసలను తిరిగి ఇచ్చే ఒక క్వెరీ లూప్ మరియు రౌండ్ ట్రిప్‌లను తొలగిస్తుంది. మొదట లూప్‌ను వెతకండి, ఎందుకంటే అది సాధారణంగా పెద్ద లాభం మరియు సమీక్షించడానికి సులభమైన మార్పు.
బ్యాచ్ ఇప్పటికీ దోష నిర్వహణను మరియు లావాదేవీ హద్దులను కాపాడాలి. సంబంధం లేని స్టేట్‌మెంట్‌లను ఒకే స్ట్రింగ్‌గా కలపడం సురక్షిత ఆప్టిమైజేషన్ కాదు, విఫలమైన స్టేట్‌మెంట్‌ను విజయవంతమైన సమర్పణ వెనుక దాచే బ్యాచ్ అది ఆదా చేసిన నిరీక్షణల కంటే అధ్వాన్నం.
బ్యాండ్‌విడ్త్ కొనే ముందు కనెక్షన్లను తిరిగి ఉపయోగించండి
కొత్త కనెక్షన్ పేరు పరిష్కారం, TCP హ్యాండ్‌షేక్, TLS చర్చలు మరియు ప్రామాణీకరణను ఖర్చు చేస్తుంది, అధిక ఆలస్యం ఉన్న మార్గంలో అవి ఒక్కొక్కటి మొదటి క్వెరీ నడవక ముందు మరొక రౌండ్ ట్రిప్. కనెక్షన్ పూల్స్ ఆ వ్యయాన్ని ప్రతి కాల్‌కు కాదు, ప్రతి ప్రక్రియకు ఒకసారి చెల్లించడానికి ఉన్నాయి.
ADO.NET లో, పూల్ కనెక్షన్‌ను మూసివేయడం లేదా dispose చేయడం కొత్త భౌతిక కనెక్షన్ తెరవడం బదులు తిరిగి ఉపయోగం కోసం ఇస్తుంది, కాబట్టి లీక్‌లా కనిపించే నమూనా తరచుగా సరైన వినియోగం. పూల్ నిజంగా వాడుకలో ఉందా అని ఊహించకుండా నిర్ధారించండి: భౌతిక కనెక్షన్ సృష్టిని లాగ్ చేయండి, లేదా స్క్రీన్ నడుస్తున్నప్పుడు సర్వర్‌లో సెషన్ సంఖ్యను గమనించండి. SQL పనితీరు మార్గదర్శిని రౌండ్ ట్రిప్‌లను తగ్గించడం మరియు తరచుగా జరిగే ad hoc కాల్స్ బ్యాచింగ్ గురించి ఇదే విషయం చెబుతుంది, సేవకు నిర్దిష్టమైన ఉదాహరణలతో, వాటిని మీ స్వంత అమరికకు అన్వయించాలి.
పూలింగ్ సెటప్ వ్యయాన్ని తొలగిస్తుంది మరియు వరుస క్వెరీ నిరీక్షణలను తాకకుండా వదిలేస్తుంది. ఇది స్వయంగా సరిదిద్దు కాదు, శుభ్రమైన కొలతకు ముందస్తు షరతు.
అమలును డేటాకు దగ్గరగా తరలించడాన్ని తూకం వేయండి
యాప్‌ను డేటాబేస్ దగ్గర నడపడం చాలా దూర డేటాబేస్ మార్పిడులను ఒకే దూర ప్రదర్శన సెషన్‌తో భర్తీ చేస్తుంది. మాట్లాడే వర్క్‌లోడ్‌కు అది పెద్ద మార్పు కావచ్చు, అది పనితీరు మార్పుతో పాటు కార్యాచరణ మార్పు కూడా: సెషన్ నిర్వహణ, యాక్సెస్ నియంత్రణ, సాఫ్ట్‌వేర్ అమరిక మరియు వినియోగదారు అనుభవం అన్నీ యాప్‌తో పాటు కదులుతాయి.
ఏ దిశ వేగంగా ఉందో ఊహించే ముందు వాస్తవ ఇంటర్‌ఫేస్ మరియు అది బదిలీ చేసే డేటాను కొలవండి. రిమోట్ డెస్క్‌టాప్ సెషన్ పిక్సెల్‌లను తరలిస్తుంది, దట్టమైన గ్రాఫిక్స్ ఉన్న స్క్రీన్ అది భర్తీ చేసిన క్వెరీల కంటే అదే మార్గంలో అధ్వాన్నంగా పనిచేయవచ్చు, ముఖ్యంగా క్లయింట్ నిరంతరం తిరిగి గీస్తున్నప్పుడు.
తర్వాత అసలు చర్యను పునరావృతం చేసి మూడు సంఖ్యలను పోల్చండి: వరుస నిరీక్షణలు, ఫలిత పరిమాణం మరియు ప్రారంభం నుండి ముగింపు వరకు పూర్తి సమయం. డేటా ఖచ్చితత్వాన్ని మరియు యాక్సెస్ విధానాన్ని కాపాడుతూ కొలిచిన వినియోగదారు పనిని మెరుగుపరిచే మార్పే నిలుపుకోదగినది.