प्रति दिन 100 हजार दौरे (डीब्रीफिंग और एक नया प्रयोग)

जीएई डेटा के साथ काम करने की गति के बारे में मेरे आखिरी लेख में, एक ग्राफिकल इंप्रेशन काउंटर को एकीकृत किया गया था। हर कोई काउंटर और खपत सीपीयू संसाधनों का मूल्य देख सकता था। जैसा कि मैंने पहले ही कहा था, काउंटर काफी "भारी" था: यह जो लोड बनाता है वह कैशिंग का उपयोग किए बिना एक पृष्ठ पर एक डेटाबेस से 1000 रिकॉर्ड प्रदर्शित करने के बराबर है।

काउंटर प्रयोग बहुत उपयोगी निकला, और इसके परिणाम मेरे लिए कुछ अप्रत्याशित हैं (समान आईपी पते से अनुरोधों से अलग)। मैं प्रयोग के परिणामों को साझा करना चाहता हूं और पहले से की गई गलतियों को ध्यान में रखते हुए एक नया प्रयोग करना चाहता हूं। वैसे, नए ग्राफिक काउंटर का स्रोत कोड सभी के लिए उपलब्ध है और लेख में दिया गया है।



क्वेरी अनुसूची



प्रति सेकंड 7 अनुरोधों पर (शाम को मुख्य रूप से हैबर का मुख्य पृष्ठ खोलते हैं)। दिन में, मुझे लगता है कि यह आंकड़ा प्रति सेकंड 10 अनुरोधों तक बढ़ जाता है।

सीपीयू समय ग्राफ



इस तरह के एक अप्रिय क्षण को ग्राफ गतिविधि की कमी के रूप में पकड़ लेता है। इस समय, लेख मुख्य पृष्ठ पर था, लेकिन चित्र दिखाई नहीं दिए, क्योंकि संसाधनों की मुफ्त सीमा समाप्त हो गई थी। सुबह स्थिति को ठीक किया गया।

पहले दिन की खपत



10 बजे तक एमसीके में संसाधन की खपत नहीं होती है (10 बजे के बाद से संसाधन काउंटर रीसेट हो जाते हैं)। 10 घंटे तक, लगभग उसी का उपयोग किया गया था। कुल लगभग 150 हज़ार अनुरोध और 500 एमबी ट्रैफ़िक (स्थैतिक चित्र के लिए अनुरोधों का हिस्सा, लेकिन वे बहुत छोटे हैं)।

दौड़ने वाले अधिकारियों की संख्या

दुर्भाग्य से, गलती से मैंने स्क्रीन को रनिंग इंस्टेंस के साथ हटा दिया। प्रति सेकंड 6 आगंतुकों के साथ, 16 उदाहरण लॉन्च किए गए (यह अधिकतम है जो मैंने रिकॉर्ड किया है)।

निषेध अनुरोध ???



और यहाँ सबसे दिलचस्प है। कुछ समय बाद, एक समस्या उत्पन्न हुई: लगभग हर 5 वें अनुरोध को औसत से 5-10 गुना अधिक (औसतन, 0.5 सेकंड के लिए लोड किया गया काउंटर) निष्पादित किया जाना शुरू हुआ। शुरुआत में, कई यात्राओं के साथ भी, यह नहीं देखा गया था। अब तक स्थिति नहीं बदली है, जब बहुत कम दौरे हुए थे।

इन त्रुटियों की व्याख्या कैसे करें? विकल्प:

1. अनुरोध को गर्म करें। नहीं, चूंकि उदाहरण के लिए उतराई के लिए पर्याप्त समय नहीं हुआ है (उदाहरण के लिए, इस ग्राफ में 3 गलत अनुरोधों के बीच का समय एक मिनट से भी कम है)।
2. एक ही कुंजी के साथ भंडार में रिकॉर्ड का एक साथ संशोधन। नहीं, क्योंकि अनुरोधों के बीच 10 सेकंड से अधिक समय बीत चुका है।
3. आवेदन अप्रभावी के रूप में सीमित था।

आखिरी बचता है। इस तथ्य के बावजूद कि, औसतन, अनुरोध 1 सेकंड (लगभग 0.5 सेकंड) से कम समय में पूरा हो गया था। अनुप्रयोग अक्षमता का निर्धारण करने के लिए एल्गोरिथ्म का खुलासा नहीं किया गया था, इसलिए कुछ विशिष्ट कहना मुश्किल है ...

ईमानदारी से, मेरे लिए, ये त्रुटियां एक रहस्य हैं।

समस्या हल करना

यदि समस्या वास्तव में है कि आवेदन अक्षम के रूप में सीमित था, तो समस्या को नए काउंटर कोड (org.toyz.litetext पहले इस्तेमाल किया गया था) के साथ दोहराया नहीं जाएगा, जो लगभग 7 गुना तेजी से चलता है। ड्राइंग बहुत सरल है, लेकिन काफी प्रभावी है (कोड नीचे है - आप इसे अपनी वेबसाइट पर उपयोग कर सकते हैं)।

दूसरा संस्करण:

public final class DynamicImage
{
//
private static final String FOLDER = "resources" ;

private static Image backgroundImage;

private static final Map< String , Image> imageTable = new Hashtable < String , Image>();

static
{
try
{
backgroundImage = makeImage( "appengine.png" );

imageTable.put( "1" ,
makeImage( "1.png" ));
imageTable.put( "2" ,
makeImage( "2.png" ));
imageTable.put( "3" ,
makeImage( "3.png" ));
imageTable.put( "4" ,
makeImage( "4.png" ));
imageTable.put( "5" ,
makeImage( "5.png" ));
imageTable.put( "6" ,
makeImage( "6.png" ));
imageTable.put( "7" ,
makeImage( "7.png" ));
imageTable.put( "8" ,
makeImage( "8.png" ));
imageTable.put( "9" ,
makeImage( "9.png" ));
imageTable.put( "0" ,
makeImage( "0.png" ));

imageTable.put( "(" ,
makeImage( "leftBracket.png" ));
imageTable.put( ")" ,
makeImage( "rightBracket.png" ));
}
catch (IOException exception)
{
throw new RuntimeException(exception);
}
}

public Image drawText( String text,
Anchor anchor,
long backgroundColor)
{
if ( null == text)
throw new ArgumentNullException( "text" );

if ( null == anchor)
throw new ArgumentNullException( "anchor" );

Collection<Composite> compositeCollection = new ArrayList <Composite>();

// background
compositeCollection.add(ImagesServiceFactory.makeComposite(backgroundImage,
0,
0,
1f,
Anchor.TOP_LEFT));

int xOffset = 0;

for ( int pos = 0; pos < text.length(); pos++)
{
String symbol = Character.toString(text.charAt(pos));

if (!imageTable.containsKey(symbol))
continue ;

Image image = imageTable. get (symbol);

compositeCollection.add(ImagesServiceFactory.makeComposite(image,
xOffset,
0,
1f,
anchor));

xOffset += image.getWidth();
}

return ImagesServiceFactory.getImagesService().composite(compositeCollection,
backgroundImage.getWidth(),
backgroundImage.getHeight(),
backgroundColor);
}

private static Image makeImage( String imageName)
throws IOException
{
InputStream inputStream = null ;
ByteArrayOutputStream outputStream = null ;

try
{
String filePath = FOLDER + File .separatorChar + imageName;
inputStream = DynamicImage. class .getResourceAsStream(filePath);

if ( null == inputStream)
throw new IllegalStateException( "filePath=" + filePath);

outputStream = new ByteArrayOutputStream();

int length;
byte [] buffer = new byte [1024];

while ((length = inputStream.read(buffer,
0,
buffer.length)) > 0)
{
outputStream.write(buffer,
0,
length);
}

outputStream.flush();

return ImagesServiceFactory.makeImage(outputStream.toByteArray());
}
finally
{
if ( null != inputStream)
inputStream.close();

if ( null != outputStream)
outputStream.close();
}
}
}

* This source code was highlighted with Source Code Highlighter .

मैं समुदाय से प्रयोग में भाग लेने के लिए कहता हूं। मैं इस लेख में परिणामों की रिपोर्ट करूंगा।

प्रयोग के परिणामों ने मुझे खुश कर दिया! आधे दिन के लिए, काउंटर को लगभग 100 हजार लोगों द्वारा खोला गया (जैसा कि अपेक्षित था)। उसी समय, 1 जीबी ट्रैफ़िक खर्च किया गया था (ठीक है, कम से कम मैंने तस्वीर को कम कर दिया, अन्यथा यह 3% सीमा में फिट नहीं होता है:)



इस मामले में, रनिंग अधिकारियों की अधिकतम संख्या 9 पीसी थी। (प्रति सेकंड 8 अनुरोधों पर):



और इस क्षण के अनुरोधों को बिना किसी देरी के निष्पादित किया गया। यहाँ लॉग से एक अंश है:



इसके अलावा, प्रत्येक अनुरोध ने डेटाबेस को लिखा और आईपी पते की विशिष्टता को सत्यापित किया। यह मुफ़्त के लिए बाहर आया था! पर्याप्त मुक्त संसाधन!

निष्कर्ष

उचित उपयोग के साथ, GAE एक जबरदस्त भार का सामना कर सकता है। Google ने वास्तव में कई सपने देखे थे: केवल वास्तव में उपयोग किए गए संसाधनों के लिए भुगतान करना (सब कुछ उचित है: यदि आप इसका उपयोग नहीं करते हैं, तो आपको कुछ भी भुगतान नहीं करना होगा)। हमें केवल ऐसी सेवाएँ बनाने की आवश्यकता है जो इतने सारे आगंतुकों को आकर्षित करें।