SQL એપ VPN પર કેમ ધીમી પડે છે અને શું બેચ કરવું

લોકલ નેટવર્ક પર એક સેકન્ડથી ઓછા સમયમાં દેખાતું ફોર્મ VPN પર પાંચ સેકન્ડ લે છે, જ્યારે એ જ લિંક પર ફાઇલ કોપી પૂરી ઝડપે ચાલે છે. ફરક બેન્ડવિડ્થનો નથી. ફોર્મ જવાબોની શ્રેણીની રાહ જુએ છે અને દરેક પગલે પૂરી રાઉન્ડ ટ્રિપ ચૂકવે છે, જ્યારે ફાઇલ કોપી બાઇટ્સને સતત માર્ગમાં રાખે છે. એક્સેસ લાઇનને અડકતાં પહેલાં એ પ્રતીક્ષાઓ ગણો.

લક્ષણ સ્ક્રીન છે, ક્વેરી નહીં

એ સ્ક્રીનની દરેક ક્વેરી ઝડપી હોઈ શકે અને સ્ક્રીન તો પણ ધીમી રહી શકે, કારણ કે કુલ સમય પ્રતીક્ષાઓનો સરવાળો છે, અમલ સમયનો નહીં. બે મિલિસેકન્ડમાં ચાલતું વિધાન પણ પૂરી રાઉન્ડ ટ્રિપનો ખર્ચ કરે છે જ્યારે ક્લાયન્ટને આગળનું મોકલતાં પહેલાં તેનું પરિણામ મેળવવું પડે. ચાલીસ મિલિસેકન્ડ વિલંબવાળા માર્ગ પર સો આશ્રિત કૉલ કોઈ પણ રેન્ડરિંગ કામ શરૂ થાય તે પહેલાં લગભગ ચાર સેકન્ડ સુધી પહોંચે છે. આ ગણિત પ્રતીક્ષાનું મોડેલ છે, તમારી લિંકનું માપ નહીં.

તેથી સ્પીડ ટેસ્ટ નિર્દોષ લાગે છે. બલ્ક ટ્રાન્સફર થ્રુપુટ માપે છે, વાતોડું ફોર્મ વિલંબ માપે છે, અને VPN એકમાં ઉત્તમ અને બીજામાં સામાન્ય હોઈ શકે. તેથી સ્ક્રીનનું નિદાન કરવું એટલે લિંક નહીં, સ્ક્રીન માપવી.

કંઈ બદલતાં પહેલાં એક વપરાશકર્તા ક્રિયાનો શરૂઆતથી અંત સુધીનો સમય નોંધો. એ સંખ્યા જ એકમાત્ર આધારરેખા છે જે કહી શકે કે પછીનું સુધારણું કામ લાગ્યું કે નહીં.

એક વપરાશકર્તા ક્રિયામાં ક્રમિક પ્રતીક્ષાઓ ગણો

અનુમાન કરવાને બદલે ક્લાયન્ટમાં માપો. psql માં \timing on દરેક વિધાનનો વીતેલો સમય છાપે છે, અને EXPLAIN (ANALYZE, BUFFERS) બતાવે છે કે તે સમયમાંથી સર્વરે ખરેખર કેટલો કામ પર ખર્ચ્યો.

એ બે સંખ્યાઓ વચ્ચેનું અંતર તમારો નેટવર્ક અને ક્લાયન્ટ ઓવરહેડ છે. જો વિધાન બે મિલિસેકન્ડમાં ચાલે અને ક્લાયન્ટ સાઠ નોંધે, તો બાકીના અઠ્ઠાવન મુસાફરી અને સ્થાનિક પ્રક્રિયા છે, અને કોઈ ઇન્ડેક્સ તેને દૂર નહીં કરે. સ્ક્રીન જે દરેક વિધાન બહાર પાડે તેના માટે આ સરખામણી પુનરાવર્તિત કરો અને અમલ સમયને બદલે અંતરોનો સરવાળો કરો.

પરિણામને ક્રમિક પ્રતીક્ષાઓની ગણતરી તરીકે લખો. પછીના બે વિભાગ જે માત્રા ઘટાડી શકે તે આ જ છે, અને આ એ સંખ્યા છે જેના વિશે તમે પુરાવા સાથે દલીલ કરી શકો.

સ્વતંત્ર કૉલ બેચ કરો, આશ્રિત રાખો

બે વિધાન જે એકબીજાનાં પરિણામ વાંચતાં નથી તે સાથે મુસાફરી કરી શકે અને એક વાર ભેગાં થઈ શકે, જે બે પ્રતીક્ષાઓને એક બનાવે છે. બે વિધાન જ્યાં બીજાને પહેલાનું મૂલ્ય જોઈએ તે આમ કરી શકતાં નથી, કારણ કે આશ્રિતતા વાસ્તવિક છે અને બેચ કરવાથી પ્રોગ્રામ જે કરે છે તે બદલાશે. કંઈ ફરી લખતાં પહેલાં કૉલને એ બે ઢગલામાં વર્ગીકૃત કરો, અને દરેક ઢગલાનું કદ તમને કહે છે કે શું શક્ય છે.

સમૂહ આધારિત કાર્ય બેચિંગ કરતાં વધુ સંપૂર્ણ રીતે પ્રતીક્ષાઓ દૂર કરે છે. એક ક્વેરી જે એ પંક્તિઓ પાછી આપે છે જે લૂપ એક-એક કરીને લાવતું હતું તે લૂપ અને રાઉન્ડ ટ્રિપ બંને દૂર કરે છે. પહેલાં લૂપ શોધો, કારણ કે સામાન્ય રીતે તે મોટો લાભ અને સમીક્ષા માટે સરળ ફેરફાર છે.

બેચે હજી પણ ભૂલ સંચાલન અને વ્યવહાર સીમાઓ જાળવવી પડે. અસંબંધિત વિધાનોને એક શબ્દમાળામાં જોડવું સુરક્ષિત ઑપ્ટિમાઇઝેશન નથી, અને જે બેચ નિષ્ફળ વિધાનને સફળ સબમિશન પાછળ છુપાવે છે તે બચાવેલી પ્રતીક્ષાઓ કરતાં વધુ ખરાબ છે.

બેન્ડવિડ્થ ખરીદતાં પહેલાં કનેક્શન ફરી વાપરો

નવું કનેક્શન નામ ઉકેલ, TCP હેન્ડશેક, TLS વાટાઘાટ અને પ્રમાણીકરણનો ખર્ચ કરે છે, અને ઊંચા વિલંબવાળા માર્ગ પર તેમાંથી દરેક પહેલી ક્વેરી ચાલે તે પહેલાં બીજી રાઉન્ડ ટ્રિપ છે. કનેક્શન પૂલ આ ખર્ચ દરેક કૉલે નહીં પણ દરેક પ્રક્રિયાએ એક વાર ચૂકવવા માટે હોય છે.

ADO.NET માં પૂલ કરેલું કનેક્શન બંધ કરવાથી કે નાબૂદ કરવાથી તે નવું ભૌતિક કનેક્શન ખોલવાને બદલે ફરી વપરાશ માટે પાછું આવે છે, તેથી લીક જેવું લાગતું પેટર્ન ઘણી વાર સાચો ઉપયોગ હોય છે. ધારી લેવાને બદલે ચકાસો કે પૂલ ખરેખર વપરાય છે: ભૌતિક કનેક્શનની રચના લોગ કરો, અથવા સ્ક્રીન ચાલતી હોય ત્યારે સર્વર પર સત્રની સંખ્યા જુઓ. SQL પ્રદર્શન માર્ગદર્શિકા પણ રાઉન્ડ ટ્રિપ ઘટાડવા અને વારંવારના એડ હોક કૉલ બેચ કરવા વિશે એ જ કહે છે, સેવા-વિશિષ્ટ ઉદાહરણો સાથે જે તમારે તમારા પોતાના ડિપ્લોયમેન્ટ પર લાગુ કરવા જોઈએ.

પૂલિંગ સેટઅપ ખર્ચ દૂર કરે છે અને ક્રમિક ક્વેરી પ્રતીક્ષાઓને અસ્પૃષ્ટ રાખે છે. તે પોતે સુધારણું નહીં, સ્વચ્છ માપનની પૂર્વશરત છે.

અમલને ડેટાની નજીક ખસેડવાનું તોલો

એપ્લિકેશનને ડેટાબેઝની નજીક ચલાવવાથી ડેટાબેઝ સાથેના ઘણા દૂરસ્થ આદાનપ્રદાન એક જ દૂરસ્થ ડિસ્પ્લે સત્રથી બદલાય છે. વાતોડા ભાર માટે તે મોટો ફેરફાર હોઈ શકે છે, અને તે પ્રદર્શન ફેરફાર જેટલો જ કાર્યાત્મક ફેરફાર છે: સત્ર સંચાલન, એક્સેસ નિયંત્રણ, સૉફ્ટવેર ડિપ્લોયમેન્ટ અને વપરાશકર્તા અનુભવ બધું એપ્લિકેશન સાથે ખસે છે.

કોઈ પણ દિશા ઝડપી છે એમ ધારવા પહેલાં વાસ્તવિક ઇન્ટરફેસ અને તે જે ડેટા સ્થાનાંતરિત કરે છે તે માપો. દૂરસ્થ ડેસ્કટોપ સત્ર પિક્સેલ ખસેડે છે, અને ગાઢ ગ્રાફિક્સવાળી સ્ક્રીન એ જ માર્ગ પર તેની જગ્યાએ આવેલી ક્વેરીઓ કરતાં ખરાબ ચાલી શકે, ખાસ કરીને જ્યારે ક્લાયન્ટ સતત ફરી દોરે.

પછી મૂળ ક્રિયા પુનરાવર્તિત કરો અને ત્રણ સંખ્યાઓ સરખાવો: ક્રમિક પ્રતીક્ષાઓ, પરિણામનું પ્રમાણ અને શરૂઆતથી અંત સુધીનો પૂર્ણ થવાનો સમય. જે સુધારો માપેલા વપરાશકર્તા કાર્યને બદલે અને સાથે ડેટાની સચ્ચાઈ તથા એક્સેસ નીતિ જાળવે છે તે જ રાખવા લાયક છે.