I'm nearing end of development of a site, and am offloading images, scripts and fonts to a second server pool. Currently, the static pool is io.mydomain.com and the site itself is mydomain.com (www.* redirects to naked domain).
It's been well documented* that using a separate DNS lookup for static assets improves performance as it doubles concurrent asset downloads, but I'm trying to find the highest performance method of achieving this?
My question is this: from a DNS perspective, is it better to use a subdomain (TLD lookup, domain lookup, subdomain lookup), like Apple does (images.apple.com), or a separate domain (TLD lookup and domain lookup) like Yahoo and Microsoft do (yimg.com and c.s-microsoft.com)? Is there much of a difference between the two or is it negligible?
*https://developer.yahoo.com/performance/rules.html
Presuming that nothing is cached, there would be a infinitesimally small improvement brought about by having the same top level domain.
For the same top level domain queries the queries would go something like
query root servers for .com. name servers
query .com. name servers for .example.com. name servers.
query .example.com. name servers for www.example.com
query .example.com. (cached address) name servers for io.example.com.
For separate domains it would be
query root servers for .com. name servers
query .com. name servers for .example.com. name servers.
query .example.com. name servers for www.example.com
query .com.(cached address) name servers for .xmpl.com. name servers.
query .xmpl.com. name servers for io.xmpl.com
Once that first query was made - as long as you hadn't set incredibly short expiry - the client would never need to look them up again.
At the very best, you might shave a millisecond from the very first query. After that it changes nothing.
It isn't even remotely worth thinking about! there are so many other places where you will transiently loose that sort of time.
Related
Imagine the following scenario:
A customer is using AWS CloudFront and is serving a site that expects and ordinarily receives no query strings. Essentially the entire site is static and the CDN is purely enabling performance by caching and distributing the content.
On occasion, we as a solutions provider for the customer, wish to refresh any page (JavaScript) on the customer site and within that refresh request, append a query string with parameter values that will be unique to each visitor. This event will only happen once per visitor in a set period - say for argument's sake, 365 days.
With the existing cache configuration, the cache can be busted and performance affected when x new visitors (x being sizeable) come to the site and trigger the refresh event.
I wish to understand how we can configure the cache key to send any page request with our query string included, to the origin but not store it in the cache once served. The cache should only store the page when the static URL is requested not the dynamic URL (dynamic because our query string has been included) when it is requested.
Any assistance would be appreciated.
You can specify which query strings to be included in the cache key or not, have a look at this document https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/controlling-the-cache-key.html#cache-policy-query-strings. With include specified query strings cache behaviour cloudfront will send the request to origin with query strings and than you probably want your origin to send cache header as no-cache so cloudfront will not cache.
We are designing an LDAP schema (specifically for OpenDJ) and we primarily need to be able to search on the mail attribute. We don't need to do a substring search as the user would provide the whole email address when they log in.
We already have an index on the mail attribute. However we are also considering to sub-divide the user directory by the first letter of the email address as well (so all users with an email address that starts with the letter A would be in an ou=A subdirectory under ou=users. The only value I can see in doing this is that when we do searches for a user by email, we can limit the baseDN of the search, thus reducing the scope of the search to approximately 1/26 of the entire directory.
My primary question is, does limiting the baseDN of an LDAP search like this provide any improvement on performance if the attribute already has an index? Do indexes take into account the baseDN, or are they indexed over the whole directory?
A secondary question, if I'm allowed, is there any other usage for splitting the users directory by first letter (or any other arrangement) other than providing a more specific baseDN when searching?
What you are thinking about seems like premature optimization when you don't even know if you have a performance issue.
Also, indexes and processing a query is not a standard element of LDAP, it's an implementation detail of the technology you are using.
In OpenDJ, an index is configured and maintain for a whole database backend.
The cost of a lookup in the email equality index and returning a single entry is the same whether you have 1 entry or 1 billion entries.
I have more than 20 years of experiences with LDAP and directory services, I've never seen any directory structured with splitting entries by the first letter of an attribute.
I once (and only once) encountered a problem similar to the one you're anticipating -- essentially you've got so many records that searching for a record creates an unacceptable user experience. In my case, there were over a million customers in the directory. What is now a rather old iteration of IBM's Tivoli Directory Server had several bugs that meant searching the directory took minutes to accomplish (indexes or no indexes). No one wants to wait minutes to log in and pay their bill! And we were constrained to using IBM's LDAP server.
In that case, I used the e-mail address used as the naming attribute when the account was created and never searched the directory. I.E. I'm cn=lisa#example.com,ou=customers,o=example within the directory. When I log in with lisa#example.com, the site programmatically formulates the bind DN as "cn=" + userInput + ",ou=customers,o=example" and validates the supplied password instead of searching for my account.
So I'm a Windows / Network admin, have been for 2 years, but today I had a question that I didn't really know the answer to.
Say I do a nslookup, and the query retrieves 2 A records.
Which A records does say, a browser use?
If we do an nslookup for google.com, we get many responses. Is there a preferred address that windows uses? Is there any deciding factors?
If you have three A records in example.com a,b,c
The first query will retrieve a.example.com
the second b.example.com
the third c.example.com, and the next will get a.example.com again.
This is known as round-robin DNS
I have a collection of 100s of machines in SCCM 2012
I have a short list of machines that I need to add to another collection, is there any way using the search bar at the top of the collection display view to have multiple terms? I've tried commas and semi colons. These are machine names, and I cannot create a new query or collection as the machines have no information that seperates them in SCCM, they are seperated by which building they are in, which SCCM is not aware of.
Does this help at all?
Tips for Finding Objects in the Configuration Manager 2012 Console
In the search bar you are very limited.
But you mention you have no information to separate them.
IP range? Operation Unit in AD?
Worse case you need create a collection with direct add's.
Very time consuming, I only use them for test cases (so a few ~10 max machines).
FJ
I would suggest you use AD Groups to collect the required machines together and target those via a query rule in the collection membership (in collection properties).
You can use the below WQL in the query text input box by adding your own (short, not FQDN) domain and AD Group name below
select SMS_R_SYSTEM.ResourceID,
SMS_R_SYSTEM.ResourceType,
SMS_R_SYSTEM.Name,
SMS_R_SYSTEM.SMSUniqueIdentifier,
SMS_R_SYSTEM.ResourceDomainORWorkgroup,
SMS_R_SYSTEM.Client from
SMS_R_System where
SMS_R_System.SecurityGroupName = "<Enter Domain>\\<Enter AD Group Name>"
This does assume that AD Discovery is configured properly in your site. You should also be aware that there is a delay in SCCM reflecting changes in AD Groups.
Additionally, if you have a relatively recent Domain Functional Level, you can utilise Dynamic Groups to auto-populate the groups based on AD attributes. I haven't got this available yet, but it looks set to hot-rod SCCM management somewhat when it becomes available.
Best wishes...
We have a fantasy football application that uses memcached and the classic memcached-object-read-with-sql-server-fallback. This works fairly well, but recently I've been contemplating the overhead involved and whether or not this is the best approach.
Case in point - we need to generate a drop down list of the users teams, so we follow this pattern:
Get a list of the users teams from memcached
If not available get the list from SQL server and store in memcached.
Do a multiget to get the team objects.
Fallback to loading objects from sql store these.
This is all very well - each cached piece of data is relatively easily cached and invalidated, but there are two major downsides to this:
1) Because we are operating on objects we are incurring a rather large overhead - a single team occupies some hundred bytes in memcached and what we really just need for this case is a list of team names and ids - not all the other stuff in the team objects.
2) Due to the fallback to loading individual objects, the number of SQL queries generated on an empty cache or when the items expire can be massive:
1 x Memcached multiget (which misses, which and causes)
1 x SELECT ... FROM Team WHERE Id IN (...)
20 x Store in memcached
So that's 21 network request just for this one query, and also the IN query is slower than a specific join.
Obviously we could just do a simple
SELECT Id, Name FROM Teams WHERE UserId = XYZ
And cache that result, but this this would mean that this data would need to be specifically invalidated whenever the user creates a new team. In this case it might seem relatively simple , but we have many of these type of queries, and many of them operate on axes that are not easily invalidated (like a list of id and names of the teams that your friends have created in a specific game).
Sooo.. My question is - do any of you have ideas for resolving the mentioned drawbacks, or should I just accept that there is an overhead and that cache misses are bad, live with it?
First, cache what you need, maybe that two fields, not a complete record.
Second, cache what you need again, break the result set into records and cache them seperately
about caching:
You generally use caching to offload the slower disc-based storage, in this case mysql. The memory cache scales up rather easily, mysql scales less easy.
Given that, even if you double the cpu/netowork/memory usage of the cache and putting it all together again, it will still offload the db. Adding another nodejs instance or another memcached server is easy.
back to your question
You say its a user's team, you could go and fetch it when the user logs-in, and keep it updated in cache while the user changes it throughout his session.
I presume the team member's names do not change, if so you can load all team members by id,name and store those in cache or even local on nodejs, use the same fallback strategy as you do now. Only step 1 and 2 and 4 will be left then.
personally i usually try to split the sql results into smaller ready-made pieces and cache those, and keep the cache updated as long as possible, untimately trying to use mysql only as storage and never read from it
usually you will run some logic on the returned rows form mysql anyways, theres no need to keep repeating that.